Microsoft Entra 佈建如何與 Workday 整合

發行項
11/23/2024

Microsoft Entra 使用者佈建服務與 Workday HCM 整合，以管理使用者的身分識別生命週期。 Microsoft Entra ID 提供三個預先建置的整合：

本文說明整合的運作方式，以及如何針對不同的 HR 案例自訂佈建行為。

建立連線

限制 Workday API 對 Microsoft Entra 端點的存取

Microsoft Entra 佈建服務會使用基本驗證，連線至 Workday Web 服務 API 端點。

若要進一步保護 Microsoft Entra 佈建服務與 Workday 之間的連線，您可以限制存取，讓指定的整合系統使用者只能從允許的 Microsoft Entra IP 範圍存取 Workday API。請與您的 Workday 系統管理員連絡，在您的 Workday 租用戶中完成下列設定。

下載 Azure 公用雲端的最新 IP 範圍。
開啟檔案並搜尋標籤 AzureActiveDirectory。
複製元素 addressPrefixes 內所列的所有 IP 位址範圍，並使用該範圍建立您的 IP 位址清單。
登入 Workday 系統管理入口網站。
存取 [維護 IP 範圍] 工作，為 Azure 資料中心建立新的 IP 範圍。以逗點分隔清單，指定該 IP 範圍 (使用 CIDR 標記法)。
存取 [管理驗證原則] 工作，建立新的驗證原則。在驗證原則中，使用驗證允許清單來指定 Microsoft Entra IP 範圍，以及允許從此 IP 範圍內存取的安全性群組。儲存變更。
存取 [啟用所有擱置中的驗證原則變更] 工作，確認變更。

使用受限制的安全性群組，限制存取 Workday 中的員工資料

設定 Workday 整合系統使用者的預設步驟，會授與擷取 Workday 租用戶中所有使用者的存取權。在某些整合案例中，您可能會想要限制存取。例如，只從 Get_Workers API 呼叫傳回特定監督組織中的使用者。

您可以使用 Workday 管理員和設定限制整合系統安全性群組來限制存取權。如需詳細資訊，請檢閱此 Workday 文件概念 Get_Workers 關係型安全性一節：取得 Workers SOAP Web 服務指導方針 (本文所需的 Workday 社群存取權)。

使用受限制的 ISSG (整合系統安全性群組) 來限制存取的這項策略，在下列案例中相當實用：

階段式推出案例：您有大型 Workday 租用戶，並計劃對 Microsoft Entra ID 自動化布建執行分階段推出 Workday。在此案例中，建議您設定受限制的 ISSG，讓 Microsoft Entra ID 只能看見範圍內的員工，而非使用 Microsoft Entra ID 範圍篩選器排除不在目前階段範圍內的使用者。
多個佈建作業案例：您有大型 Workday 租用戶及多個 AD 網域，各自支援不同的業務單位/部門/公司。若要支援此拓撲，您想要執行多個 Workday 來進行 Microsoft Entra 佈建作業，每個作業都會佈建一組特定的員工。在此案例中，建議您設定受限制的 ISSG，讓 Microsoft Entra ID 只能看見相關的員工資料，而非使用 Microsoft Entra ID 範圍篩選器排除員工資料。

Workday 測試連線查詢

為測試 Workday 的連線能力，Microsoft Entra ID 會傳送下列 Get_Workers Workday Web 服務要求。

<!-- Test connection query tries to retrieve one record from the first page -->
<!-- Replace version with Workday Web Services version present in your connection URL -->
<!-- Replace timestamps with the UTC time corresponding to the test connection event -->
<Get_Workers_Request p1:version="v21.1" xmlns:p1="urn:com.workday/bsvc" xmlns="urn:com.workday/bsvc">
  <p1:Request_Criteria>
    <p1:Transaction_Log_Criteria_Data>
      <p1:Transaction_Date_Range_Data>
        <p1:Updated_From>2021-01-19T02:28:50.1491022Z</p1:Updated_From>
        <p1:Updated_Through>2021-01-19T02:28:50.1491022Z</p1:Updated_Through>
      </p1:Transaction_Date_Range_Data>
    </p1:Transaction_Log_Criteria_Data>
    <p1:Exclude_Employees>true</p1:Exclude_Employees>
    <p1:Exclude_Contingent_Workers>true</p1:Exclude_Contingent_Workers>
    <p1:Exclude_Inactive_Workers>true</p1:Exclude_Inactive_Workers>
  </p1:Request_Criteria>
  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-01-19T02:28:50.1491022Z</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-01-19T02:28:50.1491022Z</p1:As_Of_Entry_DateTime>
    <p1:Page>1</p1:Page>
    <p1:Count>1</p1:Count>
  </p1:Response_Filter>
  <p1:Response_Group>
    <p1:Include_Reference>1</p1:Include_Reference>
    <p1:Include_Personal_Information>1</p1:Include_Personal_Information>
  </p1:Response_Group>
</Get_Workers_Request>

完整同步處理的運作方式

Workday 驅動佈建內容中的完整同步處理是一項處理序，其會從 Workday 擷取所有身分識別，並判斷要為每位員工物件，套用哪些佈建規則。首次開啟佈建時，以及從 Microsoft Entra 系統管理中心或使用圖形 API 重新啟動佈建時，會進行完整同步處理。

Microsoft Entra ID 會傳送下列 Get_Workers Workday Web 服務要求來擷取員工資料。該查詢會查詢 Workday 交易記錄中，在截至相對應於執行完整同步處理的時間之前，所有日期有效的員工項目。

<!-- Workday full sync query -->
<!-- Replace version with Workday Web Services version present in your connection URL -->
<!-- Replace timestamps with the UTC time corresponding to full sync run -->
<!-- Count specifies the number of records to return in each page -->
<!-- Response_Group flags derived from provisioning attribute mapping -->

<Get_Workers_Request p1:version="v21.1" xmlns:p1="urn:com.workday/bsvc" xmlns="urn:com.workday/bsvc">
  <p1:Request_Criteria>
    <p1:Transaction_Log_Criteria_Data>
      <p1:Transaction_Type_References>
        <p1:Transaction_Type_Reference>
          <p1:ID p1:type="Business_Process_Type">Hire Employee</p1:ID>
        </p1:Transaction_Type_Reference>
        <p1:Transaction_Type_Reference>
          <p1:ID p1:type="Business_Process_Type">Contract Contingent Worker</p1:ID>
        </p1:Transaction_Type_Reference>
      </p1:Transaction_Type_References>
    </p1:Transaction_Log_Criteria_Data>
  </p1:Request_Criteria>
  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-01-19T02:29:16.0094202Z</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-01-19T02:29:16.0094202Z</p1:As_Of_Entry_DateTime>
    <p1:Count>30</p1:Count>
  </p1:Response_Filter>
  <p1:Response_Group>
    <p1:Include_Reference>1</p1:Include_Reference>
    <p1:Include_Personal_Information>1</p1:Include_Personal_Information>
    <p1:Include_Employment_Information>1</p1:Include_Employment_Information>
    <p1:Include_Organizations>1</p1:Include_Organizations>
    <p1:Exclude_Organization_Support_Role_Data>1</p1:Exclude_Organization_Support_Role_Data>
    <p1:Exclude_Location_Hierarchies>1</p1:Exclude_Location_Hierarchies>
    <p1:Exclude_Cost_Center_Hierarchies>1</p1:Exclude_Cost_Center_Hierarchies>
    <p1:Exclude_Company_Hierarchies>1</p1:Exclude_Company_Hierarchies>
    <p1:Exclude_Matrix_Organizations>1</p1:Exclude_Matrix_Organizations>
    <p1:Exclude_Pay_Groups>1</p1:Exclude_Pay_Groups>
    <p1:Exclude_Regions>1</p1:Exclude_Regions>
    <p1:Exclude_Region_Hierarchies>1</p1:Exclude_Region_Hierarchies>
    <p1:Exclude_Funds>1</p1:Exclude_Funds>
    <p1:Exclude_Fund_Hierarchies>1</p1:Exclude_Fund_Hierarchies>
    <p1:Exclude_Grants>1</p1:Exclude_Grants>
    <p1:Exclude_Grant_Hierarchies>1</p1:Exclude_Grant_Hierarchies>
    <p1:Exclude_Business_Units>1</p1:Exclude_Business_Units>
    <p1:Exclude_Business_Unit_Hierarchies>1</p1:Exclude_Business_Unit_Hierarchies>
    <p1:Exclude_Programs>1</p1:Exclude_Programs>
    <p1:Exclude_Program_Hierarchies>1</p1:Exclude_Program_Hierarchies>
    <p1:Exclude_Gifts>1</p1:Exclude_Gifts>
    <p1:Exclude_Gift_Hierarchies>1</p1:Exclude_Gift_Hierarchies>
    <p1:Include_Management_Chain_Data>1</p1:Include_Management_Chain_Data>
    <p1:Include_Transaction_Log_Data>1</p1:Include_Transaction_Log_Data>
    <p1:Include_Additional_Jobs>1</p1:Include_Additional_Jobs>
  </p1:Response_Group>
</Get_Workers_Request>

Response_Group 節點用於指定要從 Workday 擷取哪些員工屬性。如需 Response_Group 節點中每個旗標的描述，請參閱 Workday Get_Workers API 文件 (英文)。

Response_Group 節點中指定的特定旗標值，會根據 Workday Microsoft Entra 佈建應用程式中設定的屬性加以計算。請參閱支援的實體中的章節，了解用於設定旗標值的準則。

上述查詢中 Workday Get_Workers 的回應，包括員工記錄數目與頁面計數。

  <wd:Response_Results>
    <wd:Total_Results>509</wd:Total_Results>
    <wd:Total_Pages>17</wd:Total_Pages>
    <wd:Page_Results>30</wd:Page_Results>
    <wd:Page>1</wd:Page>
  </wd:Response_Results>

若要擷取結果集的下一頁，下一個 Get_Workers 查詢會將頁碼指定為 Response_Filter 中的參數。

  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-01-19T02:29:16.0094202Z</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-01-19T02:29:16.0094202Z</p1:As_Of_Entry_DateTime>
    <p1:Page>2</p1:Page>
    <p1:Count>30</p1:Count>
  </p1:Response_Filter>

Microsoft Entra 佈建服務會處理每個頁面，並在完整同步處理期間逐一查看所有有效的員工。針對從 Workday 匯入的每個員工項目：

套用 XPATH 運算式，從 Workday 擷取屬性值。
套用屬性對應與比對規則，同時
服務會決定目標中要執行的作業 (Microsoft Entra ID / Active Directory)。

處理完成之後，該服務會將與完整同步處理的開始相關聯的時間戳記，儲存為浮水印。此浮水印可作為增量同步處理週期的起始點。

增量同步處理的運作方式

完成完整同步處理之後，Microsoft Entra 佈建服務會保有 LastExecutionTimestamp，並將其用於建立差異查詢，以擷取增量變更。在累加同步處理期間，Microsoft Entra ID 會將下列類型的查詢傳送至 Workday：

查詢手動更新
查詢有效日期更新與終止
查詢未來就職的員工

查詢手動更新

下列 Get_Workers 要求會查詢上次執行與目前執行時間之間，發生的手動更新。

<!-- Workday incremental sync query for manual updates -->
<!-- Replace version with Workday Web Services version present in your connection URL -->
<!-- Replace timestamps with the UTC time corresponding to last execution and current execution time -->
<!-- Count specifies the number of records to return in each page -->
<!-- Response_Group flags derived from provisioning attribute mapping -->

<Get_Workers_Request p1:version="v21.1" xmlns:p1="urn:com.workday/bsvc" xmlns="urn:com.workday/bsvc">
  <p1:Request_Criteria>
    <p1:Transaction_Log_Criteria_Data>
      <p1:Transaction_Date_Range_Data>
        <p1:Updated_From>2021-01-19T02:29:16.0094202Z</p1:Updated_From>
        <p1:Updated_Through>2021-01-19T02:49:06.290136Z</p1:Updated_Through>
      </p1:Transaction_Date_Range_Data>
    </p1:Transaction_Log_Criteria_Data>
  </p1:Request_Criteria>
  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-01-19T02:49:06.290136Z</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-01-19T02:49:06.290136Z</p1:As_Of_Entry_DateTime>
    <p1:Count>30</p1:Count>
  </p1:Response_Filter>
  <p1:Response_Group>
    <p1:Include_Reference>1</p1:Include_Reference>
    <p1:Include_Personal_Information>1</p1:Include_Personal_Information>
    <p1:Include_Employment_Information>1</p1:Include_Employment_Information>
    <p1:Include_Organizations>1</p1:Include_Organizations>
    <p1:Exclude_Organization_Support_Role_Data>1</p1:Exclude_Organization_Support_Role_Data>
    <p1:Exclude_Location_Hierarchies>1</p1:Exclude_Location_Hierarchies>
    <p1:Exclude_Cost_Center_Hierarchies>1</p1:Exclude_Cost_Center_Hierarchies>
    <p1:Exclude_Company_Hierarchies>1</p1:Exclude_Company_Hierarchies>
    <p1:Exclude_Matrix_Organizations>1</p1:Exclude_Matrix_Organizations>
    <p1:Exclude_Pay_Groups>1</p1:Exclude_Pay_Groups>
    <p1:Exclude_Regions>1</p1:Exclude_Regions>
    <p1:Exclude_Region_Hierarchies>1</p1:Exclude_Region_Hierarchies>
    <p1:Exclude_Funds>1</p1:Exclude_Funds>
    <p1:Exclude_Fund_Hierarchies>1</p1:Exclude_Fund_Hierarchies>
    <p1:Exclude_Grants>1</p1:Exclude_Grants>
    <p1:Exclude_Grant_Hierarchies>1</p1:Exclude_Grant_Hierarchies>
    <p1:Exclude_Business_Units>1</p1:Exclude_Business_Units>
    <p1:Exclude_Business_Unit_Hierarchies>1</p1:Exclude_Business_Unit_Hierarchies>
    <p1:Exclude_Programs>1</p1:Exclude_Programs>
    <p1:Exclude_Program_Hierarchies>1</p1:Exclude_Program_Hierarchies>
    <p1:Exclude_Gifts>1</p1:Exclude_Gifts>
    <p1:Exclude_Gift_Hierarchies>1</p1:Exclude_Gift_Hierarchies>
    <p1:Include_Management_Chain_Data>1</p1:Include_Management_Chain_Data>
    <p1:Include_Additional_Jobs>1</p1:Include_Additional_Jobs>
  </p1:Response_Group>
</Get_Workers_Request>

查詢有效日期更新與終止

下列 Get_Workers 要求，會查詢上次執行與目前執行時間之間，所發生的有效日期更新。

<!-- Workday incremental sync query for effective-dated updates -->
<!-- Replace version with Workday Web Services version present in your connection URL -->
<!-- Replace timestamps with the UTC time corresponding to last execution and current execution time -->
<!-- Count specifies the number of records to return in each page -->
<!-- Response_Group flags derived from provisioning attribute mapping -->

<Get_Workers_Request p1:version="v21.1" xmlns:p1="urn:com.workday/bsvc" xmlns="urn:com.workday/bsvc">
  <p1:Request_Criteria>
    <p1:Transaction_Log_Criteria_Data>
      <p1:Transaction_Date_Range_Data>
        <p1:Effective_From>2021-01-19T02:29:16.0094202Z</p1:Effective_From>
        <p1:Effective_Through>2021-01-19T02:49:06.290136Z</p1:Effective_Through>
      </p1:Transaction_Date_Range_Data>
    </p1:Transaction_Log_Criteria_Data>
  </p1:Request_Criteria>
  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-01-19T02:49:06.290136Z</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-01-19T02:49:06.290136Z</p1:As_Of_Entry_DateTime>
    <p1:Page>1</p1:Page>
    <p1:Count>30</p1:Count>
  </p1:Response_Filter>
  <p1:Response_Group>
    <p1:Include_Reference>1</p1:Include_Reference>
    <p1:Include_Personal_Information>1</p1:Include_Personal_Information>
    <p1:Include_Employment_Information>1</p1:Include_Employment_Information>
    <p1:Include_Organizations>1</p1:Include_Organizations>
    <p1:Exclude_Organization_Support_Role_Data>1</p1:Exclude_Organization_Support_Role_Data>
    <p1:Exclude_Location_Hierarchies>1</p1:Exclude_Location_Hierarchies>
    <p1:Exclude_Cost_Center_Hierarchies>1</p1:Exclude_Cost_Center_Hierarchies>
    <p1:Exclude_Company_Hierarchies>1</p1:Exclude_Company_Hierarchies>
    <p1:Exclude_Matrix_Organizations>1</p1:Exclude_Matrix_Organizations>
    <p1:Exclude_Pay_Groups>1</p1:Exclude_Pay_Groups>
    <p1:Exclude_Regions>1</p1:Exclude_Regions>
    <p1:Exclude_Region_Hierarchies>1</p1:Exclude_Region_Hierarchies>
    <p1:Exclude_Funds>1</p1:Exclude_Funds>
    <p1:Exclude_Fund_Hierarchies>1</p1:Exclude_Fund_Hierarchies>
    <p1:Exclude_Grants>1</p1:Exclude_Grants>
    <p1:Exclude_Grant_Hierarchies>1</p1:Exclude_Grant_Hierarchies>
    <p1:Exclude_Business_Units>1</p1:Exclude_Business_Units>
    <p1:Exclude_Business_Unit_Hierarchies>1</p1:Exclude_Business_Unit_Hierarchies>
    <p1:Exclude_Programs>1</p1:Exclude_Programs>
    <p1:Exclude_Program_Hierarchies>1</p1:Exclude_Program_Hierarchies>
    <p1:Exclude_Gifts>1</p1:Exclude_Gifts>
    <p1:Exclude_Gift_Hierarchies>1</p1:Exclude_Gift_Hierarchies>
    <p1:Include_Management_Chain_Data>1</p1:Include_Management_Chain_Data>
    <p1:Include_Additional_Jobs>1</p1:Include_Additional_Jobs>
  </p1:Response_Group>
</Get_Workers_Request>

查詢未來就職的員工

若上述任一查詢傳回未來就職的員工，則會使用下列 Get_Workers 要求，擷取未來就職新進員工的相關資訊。新進員工的 WID 屬性，會用於執行查閱，並將有效日期設定為雇用日期與時間。

注意

Workday 中未來雇用人員的 [作用中] 欄位設定為 "0"，並在雇用日期變更為 "1"。連接器的設計會查詢在雇用日期生效的未來雇用資訊，而這是它一律會取得未來雇用職工設定檔並將 [作用中] 欄位設定為 "1" 的原因。這可讓您事先為未來雇用人員設定 Microsoft Entra 設定檔，並預先填入所有正確的資訊。如果您要延遲未來雇用人員 Microsoft Entra 帳戶的啟用，請使用轉換函式 DateDiff。

<!-- Workday incremental sync query to get new hire data effective as on hire date/first day of work -->
<!-- Replace version with Workday Web Services version present in your connection URL -->
<!-- Replace timestamps hire date/first day of work -->
<!-- Count specifies the number of records to return in each page -->
<!-- Response_Group flags derived from provisioning attribute mapping -->

<Get_Workers_Request p1:version="v21.1" xmlns:p1="urn:com.workday/bsvc" xmlns="urn:com.workday/bsvc">
  <p1:Request_References>
    <p1:Worker_Reference>
      <p1:ID p1:type="WID">7bf6322f1ea101fd0b4433077f09cb04</p1:ID>
    </p1:Worker_Reference>
  </p1:Request_References>
  <p1:Response_Filter>
    <p1:As_Of_Effective_Date>2021-02-01T08:00:00+00:00</p1:As_Of_Effective_Date>
    <p1:As_Of_Entry_DateTime>2021-02-01T08:00:00+00:00</p1:As_Of_Entry_DateTime>
    <p1:Count>30</p1:Count>
  </p1:Response_Filter>
  <p1:Response_Group>
    <p1:Include_Reference>1</p1:Include_Reference>
    <p1:Include_Personal_Information>1</p1:Include_Personal_Information>
    <p1:Include_Employment_Information>1</p1:Include_Employment_Information>
    <p1:Include_Organizations>1</p1:Include_Organizations>
    <p1:Exclude_Organization_Support_Role_Data>1</p1:Exclude_Organization_Support_Role_Data>
    <p1:Exclude_Location_Hierarchies>1</p1:Exclude_Location_Hierarchies>
    <p1:Exclude_Cost_Center_Hierarchies>1</p1:Exclude_Cost_Center_Hierarchies>
    <p1:Exclude_Company_Hierarchies>1</p1:Exclude_Company_Hierarchies>
    <p1:Exclude_Matrix_Organizations>1</p1:Exclude_Matrix_Organizations>
    <p1:Exclude_Pay_Groups>1</p1:Exclude_Pay_Groups>
    <p1:Exclude_Regions>1</p1:Exclude_Regions>
    <p1:Exclude_Region_Hierarchies>1</p1:Exclude_Region_Hierarchies>
    <p1:Exclude_Funds>1</p1:Exclude_Funds>
    <p1:Exclude_Fund_Hierarchies>1</p1:Exclude_Fund_Hierarchies>
    <p1:Exclude_Grants>1</p1:Exclude_Grants>
    <p1:Exclude_Grant_Hierarchies>1</p1:Exclude_Grant_Hierarchies>
    <p1:Exclude_Business_Units>1</p1:Exclude_Business_Units>
    <p1:Exclude_Business_Unit_Hierarchies>1</p1:Exclude_Business_Unit_Hierarchies>
    <p1:Exclude_Programs>1</p1:Exclude_Programs>
    <p1:Exclude_Program_Hierarchies>1</p1:Exclude_Program_Hierarchies>
    <p1:Exclude_Gifts>1</p1:Exclude_Gifts>
    <p1:Exclude_Gift_Hierarchies>1</p1:Exclude_Gift_Hierarchies>
    <p1:Include_Management_Chain_Data>1</p1:Include_Management_Chain_Data>
    <p1:Include_Additional_Jobs>1</p1:Include_Additional_Jobs>
  </p1:Response_Group>
</Get_Workers_Request>

擷取員工資料屬性

Get_Workers API 可傳回與員工相關聯的不同資料集。依據佈建結構描述中設定的 XPATH API 運算式，Microsoft Entra 佈建服務會判斷要從 Workday 擷取哪些資料集。因此，會在 Get_Workers 要求中設定 Response_Group 旗標。

下表提供用來擷取特定資料集的對應組態的指引。

#	Workday 實體	預設包含	在對應中指定用於擷取非預設實體的 XPATH 模式
1	`Personal Data`	Yes	`wd:Worker_Data/wd:Personal_Data`
2	`Employment Data`	Yes	`wd:Worker_Data/wd:Employment_Data`
3	`Additional Job Data`	Yes	`wd:Worker_Data/wd:Employment_Data/wd:Worker_Job_Data[@wd:Primary_Job=0]`
4	`Organization Data`	Yes	`wd:Worker_Data/wd:Organization_Data`
5	`Management Chain Data`	Yes	`wd:Worker_Data/wd:Management_Chain_Data`
6	`Supervisory Organization`	Yes	`SUPERVISORY`
7	`Company`	Yes	`COMPANY`
8	`Business Unit`	No	`BUSINESS_UNIT`
9	`Business Unit Hierarchy`	No	`BUSINESS_UNIT_HIERARCHY`
10	`Company Hierarchy`	No	`COMPANY_HIERARCHY`
11	`Cost Center`	No	`COST_CENTER`
12	`Cost Center Hierarchy`	No	`COST_CENTER_HIERARCHY`
13	`Fund`	No	`FUND`
14	`Fund Hierarchy`	No	`FUND_HIERARCHY`
15	`Gift`	No	`GIFT`
16	`Gift Hierarchy`	No	`GIFT_HIERARCHY`
17	`Grant`	No	`GRANT`
18	`Grant Hierarchy`	No	`GRANT_HIERARCHY`
19	`Business Site Hierarchy`	No	`BUSINESS_SITE_HIERARCHY`
20	`Matrix Organization`	No	`MATRIX`
21	`Pay Group`	No	`PAY_GROUP`
22	`Programs`	No	`PROGRAMS`
23	`Program Hierarchy`	No	`PROGRAM_HIERARCHY`
24	`Region`	No	`REGION_HIERARCHY`
25	`Location Hierarchy`	No	`LOCATION_HIERARCHY`
26	`Account Provisioning Data`	No	`wd:Worker_Data/wd:Account_Provisioning_Data`
27	`Background Check Data`	No	`wd:Worker_Data/wd:Background_Check_Data`
28	`Benefit Eligibility Data`	No	`wd:Worker_Data/wd:Benefit_Eligibility_Data`
29	`Benefit Enrollment Data`	No	`wd:Worker_Data/wd:Benefit_Enrollment_Data`
30	`Career Data`	No	`wd:Worker_Data/wd:Career_Data`
31	`Compensation Data`	No	`wd:Worker_Data/wd:Compensation_Data`
32	`Contingent Worker Tax Authority Data`	No	`wd:Worker_Data/wd:Contingent_Worker_Tax_Authority_Form_Type_Data`
33	`Development Item Data`	No	`wd:Worker_Data/wd:Development_Item_Data`
34	`Employee Contracts Data`	No	`wd:Worker_Data/wd:Employee_Contracts_Data`
35	`Employee Review Data`	No	`wd:Worker_Data/wd:Employee_Review_Data`
36	`Feedback Received Data`	No	`wd:Worker_Data/wd:Feedback_Received_Data`
37	`Worker Goal Data`	No	`wd:Worker_Data/wd:Worker_Goal_Data`
38	`Photo Data`	No	`wd:Worker_Data/wd:Photo_Data`
39	`Qualification Data`	No	`wd:Worker_Data/wd:Qualification_Data`
40	`Related Persons Data`	No	`wd:Worker_Data/wd:Related_Persons_Data`
41	`Role Data`	No	`wd:Worker_Data/wd:Role_Data`
42	`Skill Data`	No	`wd:Worker_Data/wd:Skill_Data`
43	`Succession Profile Data`	No	`wd:Worker_Data/wd:Succession_Profile_Data`
44	`Talent Assessment Data`	No	`wd:Worker_Data/wd:Talent_Assessment_Data`
45	`User Account Data`	No	`wd:Worker_Data/wd:User_Account_Data`
46	`Worker Document Data`	No	`wd:Worker_Data/wd:Worker_Document_Data`

注意

資料表中列出的每個 Workday 實體，都受到 Workday 中網域安全性原則所保護。若在設定正確的 XPATH 之後，無法擷取任何與實體相關聯的屬性，請洽詢您的 Workday 系統管理員，確定已針對和佈建應用程式相關聯的整合系統使用者，設定了適當的網域安全性原則。例如，若要擷取技能資料，需要取得 Workday 網域員工資料：技能與經驗的存取權。

以下是一些範例，說明如何擴充 Workday 整合以符合特定需求。

範例 1：擷取成本中心與付費群組資訊

假設您想要從 Workday 擷取下列資料集，並在您的佈建規則中使用這些資料集：

成本中心
成本中心階層
付費群組

根據預設，不會包括上述資料集。若要擷取這些資料集：

以至少應用程式系統管理員的身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [身分識別] > [應用程式] > [企業應用程式]。
選取您的 Workday 至 Active Directory /Microsoft Entra 使用者佈建應用程式。
選取 [佈建]
編輯對應，然後從進階區段開啟 Workday 屬性清單。

新增下列屬性定義，並將其標記為「必要」。這些屬性不會對應至 Active Directory 或 Microsoft Entra ID 中的任何屬性。它們的作用是通知連接器擷取成本中心、成本中心階層與付費群組資訊。

屬性名稱	XPATH API 運算式
CostCenterHierarchyFlag	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data[wd:Organization_Data/wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']='COST_CENTER_HIERARCHY']/wd:Organization_Reference/@wd:Descriptor
CostCenterFlag	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data[wd:Organization_Data/wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']='COST_CENTER']/wd:Organization_Data/wd:Organization_Code/text()
PayGroupFlag	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data[wd:Organization_Data/wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']='PAY_GROUP']/wd:Organization_Data/wd:Organization_Reference_ID/text()

Get_Workers 回應中提供成本中心和支付群組資料集之後，您可以使用 XPATH 值來擷取成本中心名稱、成本中心代碼和付款群組。

屬性名稱	XPATH API 運算式
CostCenterName	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data/wd:Organization_Data[wd:Organization_Type_Reference/@wd:Descriptor='Cost Center']/wd:Organization_Name/text()
CostCenterCode	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data/wd:Organization_Data[wd:Organization_Type_Reference/@wd:Descriptor='Cost Center']/wd:Organization_Code/text()
PayGroup	wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data/wd:Organization_Data[wd:Organization_Type_Reference/@wd:Descriptor='Pay Group']/wd:Organization_Name/text()

範例 2：擷取資格與技能資料

假設您想要擷取與使用者相關聯的認證。 資格資料集可提供此資訊。若要從 Get_Workers 回應取得此資料集，請使用下列 XPATH：

wd:Worker/wd:Worker_Data/wd:Qualification_Data/wd:Certification/wd:Certification_Data/wd:Issuer/text()

範例 3：擷取佈建群組指派

假設您想要擷取指派給員工的佈建群組。 帳戶佈建資料集可以供此資訊。若要從 Get_Workers 回應取得此資料，請使用下列 XPATH：

wd:Worker/wd:Worker_Data/wd:Account_Provisioning_Data/wd:Provisioning_Group_Assignment_Data[wd:Status='Assigned']/wd:Provisioning_Group/text()

處理不同的 HR 案例

本節說明如何針對下列 HR 案例自訂佈建應用程式：

支援員工轉換
擷取國際工作指派和次要工作詳細資料

支援員工轉換

本節描述 Microsoft Entra 佈建服務支援，用於將員工角色從全職員工 (FTE) 轉換為臨時工 (CW)(反之亦然) 的案例。根據 Workday 中處理工作者角色轉換的方式，可能會有不同的實作層面需要考慮。

案例 1：從 FTE 到 CW (反之亦然) 的回溯轉換
案例 2：今天雇用為 CW/FTE 的員工，今天對 FTE/CW 的變更
案例 3：已將雇用為 CW/FTE 的工作者角色解雇，該員工在經過很長一段間隔之後以 FTE/CW 的角色重新加入
案例 4：當工作者角色為作用中 CW/FTE 時，未來日期轉換

案例 1：從 FTE 到 CW (反之亦然) 的過去日期轉換

您的 HR 小組可能會基於有效的商務原因，追溯 Workday 中的員工轉換異動。範例包括薪資處理、預算合規性、法律要求和權益管理。以下是說明如何針對此案例處理佈建的範例。

今天是 2023 年 1 月 15 日，Jane Doe 被聘為一名臨時工。 HR 為 Jane 提供一個全職職位。
Jane 合約變更的條款需要回溯異動，使其與當月的開頭一致。 HR 在 2023 年 1 月 15 日啟動回溯的員工轉換異動，生效日期為 2023 年 1 月 1 日。現在 Jane 在 Workday 中有兩個工作者設定檔。 CW 設定檔為非使用中，而 FTE 設定檔為使用中。
Microsoft Entra 佈建服務會在 2023 年 1 月 15 日的 Workday 變更檔中偵測到此變更。該服務會在下一個同步週期中自動佈建新 FTE 設定檔的屬性。
佈建應用程式組態不需要變更即可處理此案例。

案例 2：今天雇用為 CW/FTE 的員工，今天對 FTE/CW 的變更

此案例類似於上述案例，不同之處在於 HR 會執行立即生效的工作者角色轉換，而不是回溯異動。 Microsoft Entra 佈建服務會在 Workday 變更檔中偵測到此變更。在下一個同步處理週期中，服務會自動使用有效的 FTE 設定檔來佈建任何關聯的屬性。佈建應用程式組態不需要變更即可處理此案例。

案例 3：已將雇用為 CW/FTE 的工作者角色解雇，該員工在經過很長一段間隔之後以 FTE/CW 的角色重新加入

員工通常會以臨時工作者身分在公司開始工作、離開公司，然後在數個月之後重新加入為全職員工。以下是說明如何針對此案例處理佈建的範例。

今天是 2023 年 1 月 1 日，John Smith 會以臨時工的身分開始工作。因為沒有與 John 的 WorkerID (比對屬性) 相關聯的 AD 帳戶，所以佈建服務會建立新的 AD 帳戶，並將 John 的臨時員工 WID (WorkdayID) 連結至其 AD 帳戶。
John 的合約將於 2023 年 1 月 31 日結束。在 1 月 31 日結束時執行的佈建週期中，John 的 AD 帳戶會停用。
John 應徵另一個職位，並決定以全職員工身分重新加入公司，合約將於 2023 年 5 月 1 日生效。 HR 在 2023 年 4 月 15 日以預先雇用員工的身分輸入 John 的資訊。現在 John 在 Workday 中有兩個工作者設定檔。 CW 設定檔為非使用中，而 FTE 設定檔為使用中。這兩筆記錄具有相同的 WorkerID，但 WID 不同。
在 4 月 15 日，在累加週期期間，Microsoft Entra 佈建服務會自動將 AD 帳戶的擁有權轉移給作用中的員工設定檔。在此情況下，它會取消與 AD 帳戶臨時工設定檔的連結，並建立 John 作用中員工設定檔與 John AD 帳戶之間的新連結。
佈建應用程式組態不需要變更即可處理此案例。

案例 4：當工作者角色為作用中 CW/FTE 時，未來日期轉換

有時候，當 HR 起始未來日期的工作者轉換異動時，工作者角色可能已經是作用中工作者。以下是說明如何針對此案例處理佈建的範例。

今天是 2023 年 1 月 1 日，John Smith 會以臨時工的身分開始工作。因為沒有與 John 的 WorkerID (比對屬性) 相關聯的 AD 帳戶，所以佈建服務會建立新的 AD 帳戶，並將 John 的臨時員工 WID (WorkdayID) 連結至其 AD 帳戶。
1 月 15 日，HR 啟動將 John 從臨時工轉換為全職員工的異動，生效日期為 2023 年 2 月 1 日。
由於 Microsoft Entra 佈建服務會自動處理未來日期的僱用，因此它會在 1 月 15 日處理 John 的新全職員工設定檔，並以全職雇用詳細資料更新 John 的設定檔，即使他仍然是一名臨時工。
若要避免此行為，並確保會在 2023 年 2 月 1 日佈建 John 的 FTE 詳細資料，請執行下列組態變更。

組態變更
1. 請洽詢您的 Workday 系統管理員，以建立稱為「未來日期轉換」的佈建群組。
2. 在 Workday 中實作邏輯，將具有未來日期轉換的員工/員工記錄新增至此佈建群組。
3. 更新 Microsoft Entra 佈建應用程式以讀取此佈建群組。如需如何擷取佈建群組的指示，請參閱這裡的指示
4. 在 Microsoft Entra ID 中建立範圍篩選，以排除屬於此佈建群組一部分的員工設定檔。
5. 在 Workday 中，實作邏輯，使得 Workday 在轉換生效的日期會從 Workday 中的佈建群組中移除相關的員工/臨時工作者記錄。
6. 使用此設定時，現有的員工/臨時工記錄將繼續有效，而且佈建變更只會在轉換當天發生。

注意

在初始完整同步處理期間，可能會注意到與先前非在職員工個人資料相關聯的屬性值流向，已轉換成員工 AD 帳戶的行為。這是暫時性的，而且當完整同步處理進行時，最終會由作用中員工設定檔中的屬性值覆寫。完整同步處理完成且佈建工作達到穩定狀態後，一律會在累加同步處理期間挑選有效的員工設定檔。

擷取國際作業指派與次要作業詳細資料

根據預設，Workday 連接器會擷取與員工主要工作相關聯的屬性。該連接器也支援擷取與國際工作指派或次要工作相關聯的 Additional Job Data。

使用以下步驟來擷取與國際工作指派相關聯的屬性：

將 Workday 連線 URL 設定為使用 Workday Web 服務 API 30.0 版或更新版本。在您的 Workday 佈建應用程式中，適當地設定正確的 XPATH 值。
使用 Worker_Job_Data 節點上的選取器 @wd:Primary_Job=0，擷取正確的屬性。
- 範例 1：若要取得 SecondaryBusinessTitle，請使用 XPATH wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Worker_Job_Data[@wd:Primary_Job=0]/wd:Position_Data/wd:Business_Title/text()
- 範例 2：若要取得 SecondaryBusinessLocation，請使用 XPATH wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Worker_Job_Data[@wd:Primary_Job=0]/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Location_Reference/@wd:Descriptor

已知的限制

本節列出客戶在 Workday 整合中可能會遇到的當前已知限制。

連接器不支援 Workday 計算欄位的檢索。
連接器不支援同步 Workday 中的相片。
連接器不支援進階檢索工作最後一天到期的員工。
在增量同步期間，對於位於亞太地區和澳大利亞/紐西蘭地區的員工，處理終止事件可能會延遲。

共用方式為