CCP 到 UEL 移轉常見問題

檢閱有關 CCP 到 UEL 移轉的常見問題,包括結轉、停機時間、未啟用使用者、階段性首展、Sandbox 測試、錯誤處理和移轉後授權行為。

• 移轉是否可回復?

  否,移轉程序刻意為單向且無法復原。使用者授權和 UserType 從 CCP 移轉至 UEL 後,便無法回復。因此,在移轉至 UEL 之前,必須先全面測試流程並完成所有預先移轉組態。

• 停機期間對員工的影響為何?

  啟用「統一員工授權」移轉會造成員工無法登入的系統停機。為了儘量減少業務中斷,管理員應謹慎協調並排程專屬上線視窗。此外,移轉完成後,所有啟用的使用者工作階段都會終止,且會清除 UserInfo 快取。這會強迫員工再次登入,以便系統強制執行其更新的授權和存取組態。

• 移轉期間未啟用的使用者會發生什麼狀況?

  平台移轉公用程式不支援將未啟用的使用者從 CCP 移轉至 UEL。此工作特別設計為轉換已啟用的身分,同時保留其歷程記錄中繼資料。

• 階段化移轉是否可以?

  否,無法進行階段式或部分移轉。當您開啟 UEL 移轉時,其會套用至組織層級。啟用後,偏好設定為永久性,這表示所有新使用者都必須使用 UEL 模型,且您無法再建立或新增舊版 CCP 員工使用者。

• 使用者是否在移轉程序期間停用?

  否,使用者不會在移轉期間停用。工具會執行內嵌身分轉換,將使用者類型從外部 (C) 移轉至標準內部 (S)。此流程會刻意保留 UserId、Username、Email 和所有相關聯的記錄擁有權或稽核追蹤 (例如 CreatedById 和 LastModifiedById),而不需要使用者停用。

• 移轉工具是否可在 Sandbox 中使用?

  是。建議先在 Sandbox 組織中測試整個移轉程序,再將其部署在生產環境中。這可讓您事先驗證您的自訂設定檔、權限和共用規則。

• 如果我遇到錯誤,該怎麼辦?

  移轉工作會作為以 200 筆記錄的控制批次執行的非同步背景流程運作。如果發生錯誤,請使用下列方法進行疑難排解:

  • 檢閱追蹤移轉狀態:管理員可存取即時追蹤介面,以及專屬清單檢視,其中顯示執行期間失敗的所有員工,包括其員工識別碼。
  • 識別失敗的階段:基礎邏輯分為幾個階段 (例如,移除權限集、直接 DB 更新、群組重新指派)。介面會顯示詳細的失敗原因,指出程序延遲的確切步驟。
  • 修正並重試:解決基本作業或資料問題後,管理員可以使用內建機制來重試失敗的記錄。重新嘗試機制會從特定失敗點自動恢復,而非重新啟動整個工作流程。每個嘗試都會建立已稽核版本歷程記錄,以便追蹤。
• 移轉後,我的 CCP 授權會發生什麼狀況?

  這取決於授權的使用方式:針對員工設定檔:

  • 移轉完成後,取消指派給員工設定檔的所有 CCP 授權。這些項目不會自動停用。
  • 針對其他使用個案:不需要採取任何動作。所有其他的 CCP 授權將持續正常運作,而不會中斷。
• 為什麼「統一員工使用者」無法使用 Slack 進行驗證或存取適用於 Slack 的 Agentforce 工作人員?

  針對 Slack 驗證的「統一員工使用者」設定檔啟用「已啟用 API」系統權限,並針對 Slack 啟用 Agentforce Agent 存取權。

  若要啟用此權限,請選擇下列其中一個方法:

  • 複製標準設定檔:複製「統一員工使用者」標準設定檔,並手動啟用所複製設定檔的「已啟用 API」權限。
  • 建立權限集:建立已啟用 API 的權限集,並將其指派給「統一員工使用者」。