共用方式為

從預設環境移轉應用程式和流程

  • 發行項

本白皮書說明組織和管理員如何從預設環境規劃移轉應用程式和流程。

作者：Ravi Chada (Microsoft)，Rui Santos (Microsoft)

注意

您可選取瀏覽器的列印，然後選取儲存為 PDF 來儲存或列印本白皮書。

預設環境

每個租用戶都會建立一個預設環境，且該租用戶中的所有使用者都可以存取。 預設環境是在最接近 Microsoft Entra 租用戶預設區域的區域中建立，並命名如下：Microsoft Entra 租用戶名稱 (預設)。 每當新使用者簽訂 Power Apps 或 Power Automate，他們會自動新增至預設環境的製造者角色。 使用者不會自動加入預設環境的環境管理員角色。

您不能刪除預設環境，也不能手動備份預設環境。 系統備份是連續進行的。 預設環境有 1 TB 的儲存體容量限制。 預設環境具有下列功能：

  • 3 GB Dataverse 資料庫容量
  • 3 GB Dataverse 檔案容量
  • 1 GB Dataverse 記錄容量

建立新環境之前進行的容量檢查，會在計算是否有足夠空間來建立新環境時，排除預設環境的內涵儲存空間容量。 若要儲存更多資料，您可以建立生產環境。

在預設環境中，擁有 Microsoft 365 授權的組織員工可以建立應用程式和雲端流程。 預設環境會成為這些員工開始建構應用程式和流程的第一個遊樂場工作室。 因為無法從預設環境中移除環境建立者角色，因此建立者開始建立個人生產力應用程式和流程，並在團隊內共用他們，讓其他人受益。 大部分的組織通常會將預設環境重新命名為 個人生產力。

管理員會發現許多應用程式和流程是在預設環境中建立的。 在以下案例中，應用程式或流程可能不適合處於預設環境：

  • 應用程式會以類似生產行為與許多使用者共用。
  • 應用程式使用含有敏感性資料的 Excel 活頁簿。
  • 根據 SharePoint 清單的應用程式會取得許多資料互動 (例如插入或更新)。
  • 應用程式或流程使用的是新資料外洩防護 (DLP) 原則中不允許的連接器。
  • 自訂連接器在預設環境中啟用和使用，而不是在專用環境中受到保護。

上述案例值得考慮，並提供了您應該開始將這些應用程式和流程從預設環境移至其的開發人員環境或其他共用環境的指示。 下一個要考慮的因素是與預設環境相關的限制。

在達到限制後，監視 Power Platform 的卓越中心 (CoE) 團隊就被迫做出反應，而這對在預設環境中執行的應用程式會產生負面影響。 這項限制也可能是管理員或 CoE 團隊必須定期執行的操作。 主要分為三個階段：

  • Power Platform 物件的標識
  • 移動 Power Platform 物件
  • 清理 Power Platform 物件

您可以使用不同的方式來匯出應用程式和流程，將它們移至新的環境中。 解決方案是使用單一檔案，其可以包含您的製作者在 Power Platform 中建構的所有內容，並將它們一起移動。 您可以直接匯出畫布應用程式和雲端流程。

隨著時間的推移，Power Platform 物件會演變為可感知解決方案。 現在，應用程式和流程在預設情況下可以感知解決方案，但這需要手動啟動。 製作者仍然可以從 make.powerapps.com 和 make.powerautomate.com 建立應用程式和流程，這些應用程式和流程可以歸類為非解決方案感知型，並且可以單獨匯出，或將它們新增到解決方案中。 透過新增解決方案，該製作者可以利用環境變數和連線參考，在環境間設定和部署端點。

目標是將所有 Power Platform 元件新增至單一解決方案，這樣可讓多個元件做為單一單位在環境之間輕鬆移動。

Power Platform 物件的標識

第一個步驟是找出需要移動或清理的應用程式、流程和資產。 CoE 入門套件可提供所有應用程式和流程的清單，而 Power BI 報表則可協助您確定使用情況。 此步驟可協助您評估應用程式的使用情況，並應有助於對其進行標記。 當您執行練習時，務必標記應移轉至其他環境的應用程式和流程。 標記可以是根據所使用的連接器、使用者位置、使用者部門等而定。 本文也概述如何根據資料遺失防護 (DLP) 做法，來識別應該清理或重新放置的項目。

移動 Power Platform 物件

如果元件已標記為要移至其他環境，則可以使用一些選項來移動應用程式。 移動是一個互動過程，需要一定程度的製作者互動。 移動應用程式或流程的複雜度會隨用來建立應用程式或流程的元件組合而增加。

例如，一個具有六個畫面的應用程式在多個畫面上有 10 個按鈕。 假設這 10 個按鈕各自呼叫一個單獨的流程。 還有數個流程會每天觸發，以修正資料，或將資料與其他系統整合。 再假設有一個 AI Builder 影像處理模型可做為自動化的一部分。 若要移動這樣的應用程式，則必須將所有元件新增至解決方案，而且在確認完成之前，必須先將連線參考正確地調整並加以測試。

在另一個案例中，假設有一個使用 Office 365 連線的畫布應用程式。 在此案例中，製作者只需將畫布應用程式新增至解決方案。

清理 Power Platform 物件

如果元件已標記為要進行清理，則會有兩個主要選項。 第一個選項是直接刪除，而第二個選項是備份後刪除。 在後一種備份選項中，與移動物件同時發生的步驟可能會有一些重疊。

例如，CoE 團隊管理員發現大多數的製作者是出於學習目的建立測試應用程式和流程。 然後，這些製作者放棄了應用程式和流程，這可以透過查看使用計量來確認。 另一種方式是隔離應用程式。 如果沒有人會使用該應用程式，也可以刪除它。

維護通訊策略扮演著重要角色。 管理員必須規劃通訊：

  • 建立製作者在新環境中啟動應用程式時，所需允許的連線。
  • 目標環境中應用程式的新 URL。
  • 瀏覽至正確的環境。

某些用於重新定位物件的解決方案是現成的，可能需要獨立的 Power Apps 和 Power Automate 授權，讓使用者可以使用超出 Microsoft 365 範圍的資料來源建立和執行應用程式。

策略

如果以策略為基礎，從預設環境中識別和移動應用程式及流程的整個程序更有可能成功。 您應該考慮多個策略。

DLP 策略

資料遺失防護 (DLP) 原則的功能猶如護欄，協助預防使用者無意中揭露組織資料並保護租用戶中的資訊安全。 DLP 原則強制每個環境啟用連接器以及可以一起使用哪些連接器的規則。 連接器分類為 限業務資料、不允許業務資料，或 已封鎖的。 只有群組業務資料中的連接器才能與同一應用程式或流程中的群組連接器搭配使用。 建議您至少具有一個原則。

使用 DLP 識別物件

DLP 原則式識別可幫助您定義應用程式和流程的目標環境。 您可能有使用受 DLP 封鎖的連接器或商務和非商務連接器組合的應用程式或流程，這些連接器會在 DLP 啟動後停止運作。

若要防止因 DLP (CoE 入門套件的一部分) 而造成潛在重要物件停機，您可以尋找 DLP 編輯器 (影響分析) 工具。 DLP 編輯器的目標是讓管理員可以查看現有原則的影響，或是原則變更的潛在影響。 它可讓管理員看到受影響的應用程式和流程，以及在實施新的或更新原則時，將會停用的資源。 該應用程式可以用來檢閱現有的原則、變更現有的原則，並通過連絡製作者並告知他們適合其應用程式或流程的最佳行動方案來降低風險。

更新現有的 DLP 原則以查看影響。 依照使用 CoE 入門套件確保租用戶健康一文，深入了解 DLP 編輯器。

在打開 DLP 功能之前，您可以找出受影響的應用程式和流程，並提醒製作者。 DLP 編輯器可以將受影響的所有應用程式和流程的清單傳送到電子郵件地址，該地址會為每種類型的物件產生一個 .csv 檔案。

使用 DLP 編輯器 2.0 版，在影響分析區域中，選擇將受影響的應用程式流程匯出到 CSV。

使用 DLP 編輯器 2.0 版。

每個產生的 csv 檔案 (flow.csv 和 apps.csv) 都包含以下資訊：

  1. 應用程式和流程的名稱。
  2. 應用程式和流程的負責人。
  3. 應用程式和流程的 OwnerEmail。
  4. 應用程式和流程所使用的所有連線。
  5. 用來標識物件的應用程式和流程的識別碼。
  6. 應用程式和流程所在位置的環境識別碼。

請注意，這些連線會提供應用程式或流程所使用的所有連線清單。 如果您需要準確識別哪個連接器受到相關 DLP 的影響，此時需要自動化。 我們正在評估如何在該工具中改變這種情況。

識別連線的實施範例：

  1. 建立 Power Automate 流程。

  2. 使用取得租用戶 DLP 原則連接器來指定相關的 DLP。

  3. 結果是兩個陣列、商務資料與非商務資料。 例如，TwITter 連接器會顯示下列程式碼：

    [
  {
    "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
    "name": "Twitter",
    "type": "Microsoft.PowerApps/apis"
  }
……
]

  4. 從此清單中，您可以存取與 csv 應用程式或流程連線資料行名稱清單相符的連接器名稱。

  5. 將 csv 轉換為 Excel 格式並將其放在 OneDrive 中，您就可以從 Power Automate 讀取所有受影響的應用程式和流程。 根據比對連線與連接器名稱的邏輯，檢查哪一個連線受到影響。

  6. 當你比對出是哪個連線要成影響後，產生一個包含應用程式或流程識別碼以及受 DLP 影響的連接器新清單。

  7. 使用先前的資訊，通知製作者未來的影響。 如果應用程式或流程可以刪除或需要移轉至其他環境，您可以使用 Power Cards 來收集製作者的意見。

根據您的分析，如果您判斷受影響的流程不會使用，您可以將它們放在隔離區中，並傳送電子郵件給製作者，說明如何將它們移至其他環境。 這能促進自己動手 (DIY) 的文化並消除影子 IT。 在某些情況下，您可能希望使某些物件免於 DLP。 例如，您可能會想要只對已建立且免除目前資源的新資源套用特定的 DLP。 如需 DLP 資源免除的詳細資訊，請參閱 DLP 資源免除。

實際上，您的環境原則是透過 DLP 定義的，並為在預設環境中開發的應用程式和流程提供了目的地。

環境原則

開發環境策略需要以支援貴組織中生產力開發的方式設定環境和其他層級的資料安全性，同時保護和組織資源。 管理環境佈建、存取管理和控制環境中資源的策略對於以下方面很重要：

  • 保護資料和存取。
  • 以符合規範的方式管理預設環境。
  • 管理正確數量的環境，避免大量增加並節省容量。
  • 促進並實施良好的應用程式生命週期管理 (ALM)。
  • 組織邏輯分割區中的資源。
  • 藉由在專用環境中識別生產中的應用程式支援各項作業 (和説明台)。
  • 確保資料存放在可接受的地理區域中及傳輸 (基於效能和法規遵從性原因)。
  • 確保被開發的應用程式會進行隔離。
  • 向使用該服務的商務終端使用者或業務單位提供內部開立發票服務。

您應該有一個能自我維持並擁有現有 ALM 程序的適當部門。 在這類案例中，環境會根據部門提供隔離和組織資源。 此策略可以透過為每個部門建立不同的環境來達成。 這些環境隨後會成為預設環境中應用程式和流程的目的地。

溝通策略

在移轉過程中，有效的溝通至關重要。 所有移轉程序階段都會進行溝通。 清楚的溝通可促進專案關係人之間的瞭解和合作。 它可讓資訊順暢流動，確保每個相關人員都充分了解移轉規劃、進度及任何潛在的挑戰。

做為移轉及清理工作的一部分，請確保該過程對於製作者、專案關係人和領導階層來說是順利的。 制定最有效的溝通方式和應在什麼時候溝通的策略，這可以使您的目標保持一致，並有助於所有參與者的溝通。 需要考慮的選項包括：

  • 使用 CoE 入門套件做為資產追蹤者。
  • 新增自訂雲端流程，在不同的階段傳送通知。
  • 建立範本電子郵件，透過傳送郵件與製作者溝通。

需要注意的事項包括：

  • 變更應用程式的 URL。 應用程式的使用者需要在預設環境中更新應用程式的書籤。
  • 如果存在 URL 型 HTTP 觸發程序流，則必須在相依流程中更新該流程，以確保它仍作為 Webhook 使用。
  • 為製作者和應用程式使用者提供遷移完成後，建立連線的詳細步驟。 當使用者第一次從新環境啟動應用程式時，不必擔心建立連線。

設定良好的溝通方式需要用自助服務模型來進行擴展，而且對使用者來說，這比使用單一使用者電子郵件或通訊群組清單更加即時。 如果您計畫建立 SharePoint 網站，可以使用範本來建立內部 Microsoft Power Platform 中樞。 此中樞將成為學習策略和指導的共同場所，讓製作者能夠針對他們打算建構的內容和方向做出正確的決策。

您可以利用 CoE 入門套件中的現有解決方案元件，例如設定非使用中的通知元件和開發人員合規性元件。 這些元件會隨附電子郵件範本，您可以複製它們以滿足您的目的，並從預設環境中將它們進行移轉。 這還有一個好處，那就是可以在溝通網站上擷取成功案例。

對象

在移轉程序中，溝通通常會涉及不同的對象。 以下是最常見的主要專案關係人及其角色：

  • 應用程式擁有者：應用程式擁有者是負責開發、維護和管理特定應用程式的個人或團隊。 他們對其應用程式的功能、工作流程和設定有深入瞭解。 與應用程式負責人的溝通對於瞭解其應用程式特定需求、收集意見、解決問題以及確保將其應用程式平穩地移轉至新環境十分重要。
  • 應用程式使用者：應用程式使用者是定期使用應用程式執行其任務或工作流的個人。 他們的技術專業知識水準和對應用程式的熟悉度可能各不相同。 與應用程式使用者的溝通非常重要，可以通知他們有關移轉的資訊、提供可能發生的任何變更或中斷的最新消息，並提供培訓或支援以確保轉換順利，並儘量減少對其日常作業的影響。
  • 部門負責人或經理：部門負責人或經理在遷移過程中發揮著重要作用，因為他們負責監督各自部門的運營和戰略目標。 他們需要了解移轉的時間表、潛在影響和好處。 與部門主管溝通可讓他們提供必要的指導、使遷移與部門目標保持一致，並確保團隊內部協調順利。
  • IT 或技術團隊：IT 或技術團隊負責遷移的基礎設施、系統和整體技術方面。 他們會參與移轉程序的規劃、執行及支援。 與 IT 團隊的溝通對討論技術需求、相依性、安全性注意事項以及成功移轉必須實施的任何必要基礎結構或設定變更至關重要。
  • 安全和合規團隊：安全和合規團隊在遷移過程中確保數據安全、隱私和法規合規性方面發揮著關鍵作用。 它們提供指導，並確保採取適當的措施以保護敏感資訊。 與安全性和合規性團隊的溝通涉及討論安全性需求、加密協定、存取控制以及在整個移轉過程中任何與合規性相關的注意事項。
  • 執行管理層：應隨時向執行管理層 (包括 C 級高管或高級領導) 通報遷移過程。 他們可能不需要詳細的技術資訊，但是必須瞭解專案的目標、進度及對組織的潛在影響。 與行政管理層的溝通可協助確保其支援、與戰略目標的一致性、以及遷移的資源分配。

考慮到每個對象的具體需求、關注點和技術理解水準，為他們量身定制溝通策略和信息非常重要。 與所有專案關係人進行清晰且及時的溝通可以促進協作、確保順利協調並減輕移轉過程中的任何潛在挑戰。

步調

在移轉過程中，與專案關係人溝通的節奏或頻率會根據專案的具體需求和動態而變化。 建立定期和一致的溝通非常重要，以使專案關係人了解情況、解決問題並在整個移轉過程中保持一致。 以下是判斷不同專案關係人溝通節奏的一些考量：

  • 應用擁有者： 在整個遷移過程中與應用擁有者保持頻繁的溝通非常重要。 這包括定期更新移轉進度、解決任何問題，以及在必要時讓應用程式負責人參與決策。 根據應用程式的複雜性和重要程度，通訊頻率會有所不同，但是建議定期檢查並及時回應問題。
  • 應用使用者： 通過定期溝通管道與應用用戶互動，讓他們瞭解遷移情況。 這包括宣告、電子郵件、電子報，甚至專門的培訓課程或研討會。 與應用程式使用者溝通的頻率可能會有所不同，但重要的是在關鍵里程碑上提供更新，告知他們可能造成影響的任何變化或中斷，並在整個過程中提供支援和指導。
  • 部門負責人和經理： 與部門負責人和經理的溝通可以定期進行，也可以根據需要進行，具體取決於遷移到其部門的重要性。 定期更新其團隊的整體進度、時間表和影響。
  • IT 或技術團隊：與參與遷移的 IT 和技術團隊進行定期溝通。 這包括持續的協作、共用技術問題的更新，以及協調任何必要的設定或變更。 在規劃和分析階段，溝通頻率通常較高。 在實施階段，定期舉行接觸點或會議，以確保協調順利。

資源分配

有效管理資源對於成功移轉至關重要。 以下是在移轉期間進行資源管理時，要考慮的一些主要事項：

  • 資源識別： 識別遷移專案所需的資源，包括負責遷移前準備、數據遷移、測試、部署、配置、遷移后支援等任務的個人或團隊。 確定每個角色所需的特定技能、專業知識和可用性。
  • 資源分配： 根據資源的技能、可用性和工作負載容量為角色和任務分配資源。 請確定適當分配資源，以平衡工作負載並滿足專案的截止時間。 考慮可能會影響資源配置的任何相依性或限制，例如跨多個專案的共用資源。
  • 技能開發和培訓： 評估團隊內部的技能和知識差距，並提供必要的培訓或技能提升機會，以確保資源為分配的任務提供足夠的裝備。 這可能包括提供培訓課程、研討會或相關資源和文件的存取權。
  • 溝通和協作： 促進遷移中涉及的資源之間的有效溝通和協作。 鼓勵定期狀態更新、協調會議和知識共用，以確保所有團隊成員都能保持一致、瞭解情況並共同努力實現目標。
  • 應急計劃： 預測潛在的資源限制或風險，並制定應急計劃。 確定關鍵角色的後備資源或對其進行交叉培訓，以緩解任何無法預料的挑戰，例如意外缺勤或資源限制。
  • 利益相關者參與： 讓利益相關者 (如應用程式擁有者、部門負責人和管理層) 瞭解資源分配以及對時程表或可交付成果的任何潛在影響。 定期傳送資源更新、進度報表，以及對資源計劃的任何調整，以管理期望並保持透明度。

物件的單獨移轉

應用程式與解決方案之間的區別十分重要。 匯出和匯入應用程式只會影響該物件。 解決方案是一種容器，其中可以包含多個應用程式、流程及其他物件。

匯出和匯入畫布應用程式 (傳統方法)

詳細步驟記錄在匯出畫布應用程式套件和匯入畫布應用程式套件中

這種匯出應用程式的方法是傳統方式。 雖然受到支援，但還是建議您使用解決方案。 解決方案可讓您移轉多個元件，而不僅僅是一種資源。

匯出和匯入流程 (傳統方式)

下列步驟說明如何匯出流程。

  1. 選取「...」功能表，選取匯出，然後選取套件 (.zip)。
  2. 輸入套件的名稱及說明。 然後，您可以在匯入階段設定預設設定並新增可存取的留言。
  3. 選取右下角的匯入按鈕，以下載套件。 如果您的下載未自動開始，您可以選取下載按鈕。

下列步驟說明如何匯入流程。

  1. 選取匯入按鈕。
  2. 上傳套件檔案，並等待畫面顯示套件詳細資料。
  3. 設定流程設定時，您可以選擇建立新的流程，或利用套件中的流程定義來更新現有的流程。
  4. 選取設定流程所需的連線。 在您成功設定所有必要設定之後，您應該會看到匯入按鈕變得可用。

匯入流程之後，必須啟動該流程。 如果流程有任何連線參考，則啟用它的使用者必須具備這些連線的存取權。 如果不是，則連線負責人可以授與啟用使用者的存取權。

這種匯出雲端流程的方法是傳統方式。 雖然受到支援，但還是建議您使用解決方案，這可讓您移轉多個元件，而不只是一個資源。

匯出和匯入模型導向應用程式

模型導向應用程式會是解決方案的一部分。 解決方案檔案 (.zip) 中所包含的封裝應用程式，在順利匯出並匯入目標環境後，可以根據其在資訊安全角色與使用者共用。

匯出解決方案和匯入解決方案中介紹了詳細的逐步程序。

匯入及匯出 Microsoft Copilot Studio 機器人

您可以使用解決方案匯出和匯入機器人。 使用解決方案匯出和匯入機器人中介紹了詳細的步驟清單。

匯入及匯出 Power Pages 網站

移轉頁面牽涉到從來源 Microsoft Dataverse 環境匯出現有的組態設定，然後再將其匯入目標 Dataverse 環境。 有一些必須在目標環境中執行的先決步驟。 準備工作完成後，就可以使用設定移轉工具匯出入口網站設定資料。

SharePoint 表單應用程式 - 預設環境的特殊案例

SharePoint 表單應用程式 只能與一個環境關聯，如果未另行配置，則位於預設環境中。 所有應用程式的移轉都需要將目標設定為不同的環境，而不是預設環境。 現有的自訂表單並不會自動移轉至新指定的環境。 SharePoint 自訂表單只能指定生產環境。 接下來是手動過程，就像移動畫布應用程式一樣。

備份 Microsoft Power Platform 物件

大部分 Microsoft Power Platform 物件都會匯出為 zip 檔案。 如果不是，則至少要有一種檔案格式。 根據原始格式 (如 zip 檔案或隨附的任何副檔名)，可以將這些檔案新增至任何您選擇的檔案儲存位置或存放庫。 需要提及的幾個選項包括 Azure DevOps、GITHub、SharePoint、One Drive 或任何其他支援所有檔案格式的解決方案。

大量移轉選項

如果應用程式或流程的功能與以前相同，就算移轉成功。 但是，有一些元素無法轉移：

  • 有關流 過去運行的流運行數據 - 有關流運行的數據僅存儲 28 天。 如果您需要資料，則可以使用 CoE 入門套件匯出和儲存資料，或者如果您已設定匯出至資料湖。 如果與資料匯出搭配使用，最新版本的 CoE 入門套件會包含資料執行資料。
  • 畫布應用的 版本 - 當製作者反覆運算開發流程時，可能會創建多個版本。 之前的版本無法移轉。 只有最新的版本才能進行移轉。
  • 應用程式或流或使用連接器 訪問的數據 - 匯出過程中僅包含應用程式元數據。

在應用程式或流程中發表的任何共同作業留言也不包括在內。

本文概述了一些可能的選擇。 在決定之前，請務必仔細考慮每個選擇的含意和優點。

全部移轉 – 資料庫備份及還原選項

與大部分環境類型類似，預設環境也會備份。 這些系統備份會自動執行。 預設環境不需要任何指定選項，因此需要支援要求。 備份可以還原至新環境中，並將所有資料保留在 Dataverse 中。 此選項只是告知讀者其存在，並使其瞭解應何時使用該選項。 不應將其視為主要選項，因為它只會產生部分移轉。

  • 支援： Dataverse，Dynamics 應用
  • 不完全支援：畫布應用程式、元件程式庫、自定義頁面 Power Automate、 Microsoft Copilot Studio

未完全支援表示移轉過程中可能存在潛在的資料遺失，需要執行其他的步驟。

先移轉中繼資料，然後再移轉資料

建議的方式是使用解決方案來移動中繼資料，然後使用資料流程、Azure Data Factory 或其他喜好工具來傳輸資料。 由於連接器種類繁多，可能無法在各種情況下實現從開始到結束的完全自動化，但可以達到近似的效果。

概括來說，步驟是：

  1. 將應用程式新增至解決方案。
  2. 將流程新增至解決方案。
  3. 新增現有機器人。
  4. 調整應用程式和流程中的連線參考。
  5. 檢查解決方案元件相依性和新增物件。
  6. 匯出解決方案。
  7. 匯入解決方案。
  8. 傳輸資料。

檢查解決方案相依性

只有當您將所有相關元件新增至解決方案或在目標環境中使用它們時，才能確保解決方案在目標環境中成功匯入。 如果缺少元件，則解決方案可能會匯入失敗。 若要確定所有必要元件都存在，最好結合使用以下選項：

  • 手動將所選元件新增到解決方案中。 在此案例中，假設您知道所有相依元件都已存在於目標環境中。

  • 使用解決方案中的顯示相依項按鈕，讓系統為您識別相依項。 您可以新增所有相依性，也可以選擇只新增目標環境中不存在的相依性。

    該圖顯示了帳戶資料表的相依元件範例。

將元件新增到解決方案 (手動)

假設解決方案已建立，製作者需要使用「新增現有元件」功能表選項來新增現有應用程式、流程或機器人。

該圖顯示了將現有元件新增至解決方案。

調整連接參考

畫布應用程式和流程會以不同方式處理連線。 流對所有連接器使用連接引用，而畫布應用僅將它們用於隱式共用 (非OAuth) 連接，例如 SQL Server 身份驗證。

更新應用程式以使用連線參考而不是連線

新增到解決方案時，無法識別解決方案的畫布應用程式不會自動升級為使用連接參考。 只有在將資料來源新增至應用程式時，連線參考才會與畫布應用程式相關聯。 若要升級應用程式，您必須：

  1. 將非解決方案感知的應用程式新增到解決方案。
  2. 從應用程式中移除連線。
  3. 在解決方案中建立新的連線參考。
  4. 新增包含關聯連線參考的連線。

更新流程以使用連線參考而不是連線

當流程不在解決方案中時，其會使用連線。 如果該流程隨後會新增至解決方案中，其將繼續使用初始連線。 可使用下列兩種方式來更新流程以使用連接參考，而不是連線：

  • 如果流程是在未受管理的解決方案中匯出和匯入，則連線將隨連接參考一起移除。

  • 開啟解決方案流程時，流程詳細資料頁面上的流程檢查工具會顯示使用連接參考的警告。 警告訊息中包含可選取的移除連線來新增連接參考動作。 選取該動作將從流程中的觸發程序和動作移除連線，並允許選取和建立連接參考。

將物件新增至解決方案 (自動化)

您可以使用 PowerShell 命令，將應用程式大量移至解決方案。 也可以透過命令列將先前存在的畫布應用程式和雲端流程新增至解決方案中。 安裝最新的 PowerShell 模組以嘗試此選項。 這兩個主要命令是 Set-PowerAppAsSolutionAware 和 Set-FlowAsSolutionAware。

安裝模組之後，請插入您自己的環境識別碼、應用程式識別碼、流程識別碼和解決方案識別碼。

如果是畫布應用程式：

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

如果是流程：

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

連接引用 是連線參考表中的數據條目。 若要在應用程式或流程中使用連線參考，則需要修改核心應用程式或流程定義。 您必須使用連線參考來取代 connectionReferences 節點。

解決方案匯出及匯入

假設已準備好解決方案，下一階段的自動化工作可使用多種方式完成：

  • 將解決方案手動匯出和匯入目標環境。

  • 使用套件以一次移動多個解決方案。

  • 使用 Power Platform 建立工具工作來執行多個作業，例如封裝解決方案、解壓縮解決方案、匯出解決方案及匯入解決方案。 DevOps 提供自動化應用程式生命週期管理 (ALM) 的功能，而且這些工作都是為支援 ALM 適用的 Microsoft Power Platform 而建立的。

Power Platform 命令列介面 (CLI) 也提供匯出和匯入解決方案的選項。 所有與解決方案相關的命令都可以用來建立、匯出及匯入解決方案。 您也可以使用 CLI 來傳入和傳出資料。

一個對製作者友好的選擇是使用旨在使 ALM 適用的 Power Platform 大眾化的管道。 對於所有製作者、管理員和開發人員來說，將 ALM 自動化和持續整合/持續部署 (CI/CD) 功能引入到單一功能服務中更加容易。

建立連線 (手動)

在設定匯入作業之前的目標環境中，建立應用程式或流程所需的遺失連線。 如需如何建立連線的詳細資訊，請參閱在 Power Automate 中管理連線。

資料移轉

資料移轉有多個可用的選項，從手動到完整自動化都可以。

  • 使用 Excel 活頁簿手動匯出和匯入資料。
  • 您可以開發 Power Automate 雲端流程，從來源資料表提取資料，並將資料直接寫入目的地中。 但是，這需要製作者使用 Dynamics 365 Connector 或 Dataverse (舊版) 連接器。 目前，Dataverse 連接器並不支援跨環境的連線。 該功能計劃在未來推出，一旦發布，它可用於將資料從一個裝置移動到另一個裝置。
  • 配置遷移工具（CMT） 是一種用於門戶遷移的工具，但也可用於常規數據遷移。 CMT 還可以與 PowerShell 一起使用。 PAC CLI 工具提供呼叫 CMT 的功能。
  • 資料流程可以用來建立環境之間的對應，並用於移動資料。 HTTP Web 連接器可以替代 Dataverse。
  • Azure Data Factory 可以與 Dataverse 連接器搭配使用，從來源提取資料，並將資料插入目的地中。

假設預設環境的大小有限，則使用上述其中一個選項應該就足以將資料從預設環境中移出。

清理注意事項

對於長時間未使用和更新的應用程式和流程來說，進行清理是個好主意。 管理員可以考慮用不同的路徑進行清理。

  • 決定匯入資料的順序。 最不相關的資料表最先移走，最相關的資料表最後才移動。
  • 並非所有欄位都需要對應。 例如版本、修改日期、建立日期和其他系統欄位就不需要對應。
  • 如果您想保留原始 建立日期，請使用將來源建立日期欄位對應到目的地資料表上的 OverRiddenCreatedOn 欄位。
  • 無法移轉稽核資料。
  • 除非有意，否則請勿啟用任何基於資料插入觸發的工作流程或流程。 這會增加資料移轉的時間。

標記選項

CoE 入門套件目前尚無標記選項。 但是，您可以將其當作自訂項目新增至入門套件。

建立名為 Tags 的資料表，並設定與應用程式、流程及其他詳細目錄資料表的多對多 (N：N) 關聯。 然後，您可以建立標記，並將這些記錄與適當的詳細目錄項目關聯。 為了獲得更好的使用者體驗，您可以在應用程式、流程及其他詳細目錄資料表的主要表單中嵌入方格。 建議使用此選項，因為它具有參考一致性。

在每個詳細目錄表上建立一個文字欄位，並使用該文字來擷取您稍後可以使用的文字 (標籤)。

如果您需要更固定的清單，請建立全域選項組，並將其新增至所有詳細目錄表及其表單中。

隔離選項

如果您不確定某些應用程式的必要性，您可以嘗試將它們隔離一段時間，並將它們置於隔離狀態。 該應用程序只能由負責人使用。 經過適當的時間後，如果沒有收到負責人的回覆，您可以將它們從環境中刪除。

流程不支援隔離狀態，但是可以使用類似的方法，即停止流程並檢查其負責人是否再次啟動它。

在這兩種情況下，與負責人進行適當的溝通很重要。

只刪除選項

如果確實不會損失生產力和重複使用物件，則此選項是最合適的。 大部分測試流程和應用程式都屬於這一類。

在此案例中，一旦標識物件清單，就可以開發 PowerShell 批次處理，並將 csv 清單傳遞給它，然後刪除這些資產。

當您循環存取應用程式和流程的識別碼時，可以使用以下命令將它們從預設環境中移除。

  • Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
  • Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

物件備份及刪除選項

例如，假設已建立 Power Automate 流程來處理特定的季節性需求，但該流程已經很長時間沒有使用了。 在這種情況下，最好在刪除元件之前先備份元件。

若要建立元件的備份，可以使用個別移轉或大量移轉選項來產生匯出解決方案。 然後可以將其新增至您選擇的檔案存放庫或 OneDrive 位置。

成功備份後，您可以套用刪除選項來完成清理程序。

在許多案例中，這些是由製作者建立的測試流程和應用程式，成為其個人生產力學習和實驗的一部分。

推論

Power Platform 是一種面向公民開發人員和專業開發人員的工具。 預設環境使用情況應主要側重於使用 Microsoft 365 產品的個人生產力。 所有其他應用程式和流程開發都應該在指定的共用、個人或開發人員環境中進行。 強烈建議制定根據 DLP 的獨立環境原則，這可協助製作者在適當的環境中開發其應用程式和流程。 建立溝通原則並為使用者提供自助服務模型來學習策略、解決方案的實施以及開發應用程式和流程的最佳做法也有很大的好處。 另一個好處是可以在溝通網站上擷取成功案例。 內部發佈的成功故事可幫助製作者接觸各種構想，並讓他們瞭解使用 Power Platform 的成功之處。

在移轉或移動特定物件時，強有力的治理策略至關重要。 有多種原則可讓您移轉物件，包括單獨移轉和大量移轉。 可視組織原則選擇最合適的選項。 建議使用解決方案來組織應用程式元件並讓移轉更加直接。