Partager via

Comment Microsoft Entra provisionnement s’intègre à Workday

  • Article

Le service d’approvisionnement d’utilisateurs Microsoft Entra s’intègre avec Workday HCM pour gérer le cycle de vie des identités des utilisateurs. Microsoft Entra ID offre trois intégrations prédéfinies :

Cet article explique le fonctionnement de l’intégration et comment vous pouvez personnaliser le comportement d’approvisionnement pour différents scénarios de RH.

Établir une connectivité

Restriction de l’accès de l’API Workday aux points de terminaison Microsoft Entra

Le service d’approvisionnement Microsoft Entra utilise l’authentification de base pour se connecter aux points de terminaison de l’API de services web Workday.

Pour sécuriser davantage la connectivité entre le service d’approvisionnement Microsoft Entra et Workday, vous pouvez restreindre l’accès afin que l’utilisateur du système d’intégration désigné accède uniquement aux API Workday à partir de plages d’adresses IP Microsoft Entra autorisées. Demandez à votre administrateur Workday d’effectuer la configuration suivante dans votre locataire Workday.

  1. Téléchargez les dernières plages d’adresses IP pour le cloud public Azure.
  2. Ouvrez ce fichier et recherchez AzureActiveDirectory.
  3. Copiez toutes les plages d’adresses IP répertoriées dans l’élément addressPrefixes, et utilisez la plage pour créer votre liste d’adresses IP.
  4. Connectez-vous au portail d’administration Workday.
  5. Accédez à la tâche Maintain IP Ranges (conserver les plages d’adresses IP) pour créer une plage d’adresses IP pour les centres de données Azure. Spécifiez les plages d’adresses IP (à l’aide d’une notation CIDR) sous la forme d’une liste séparée par des virgules.
  6. Accédez à la tâche Manage Authentication Policies (Gérer les stratégies d’authentification) pour créer une stratégie d’authentification. Dans la stratégie d’authentification, utilisez la liste d’autorisation d’authentification pour spécifier la plage d’adresses IP Microsoft Entra et le groupe de sécurité qui sont autorisés à accéder depuis cette plage d’adresses IP. Enregistrez les modifications.
  7. Accédez à la tâche Activate All Pending Authentication Policy Changes (Activer toutes les modifications de stratégie d'authentification en attente) pour confirmer les modifications.

Limitation de l’accès aux données des employés dans Workday à l’aide de groupes de sécurité avec contraintes

La procédure par défaut pour configurer l’utilisateur du système d’intégration Workday accorde l’accès pour récupérer tous les utilisateurs dans votre locataire Workday. Dans certains scénarios d’intégration, vous souhaiterez peut-être limiter l’accès. Par exemple, retourner uniquement les utilisateurs de certaines organisations de supervision à partir de l’appel d’API Get_Workers.

Vous pouvez limiter l’accès en travaillant avec votre administrateur Workday et en configurant des groupes de sécurité du système d’intégration avec contraintes. Pour plus d’informations, consultez la section Sécurité contextuelle Get Workers dans ce document Workday : Directives relatives au service web SOAP Get Workers (Accès à la communauté Workday requis pour cet article).

Cette stratégie de limitation de l’accès à l’aide des groupes ISSG (groupes de sécurité du système d’intégration) avec contraintes est utile dans les scénarios suivants :

  • Scénario de déploiement progressif : vous avez un locataire Workday de grande taille et vous envisagez d’effectuer un déploiement progressif de Workday vers l’approvisionnement automatique Microsoft Entra ID. Dans ce scénario, au lieu d’exclure les utilisateurs qui ne figurent pas dans l’étendue de la phase actuelle avec des filtres d’étendue Microsoft Entra ID, nous vous recommandons de configurer des ISSG avec contraintes pour que seuls les employés figurant dans l’étendue soient visibles par Microsoft Entra ID.
  • Scénarios de travaux d’approvisionnement multiples : vous avez un locataire Workday de grande taille et plusieurs domaines AD prenant chacun en charge une unité commerciale, division ou société distincte. Pour prendre en charge cette topologie, vous pouvez exécuter plusieurs travaux d’approvisionnement de Workday vers Microsoft Entra, chaque travail approvisionnant un ensemble spécifique d’employés. Dans ce scénario, au lieu d’utiliser des filtres d’étendue Microsoft Entra ID pour exclure des données d’employés, nous vous recommandons de configurer des ISSG avec contraintes de façon à ce que seules les données d’employés pertinentes soient visibles pour Microsoft Entra ID.

Requête de test de connexion à Workday

Pour tester la connectivité à Workday, Microsoft Entra ID envoie la demande de services web Workday Get_Workers suivante.

<!-- 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>

Fonctionnement de la synchronisation complète

La synchronisation complète dans le contexte de l’approvisionnement piloté par Workday fait référence au processus d’extraction de toutes les identités de Workday et de détermination des règles d’approvisionnement à appliquer à chaque objet employé. La synchronisation complète se produit lors de la première activation de l’approvisionnement et lors du redémarrage de l’approvisionnement à partir du centre d’administration Microsoft Entra ou à l’aide d’API Graph.

Microsoft Entra ID envoie la demande de services web Workday Get_Workers suivante pour récupérer les données d’employés. La requête recherche dans le journal des transactions de Workday toutes les entrées d’employés avec date d’effet à compter de l’heure correspondant à l’exécution de la synchronisation complète.

<!-- 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>

Le nœud Response_Group est utilisé pour spécifier les attributs d’employé à extraire de Workday. Pour obtenir une description de chaque indicateur dans le nœud Response_Group, consultez la documentation sur l’API Get_Workers de Workday.

Certaines valeurs d’indicateur spécifiées dans le nœud Response_Group sont calculées en fonction des attributs configurés dans l’application d’approvisionnement Microsoft Entra Workday. Reportez-vous à la section Entités prises en charge pour les critères utilisés pour définir les valeurs d’indicateur.

La réponse de Workday à la demande Get_Workers pour la requête ci-dessus inclut le nombre d’enregistrements d’employés et le nombre de pages.

  <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>

Pour récupérer la page suivante du jeu de résultats, la requête Get_Workers suivante spécifie le numéro de page en tant que paramètre dans le 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>

Le service d’approvisionnement Microsoft Entra traite chaque page et itère dans l’ensemble des employés effectifs pendant la synchronisation complète. Pour chaque entrée d’employé importée à partir de Workday :

  • L’expression XPATH est appliquée pour récupérer les valeurs d’attribut de Workday.
  • Les règles de mappage d’attributs et de correspondance sont appliquées.
  • Le service détermine l’opération à effectuer dans la cible (Microsoft Entra ID / Active Directory).

Une fois le traitement terminé, l’horodatage associé au début de la synchronisation complète est enregistré en tant que filigrane. Ce filigrane sert de point de départ pour le cycle de synchronisation incrémentielle.

Synchronisation incrémentielle

Après une synchronisation complète, le service d’approvisionnement Microsoft Entra conserve la valeur LastExecutionTimestamp et l’utilise pour créer des requêtes delta afin de récupérer les modifications incrémentielles. Au cours d’une synchronisation incrémentielle, Microsoft Entra ID envoie les types suivants de requêtes à Workday :

Requête relative aux mises à jour manuelles

La demande Get_Workers suivante interroge les mises à jour manuelles qui se sont produites entre la dernière exécution et l’exécution actuelle.

<!-- 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>

Requête relative aux mises à jour et arrêts avec date d’effet

La demande Get_Workers suivante interroge les mises à jour avec date d’effet qui se sont produites entre la dernière exécution et l’exécution actuelle.

<!-- 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>

Requête relative aux embauches futures

Si l’une des requêtes ci-dessus retourne une embauche future, la demande Get_Workers suivante est utilisée pour extraire des informations sur une nouvelle embauche future. L’attribut WID de la nouvelle embauche est utilisé pour effectuer la recherche, et la date d’effet est définie sur la date et l’heure de l’embauche.

Notes

Les embauches futures dans Workday ont le champ actif défini sur « 0 » et cela est remplacée par la valeur « 1 » à la date d’embauche. Le connecteur permet de concevoir des requêtes pour les informations d’embauche future effectives à la date d’embauche. C’est pourquoi il obtient toujours le profil de Worker au recrutement futur avec le champ actif défini sur « 1 ». Cela vous permet de configurer le profil de Microsoft Entra pour les embauches ultérieures à l’avance avec toutes les informations appropriées préremplies. Si vous souhaitez retarder l’activation du compte de Microsoft Entra pour les futures embauches, utilisez la fonction de transformation 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>

Récupération des attributs de données d’employé

L’API Get_Workers peut retourner différents jeux de données associés à un employé. En fonction des expressions d’API XPATH configurées dans le schéma d’approvisionnement, le service d’approvisionnement Microsoft Entra détermine les jeux de données à récupérer à partir de Workday. En conséquence, les indicateurs Response_Group sont définis dans la demande Get_Workers.

Le tableau fournit des conseils sur la configuration de mappage à utiliser pour récupérer un jeu de données spécifique.

# Entité Workday Incluse par défaut Modèle XPATH à spécifier dans le mappage pour extraire des entités autres que par défaut
1 Personal Data Oui wd:Worker_Data/wd:Personal_Data
2 Employment Data Oui wd:Worker_Data/wd:Employment_Data
3 Additional Job Data Oui wd:Worker_Data/wd:Employment_Data/wd:Worker_Job_Data[@wd:Primary_Job=0]
4 Organization Data Oui wd:Worker_Data/wd:Organization_Data
5 Management Chain Data Oui wd:Worker_Data/wd:Management_Chain_Data
6 Supervisory Organization Oui SUPERVISORY
7 Company Oui COMPANY
8 Business Unit Non BUSINESS_UNIT
9 Business Unit Hierarchy Non BUSINESS_UNIT_HIERARCHY
10 Company Hierarchy Non COMPANY_HIERARCHY
11 Cost Center Non COST_CENTER
12 Cost Center Hierarchy Non COST_CENTER_HIERARCHY
13 Fund Non FUND
14 Fund Hierarchy Non FUND_HIERARCHY
15 Gift Non GIFT
16 Gift Hierarchy Non GIFT_HIERARCHY
17 Grant Non GRANT
18 Grant Hierarchy Non GRANT_HIERARCHY
19 Business Site Hierarchy Non BUSINESS_SITE_HIERARCHY
20 Matrix Organization Non MATRIX
21 Pay Group Non PAY_GROUP
22 Programs Non PROGRAMS
23 Program Hierarchy Non PROGRAM_HIERARCHY
24 Region Non REGION_HIERARCHY
25 Location Hierarchy Non LOCATION_HIERARCHY
26 Account Provisioning Data Non wd:Worker_Data/wd:Account_Provisioning_Data
27 Background Check Data Non wd:Worker_Data/wd:Background_Check_Data
28 Benefit Eligibility Data Non wd:Worker_Data/wd:Benefit_Eligibility_Data
29 Benefit Enrollment Data Non wd:Worker_Data/wd:Benefit_Enrollment_Data
30 Career Data Non wd:Worker_Data/wd:Career_Data
31 Compensation Data Non wd:Worker_Data/wd:Compensation_Data
32 Contingent Worker Tax Authority Data Non wd:Worker_Data/wd:Contingent_Worker_Tax_Authority_Form_Type_Data
33 Development Item Data Non wd:Worker_Data/wd:Development_Item_Data
34 Employee Contracts Data Non wd:Worker_Data/wd:Employee_Contracts_Data
35 Employee Review Data Non wd:Worker_Data/wd:Employee_Review_Data
36 Feedback Received Data Non wd:Worker_Data/wd:Feedback_Received_Data
37 Worker Goal Data Non wd:Worker_Data/wd:Worker_Goal_Data
38 Photo Data Non wd:Worker_Data/wd:Photo_Data
39 Qualification Data Non wd:Worker_Data/wd:Qualification_Data
40 Related Persons Data Non wd:Worker_Data/wd:Related_Persons_Data
41 Role Data Non wd:Worker_Data/wd:Role_Data
42 Skill Data Non wd:Worker_Data/wd:Skill_Data
43 Succession Profile Data Non wd:Worker_Data/wd:Succession_Profile_Data
44 Talent Assessment Data Non wd:Worker_Data/wd:Talent_Assessment_Data
45 User Account Data Non wd:Worker_Data/wd:User_Account_Data
46 Worker Document Data Non wd:Worker_Data/wd:Worker_Document_Data

Notes

Chaque entité Workday figurant dans la table est protégée par une stratégie de sécurité du domaine dans Workday. Si vous ne parvenez pas à récupérer un attribut associé à l’entité après avoir défini le bon XPATH, contactez votre administrateur Workday pour vous assurer que la stratégie appropriée de sécurité du domaine est configurée pour l’utilisateur du système d’intégration associé à l’application de configuration. Par exemple, pour récupérer des données de compétence, un accès Get est requis sur le domaine Workday Données Workday : Compétences et expérience.

Voici quelques exemples de la façon dont vous pouvez étendre l’intégration de Workday pour répondre à des exigences spécifiques.

Exemple 1 : récupération d’informations sur le centre de coûts et le groupe de paie

Supposons que vous souhaitiez récupérer les jeux de données suivants à partir de Workday et les utiliser dans vos règles d’approvisionnement :

  • Centre de coûts
  • Hiérarchie du centre de coûts
  • Groupe de paie

Les jeux de données ci-dessus ne sont pas inclus par défaut. Pour récupérer ces jeux de données :

  1. Connectez-vous au centre d'administration Microsoft Entra au minimum en tant qu’Administrateur d'application.

  2. Accédez à Identité>Applications>Applications d’entreprise.

  3. Sélectionnez votre application d’approvisionnement d’utilisateurs Workday vers Active Directory / Microsoft Entra.

  4. Sélectionnez Provisionnement.

  5. Modifiez les mappages et ouvrez la liste des attributs Workday à partir de la section avancée.

  6. Ajoutez les définitions d’attributs suivantes et marquez-les comme « Obligatoires ». Ces attributs ne sont mappés à aucun attribut dans Active Directory ou Microsoft Entra ID. Ils servent de signaux adressés au connecteur pour récupérer les informations sur le centre de coût, la hiérarchie du centre de coûts et le groupe de paie.

    Nom de l'attribut Expression d’API XPATH
    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()

  7. Une fois que le jeu de données sur le centre de coûts et le groupe de paiement est disponible dans la réponse à la demande Get_Workers, vous pouvez utiliser les valeurs XPATH pour récupérer le nom du centre de coût, le code du centre de coûts et le groupe de paie.

    Nom de l'attribut Expression d’API XPATH
    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()

Exemple 2 : récupération de données sur la qualification et les compétences

Supposons que vous souhaitiez récupérer des certifications associées à un utilisateur. Ces informations sont disponibles dans le jeu de données de qualification. Pour récupérer ce jeu de données dans la réponse Get_Workers, utilisez le XPATH suivant :

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

Exemple 3 : récupération d’affectations de groupe d’approvisionnement

Supposons que vous souhaitiez récupérer les groupes d’approvisionnement attribués à un employé. Ces informations sont disponibles dans le jeu de données d’approvisionnement de compte. Pour récupérer ces données dans la réponse Get_Workers, utilisez le XPATH suivant :

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

Gestion de différents scénarios RH

Cette section décrit comment vous pouvez personnaliser l’application d’approvisionnement pour les scénarios RH suivants :

Prise en charge des conversions de rôle de travail

Cette section décrit la prise en charge du service de provisionnement Microsoft Entra pour les scénarios où un travailleur passe du statut de salarié à temps plein (FTE) à celui de travailleur intérimaire (CW), ou inversement. Selon la façon dont les changements de statut des travailleurs sont traités dans Workday, il existe certaines différences dans les aspects à prendre en compte au moment de l’implémentation.

Scénario 1 : Changement antidaté du statut de salarié à temps plein à celui de travailleur intérimaire, ou inversement

Votre équipe RH peut antidater une transaction de conversion de travailleur dans Workday pour des raisons professionnelles valables. Les exemples incluent le traitement de la paie, la conformité budgétaire, les exigences légales et la gestion des avantages sociaux. Voici un exemple illustrant la gestion du provisionnement pour ce scénario.

  • Nous sommes le 15 janvier 2023 et Jane Doe travaille en tant que salariée occasionnelle. Les RH proposent à Jane un poste à temps plein.
  • Les conditions du changement de contrat de Jane imposent un antidatage de la transaction pour qu’elle s’aligne sur le début du mois en cours. Les RH lancent une transaction antidatée de changement de statut de travailleur dans Workday le 15 janvier 2023, avec une date d’effet au 1er janvier 2023. Il existe désormais deux profils de travailleur dans Workday pour Jane. Le profil de travailleur intérimaire est inactif, alors que le profil de salarié à temps plein est actif.
  • Le service d’approvisionnement Microsoft Entra détecte cette modification dans le journal des transactions Workday le 15 janvier 2023. Le service approvisionne automatiquement les attributs du nouveau profil de salarié à temps plein dans le prochain cycle de synchronisation.
  • Aucun changement n’est nécessaire dans la configuration de l’application de provisionnement pour gérer ce scénario.

Scénario 2 : Le travailleur employé aujourd’hui avec un statut de travailleur intérimaire/salarié à temps plein va passer à un statut de salarié à temps plein/travailleur intérimaire

Ce scénario est similaire au scénario ci-dessus, à ceci près qu’au lieu d’antidater la transaction, les RH effectuent un changement de statut de travailleur qui prend effet immédiatement. Le service d’approvisionnement Microsoft Entra détecte cette modification dans le journal des transactions Workday. Dans le cycle de synchronisation suivant, le service approvisionne automatiquement tous les attributs associés avec un profil FTE actif. Aucun changement n’est nécessaire dans la configuration de l’application de provisionnement pour gérer ce scénario.

Scénario 3 : Le travailleur employé avec un statut de travailleur intérimaire/salarié à temps plein est licencié, mais il revient avec un statut de salarié à temps plein/travailleur intérimaire après un délai important

Il est courant que les travailleurs commencent à travailler dans une entreprise en tant que travailleurs intérimaires, quittent l’entreprise, puis la rejoignent après plusieurs mois en tant que salariés à temps plein. Voici un exemple illustrant la gestion du provisionnement pour ce scénario.

  • Nous sommes le 1er janvier 2023, et John Smith commence à travailler en tant que salarié occasionnel. Dans la mesure où aucun compte AD n’est associé au WorkerID de John (attribut correspondant), le service de provisionnement crée un compte AD et lie le WID (WorkdayID) de travailleur intérimaire de John à son compte AD.
  • Le contrat de John prend fin le 31 janvier 2023. Dans le cycle de provisionnement qui s’exécute après la fin de la journée du 31 janvier, le compte AD de John est désactivé.
  • John postule à un autre poste et décide de rejoindre l’entreprise en tant que salarié à temps plein à compter du 1er mai 2023. Les RH entrent les informations de John sous la forme d’une préembauche le 15 avril 2023. Il existe désormais deux profils de travailleur dans Workday pour John. Le profil de travailleur intérimaire est inactif, alors que le profil de salarié à temps plein est actif. Les deux enregistrements ont le même WorkerID mais des WID distincts.
  • Le 15 avril, durant le cycle incrémentiel, le service de provisionnement Microsoft Entra transfère automatiquement la propriété du compte AD au profil de travail actif. Dans ce cas, elles dissocient le profil de salarié occasionnel du compte AD, puis établissent un nouveau lien entre le profil de salarié actif de John et son compte AD.
  • Aucun changement n’est nécessaire dans la configuration de l’application de provisionnement pour gérer ce scénario.

Scénario 4 : Changement de statut futur, quand le travailleur est un travailleur intérimaire/salarié à temps plein actif

Parfois, un travailleur est déjà un travailleur intérimaire actif, quand les RH lancent une transaction de changement de statut du travailleur pour une date future. Voici un exemple illustrant la gestion du provisionnement pour ce scénario ainsi que les changements de configuration nécessaires à la prise en charge du scénario.

  • Nous sommes le 1er janvier 2023, et John Smith commence à travailler en tant que salarié occasionnel. Dans la mesure où aucun compte AD n’est associé au WorkerID de John (attribut correspondant), le service de provisionnement crée un compte AD et lie le WID (WorkdayID) de travailleur intérimaire de John à son compte AD.

  • Le 15 janvier, les RH lancent une transaction visant à faire passer John du statut de salarié occasionnel à celui de salarié à temps plein avec effet au 1er février 2023.

  • Dans la mesure où le service d’approvisionnement Microsoft Entra traite automatiquement les embauches futures, il traite le nouveau profil de salarié à temps plein de John le 15 janvier, et met à jour son profil dans AD en fonction des détails de l’emploi à temps plein, même s’il est toujours salarié occasionnel.

  • Pour éviter ce comportement et veiller à ce que les détails du profil de salarié à temps plein de John soient approvisionnés le 1er février 2023, effectuez les changements de configuration suivants.

    Modifications de configuration

    1. Contactez votre administrateur Workday pour créer un groupe de provisionnement appelé « Conversions futures ».
    2. Implémentez une logique dans Workday pour ajouter des enregistrements de salarié à temps plein/travailleur intérimaire avec des conversions futures à ce groupe de provisionnement.
    3. Mettez à jour l’application de provisionnement Microsoft Entra pour lire ce groupe de provisionnement. Consultez les instructions fournies ici pour savoir comment récupérer le groupe de provisionnement
    4. Créez un filtre d’étendue dans Microsoft Entra ID pour exclure les profils de travailleur qui font partie de ce groupe de provisionnement.
    5. Dans Workday, implémentez une logique adaptée au cas de figure suivant : une fois que la date de conversion est effective, Workday doit supprimer l’enregistrement approprié de salarié à temps plein/travailleur intérimaire du groupe de provisionnement.
    6. Avec cette configuration, l’enregistrement existant de salarié à temps plein/travailleur intérimaire continue d’être effectif, et le changement de provisionnement a lieu uniquement le jour de la conversion.

Notes

Durant la synchronisation complète initiale, il se peut que vous remarquiez peut-être un comportement se traduisant par le fait que les valeurs d’attribut associées au profil de rôle de travail inactif précédent sont acheminées vers le compte AD des rôles de travail convertis. Il s’agit d’une situation temporaire. À mesure que la synchronisation complète progresse, les valeurs d’attribut sont remplacées par celles du profil de rôle de travail actif. Une fois la synchronisation complète terminée et le travail d’approvisionnement à l’état stable, le profil du rôle de travail actif est toujours sélectionné pendant la synchronisation incrémentielle.

Récupération des affectations de travaux internationales et des détails sur les travaux secondaires

Par défaut, le connecteur Workday récupère les attributs associés au travail principal de l’employé. Le connecteur prend également en charge la récupération de Additional Job Data associées à des affectations de travaux internationales ou à des travaux secondaires.

Utilisez ces étapes pour récupérer les attributs associés aux affectations de travaux internationales :

  1. Définissez l’URL de connexion de Workday de manière à utiliser l’API de service web Workday version 30.0 ou ultérieure. Définissez en conséquence les valeurs XPATH adéquates dans votre application de provisionnement Workday.
  2. Utilisez le sélecteur @wd:Primary_Job=0 sur le nœud Worker_Job_Data pour récupérer l’attribut correct.
    • Exemple 1 : Pour obtenir SecondaryBusinessTitle, utilisez le XPATH wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Worker_Job_Data[@wd:Primary_Job=0]/wd:Position_Data/wd:Business_Title/text()
    • Exemple 2 : Pour obtenir SecondaryBusinessLocation, utilisez le 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

Limitations connues

Cette section répertorie les limitations actuelles et connues que les clients peuvent rencontrer dans leur intégration Workday.

  1. Le connecteur ne prend pas en charge la récupération des champs calculés Workday.
  2. Le connecteur ne prend pas en charge la synchronisation des photos à partir de Workday.
  3. Le connecteur ne prend pas en charge la récupération avancée des workers dont le dernier jour de travail est dû.
  4. Pendant la synchronisation incrémentielle, il peut y avoir un retard lors du traitement de l’événement d’arrêt pour les workers situés dans les régions Asie-Pacifique et Australie/Nouvelle-Zélande.

Étapes suivantes