Comment Microsoft Entra provisionnement s’intègre à Workday

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 :

• Approvisionnement d’utilisateurs de Workday vers Active Directory local
• Approvisionnement des utilisateurs de Workday vers Microsoft Entra
• Workday Writeback

Cet article explique le fonctionnement de l’intégration et la manière dont 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 client 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 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 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 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 client Workday. Dans certains scénarios d’intégration, vous souhaiterez peut-être limiter l’accès. Par exemple, vous voudrez 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 concept de 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 client 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 client 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 de 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 des 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 à 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 sur 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’attribut et de correspondance sont appliquées et
• 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.

Fonctionnement de la 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
• Requête relative aux mises à jour et arrêts avec date d’effet
• Requête relative aux embauches futures

Requête relative aux mises à jour manuelles

La requête 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 requête 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 requête 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.

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

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ût 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ût
• 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 Approvisionnement.

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ût 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ût et le groupe de paie 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ût 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 changements de statut des employés
• Récupération des affectations de travaux internationales et des détails sur les travaux secondaires

Prise en charge des changements de statut des employés

Cette section décrit la prise en charge du service d’approvisionnement Microsoft Entra pour les scénarios où un employé 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 employés 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 de statut antidaté de salarié à temps plein à celui de travailleur intérimaire, ou inversement
• Scénario 2 : L’employé avec aujourd’hui un statut de travailleur intérimaire/salarié à temps plein va passer à un statut de salarié à temps plein/travailleur intérimaire
• Scénario 3 : L’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
• Scénario 4 : Changement de statut futur, quand l’employé est un travailleur intérimaire/salarié à temps plein actif

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 changement de statut d’un employé 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 de l’approvisionnement pour ce scénario.

• Nous sommes le 15 janvier 2023 et Jane Doe travaille en tant qu’employé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 l’aligner sur le début du mois en cours. Les RH lancent une transaction antidatée de changement de statut d’employé dans Workday le 15 janvier 2023, avec une date d’effet au 1er janvier 2023. Il existe désormais deux profils d’employé 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 FTE dans le prochain cycle de synchronisation.
• Aucun changement n’est nécessaire dans la configuration de l’application d’approvisionnement 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 d’employé 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 d’approvisionnement 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 employés 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 d’approvisionnement pour ce scénario.

• Nous sommes le 1er janvier 2023, et John Smith commence à travailler en tant que travailleur intérimaire. Dans la mesure où aucun compte AD n’est associé au WorkerID de John (attribut correspondant), le service d’approvisionnement 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 d’approvisionnement 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 d’employé 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 d’approvisionnement Microsoft Entra transfère automatiquement la propriété du compte AD au profil d’employé actif. Dans ce cas, elles dissocient le profil de travailleur intérimaire du compte AD, puis établissent un nouveau lien entre le profil d’employé actif de John et son compte AD.
• Aucun changement n’est nécessaire dans la configuration de l’application d’approvisionnement pour gérer ce scénario.

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

Parfois, un employé est déjà un travailleur intérimaire actif, quand les RH lancent une transaction de changement de statut d’employé pour une date future. Voici un exemple illustrant la gestion de l’approvisionnement 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 travailleur intérimaire. Dans la mesure où aucun compte AD n’est associé au WorkerID de John (attribut correspondant), le service d’approvisionnement 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 travailleur intérimaire à 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 travailleur intérimaire.

• Pour éviter ce comportement et veiller à ce que les détails de FTE 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 d’approvisionnement appelé « Conversions futures ».
  2. Implémentez une logique dans Workday pour ajouter des enregistrements de salarié à temps plein/travailleur intérimaire avec des changements de statut futurs à ce groupe d’approvisionnement.
  3. Mettez à jour l’application d’approvisionnement Microsoft Entra pour lire ce groupe d’approvisionnement. Consultez les instructions fournies ici pour savoir comment récupérer le groupe d’approvisionnement
  4. Créez un filtre d’étendue dans Microsoft Entra ID pour exclure les profils d’employé qui font partie de ce groupe d’approvisionnement.
  5. Dans Workday, implémentez une logique adaptée au cas de figure suivant : une fois que la date de changement de statut est effective, Workday doit supprimer l’enregistrement approprié de salarié à temps plein/travailleur intérimaire du groupe d’approvisionnement.
  6. Avec cette configuration, l’enregistrement existant de salarié à temps plein/travailleur intérimaire continue d’être effectif, et le changement d’approvisionnement a lieu uniquement le jour du changement de statut.

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 d’approvisionnement 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 employés 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 employés situés dans les régions Asie-Pacifique et Australie/Nouvelle-Zélande.

Étapes suivantes

• Découvrez comment configurer l’approvisionnement de Workday vers Active Directory
• Découvrez comment configurer l’écriture différée dans Workday
• En savoir plus sur les attributs Workday pris en charge pour l'approvisionnement entrant