Configurare l'integrazione semplificata di Workday per employee Self-Service

L'agente Self-Service dipendente si basa su Copilot e usa l'intelligenza artificiale per fornire informazioni rilevanti ai dipendenti e intraprendere azioni sui dati delle risorse umane.

Se l'organizzazione usa un sistema di gestione delle risorse umane, l'agente Self-Service dipendente richiede l'accesso a tale sistema per funzionare in modo più efficace. Questo articolo illustra l'integrazione semplificata di Workday, in cui l'agente Self-Service dipendente si connette a Workday usando l'identità dell'utente connesso tramite una singola connessione OAuth.

Sinossi tecnica

Questo diagramma descrive i componenti di alto livello che costituiscono la soluzione complessiva per l'agente Self-Service dipendente e l'integrazione semplificata di Workday. L'agente Self-Service dipendente si connette a Workday usando una singola connessione OAuth. Gli endpoint REST e SOAP di Workday sono accessibili tramite la stessa connessione e l'identità dell'utente connesso viene usata in fase di esecuzione per ogni chiamata API Workday.

Ruoli diversi devono eseguire varie attività sia per la distribuzione iniziale che per l'operazione in corso. Poiché questa soluzione prevede più piattaforme, è consigliabile leggere la documentazione e comprendere il processo prima di iniziare l'integrazione. Un primo passaggio consiste nell'identificare gli stakeholder per configurare un ambiente per distribuire l'agente Self-Service dipendente.

Prerequisiti

Prerequisiti della sottoscrizione

• Un account utente Microsoft Entra con sottoscrizione attiva
• Sottoscrizione di Workday abilitata per l'accesso Single Sign-On (SSO)

È anche necessario soddisfare i prerequisiti per distribuire l'agente Self-Service dipendente.

Configurare la capacità Copilot Studio

È consigliabile configurare Copilot Studio capacità per monitorare l'utilizzo della capacità dell'agente Self-Service dipendente nel tempo. Altre informazioni sul processo di distribuzione per l'agente Self-Service dipendente.

Requisiti del ruolo di distribuzione

Configurazione dell'infrastruttura per l'integrazione di soluzioni di sistema esterne di terze parti

La maggior parte delle organizzazioni aziendali protegge i sistemi di gestione delle risorse umane e le origini delle conoscenze da reti esterne, in quanto è fondamentale proteggere le informazioni sensibili su dipendenti, organizzazioni, asset di conoscenze e altro ancora.

Integrando questi sistemi aziendali nell'agente employee Self-Service, diventa un'origine più affidabile per fornire informazioni agli utenti. Per integrare questi sistemi, è necessario renderli accessibili all'ambiente Power Platform in cui è ospitato l'agente Self-Service dipendente.

È necessario configurare questi sistemi con gli elenchi consentiti per gli indirizzi IP di origine da cui l'agente Self-Service dipendente è ospitato ed eseguito, ad esempio l'ambiente Power Platform. Per informazioni sul recupero dell'elenco degli intervalli di indirizzi IP da configurare nell'ambiente di rete, vedere la documentazione seguente:

• Informazioni sugli URL generali di Power Platform e sugli intervalli di indirizzi IP.
• Informazioni sugli indirizzi IP in uscita dei connettori gestiti.

Per l'integrazione di Workday, l'agente Self-Service employee usa gli endpoint REST e SOAP di Workday tramite una singola connessione OAuth. Collaborare con il team InfoSec per consentire all'agente Self-Service dipendente di comunicare con entrambi gli endpoint. La maggior parte delle regole del firewall SOAP esistenti copre l'endpoint REST; alcuni clienti potrebbero richiedere una revisione separata.

Se è necessario soddisfare altri requisiti di sicurezza dei dati per lo scambio SOAP e REST, collaborare con gli specialisti della sicurezza per aumentare la sicurezza per i dati in transito.

Configurare l'accesso SSO per Workday con Microsoft Entra

Fare riferimento a questa documentazione per configurare l'accesso Single Sign-On per Workday con Microsoft Entra: Microsoft Entra l'integrazione dell'accesso Single Sign-On (SSO) con Workday.

Configurare il connettore Workday in Microsoft Entra

1. Aprire https://portal.azure.com.
2. Passare a Registrazioni app.
3. Individuare l'applicazione creata per l'installazione di Workday SSO.
4. Si noti l'URI dell'ID applicazione per un secondo momento.
5. Passare a Gestisci>Esporre un'API.
6. Aggiungere un ambito per user_impersonation:
   • Selezionare + Aggiungi un ambito.
   • Nome ambito: user_impersonation
   • Chi può fornire il consenso: amministratori e utenti
   • Compilare i nomi visualizzati e le descrizioni del consenso.
7. In Applicazioni client autorizzate aggiungere l'ID app del connettore Workday seguente: 4e4707ca-5f53-46a6-a819-f7765446e6ff.
8. Assicurarsi che la nuova applicazione client abbia l'ambito user_impersonation aggiunto nel passaggio precedente. In Autorizzazioni API aggiungere le openidautorizzazioni , profilee User.Read Microsoft Graph:
   • Selezionare + Aggiungi un'autorizzazione.
   • Selezionare Microsoft Graph.
   • Scegliere Autorizzazione delegata.
   • Selezionare openid, profilee User.Read.
9. Selezionare Concedi consenso amministratore.

Configurare Workday per l'agente Self-Service dipendente

Le attività di configurazione seguenti devono essere eseguite in Workday da un amministratore di Workday:

1. Creare la chiave pubblica X.509
2. Modificare la configurazione del tenant - Sicurezza
3. Gestire i criteri di autenticazione
4. Registrare il client API

Attività 1: Creare la chiave pubblica X.509

Usare la chiave pubblica X.509 fornita da Microsoft Entra per creare una nuova chiave in Workday.

Attività 2: Modificare la configurazione del tenant - Sicurezza

1. Configurare l'URL di reindirizzamento.

   

2. Abilitare i client OAuth 2.0 e l'autenticazione SAML scegliendo Sì nelle sezioni Client OAuth 2.0 abilitati e Abilita autenticazione SAML .

3. Configurare il provider di identità SAML. Verificare i campi seguenti se l'accesso SSO è già configurato per Workday con Microsoft Entra:

Attività 3: Gestire i criteri di autenticazione

Modificare i criteri di autenticazione per il tenant di Workday. Se non sono ancora configurati criteri di autenticazione, crearne uno per primo.

1. Eseguire il report Gestisci criteri di autenticazione. Selezionare quindi il pulsante Modifica per i criteri per il tenant.
2. Definire l'ambito dei criteri di autenticazione per l'identità client OAuth usata dall'agente Self-Service dipendente. Gli utenti del sistema di integrazione non vengono usati nella configurazione semplificata.
3. Selezionare SAML come Tipo di autenticazione consentito. Se sono in uso entrambi i metodi SAML e Password nome utente, consentire entrambi.
4. Assicurarsi di avere l'opzione SAML abilitata per il gruppo di sicurezza Tutti i dipendenti , insieme a qualsiasi altro metodo necessario nell'ambiente Workday.
5. Eseguire l'attività Attiva tutte le modifiche ai criteri di autenticazione in sospeso per attivare tutte le modifiche ai criteri di autenticazione in sospeso. Questo passaggio è necessario per finalizzare tutte le modifiche ai criteri di autenticazione.

Attività 4: Registrare il client API

Questa attività è necessaria per richiamare le API Workday da un sistema esterno, ad esempio l'agente employee Self-Service.

Accedere a Workday come amministratore che può gestire i client API. Nella ricerca globale Workday immettere register api client (Registra client API) e quindi selezionare Register API Client (Registra client API) nei risultati.

Quando si configura l'ambito (aree funzionali) nel client API, aggiungere le aree funzionali seguenti necessarie per la configurazione semplificata di Employee Self-Service:

• Retribuzioni principali
• Organizzazioni e ruoli
• Personale
• Time Off and Leave

Queste quattro aree funzionali sono l'ambito minimo necessario per l'esperienza predefinita employee Self-Service. Se si prevede di estendere Self-Service dipendente con argomenti o flussi personalizzati che usano domini Workday aggiuntivi (ad esempio, Recruiting, Learning o Spese), aggiungere anche le aree funzionali corrispondenti.

Impostare Includi ambito di proprietà workday su Sì in modo che i servizi Web di proprietà di Workday (ad esempio, l'endpoint REST /workers/me usato per la ricerca del contesto utente) siano inclusi insieme alle aree funzionali selezionate.

L'ID client e gli endpoint generati automaticamente dopo la creazione del client devono essere condivisi in modo sicuro con Microsoft Entra Administrators per la configurazione Microsoft Entra per l'agente Self-Service dipendente.

Installare il pacchetto di estensione Workday per l'agente Self-Service dipendente

L'agente Self-Service dipendente è progettato per avere pacchetti di estensione separati per ogni soluzione di sistema esterno di terze parti. È necessario installare il pacchetto di estensione prima di avviare configurazioni o personalizzazioni.

I passaggi seguenti sono necessari per installare e abilitare il pacchetto di estensione Workday.

Passaggio 1: Installare l'estensione

1. Aprire l'agente Self-Service dipendente in Copilot Studio.
2. Passare a Impostazioni.
3. Selezionare Personalizza nel riquadro di spostamento a sinistra.
4. Selezionare Workday e scegliere Installa. I clienti esistenti possono aggiornare un pacchetto installato selezionando Workday in Impostazioni>Personalizza e scegliendo Aggiorna. L'aggiornamento del pacchetto non influisce sull'agente di produzione fino a quando non lo si accetta.
5. Quando richiesto, aggiornare le connessioni come descritto selezionando i puntini di sospensione (...) sul lato destro per ogni connessione.

Passaggio 2: Configurare l'autenticazione della connessione

Attualmente, il connettore Workday in Power Platform supporta tre tipi di autenticazione:

• Basic
• Microsoft Entra ID integrato
• Microsoft Entra ID integrato con Gestione API

Questo articolo illustra come configurare il metodo di autenticazione integrata Microsoft Entra ID. Per eseguire questa configurazione, è necessario completare la configurazione dell'accesso Single Sign-On.

Quando si installa il connettore Workday, il primo passaggio consiste nel configurare le connessioni usando il modulo . Compilare i campi seguenti.

MICROSOFT ENTRA URL risorsa (URI ID applicazione)

registrazione dell'app di Microsoft Entra creata per l'accesso Single Sign-On di Workday. Informazioni su come accedere alle registrazioni delle app.

1. Selezionare Tutte le applicazioni.
2. Scegliere l'applicazione corretta creata per Workday SSO.
3. Nella sezione Panoramica usare l'URI ID applicazione nella scheda Informazioni di base .

URL del token OAuth workday e ID client

Le impostazioni client dell'API Workday hanno l'URL del token OAuth.

1. Accedere a Workday con privilegi per visualizzare il client API.
2. Identificare la voce client API corretta dalla tabella e aprirla (creata durante la configurazione dell'accesso SSO in Modifica configurazione tenant - sicurezza in Workday).
3. Nella pagina Visualizza client API cercare Endpoint token.
4. Il valore per l'ID client viene visualizzato sopra l'endpoint del token.

SOAP base URL

Il report Servizi Web pubblici workday fornisce l'URL di base SOAP. La configurazione semplificata non usa Reports as a Service (RaaS), quindi seguire questa procedura per trovare l'URL dell'endpoint SOAP.

1. Nella barra di ricerca di Workday immettere Servizi Web pubblici e quindi aprire il report Servizi Web pubblici .

   

2. Individuare il servizio Web necessario, ad esempio Risorse umane, Personale o Recruiting. In questo esempio vengono usate le risorse umane (public).

3. Selezionare il menu Azioni correlate (tre punti) accanto al servizio Web e quindi selezionare Visualizzazione servizio> WebWSDL.

   

4. Quando si apre la pagina WSDL, cercare soapbind:address.

5. Copiare il valore dell'attributo location nell'elemento soapbind:address . Questo valore è l'URL dell'endpoint SOAP da usare per l'integrazione.

   

Il location valore ha il formato seguente:

https://<tenant>/ccx/service/<service_name>/<version>

Workday REST base URL

L'URL di base REST di Workday viene esposto nella stessa pagina di visualizzazione client dell'API Workday usata per recuperare l'URL del token OAuth e l'ID client. Specificare l'URL di base REST nella configurazione della connessione. Questo campo è un nuovo campo per l'installazione semplificata.

Copiare il valore dell'endpoint DELL'API REST di Workday quando viene visualizzato da Workday, ovvero l'host e il percorso variano in base alla distribuzione di Workday, quindi non ricostruire o creare modelli dell'URL manualmente. Quindi tagliare il valore copiato in modo che termini in corrispondenza di /api. Rimuovere tutti gli elementi dopo /api , ad esempio il suffisso del tenant o qualsiasi /v1 percorso di risorsa o aggiunto da Workday. Il campo URL di base REST prevede che l'endpoint sia solo /api . Se si lascia il percorso finale in , il flusso semplificato non riesce in modo invisibile all'utente.

Passaggio 3: Configurare le connessioni

Durante il processo di installazione del Pacchetto di estensione Workday, vengono richieste le configurazioni di connessione seguenti:

Assicurarsi che ogni connessione sia configurata in modo esplicito con il proprio account, anche se lo stato della connessione potrebbe diventare verde dopo la prima configurazione della connessione.

Passaggio 4: Attivare Consenti l'autorizzazione per condividere i parametri

Nella connessione Workday aprire la scheda Parametri di connessione e impostare Consenti l'autorizzazione per condividere i parametri su Attivato. Verificare che tutti i campi dei parametri (incluso l'URL di base REST) siano popolati e quindi selezionare Salva.

Passaggio 5: Verificare che i flussi workday siano attivati

1. Aprire la soluzione Workday dalla pagina Soluzioni.
2. Selezionare Flussi cloud dalla barra laterale e verificare che entrambi i flussi di lavoro siano attivati.
3. Se i flussi cloud non sono attivati, selezionare i nomi visualizzati per aprire il flusso cloud e selezionare Attiva sulla barra degli strumenti.

Passaggio 6: Configurare l'argomento del contesto utente

Verificare che l'argomento di contesto utente sia impostato sulla versione V2. In Microsoft Copilot Studio passare ad ArgomentiHR/IT> di Agents> ESSe aprire l'argomento [Amministrazione] - Contesto utente - Configurazione. Nel nodo Argomento controllare l'argomento a cui si fa riferimento:

• Se è già Workday [System] - 1: Imposta contesto utente V2, non è necessaria alcuna modifica.
• In caso contrario, selezionare il riferimento all'argomento esistente, scegliere Seleziona un argomento, cercare v2e quindi selezionare Workday [Sistema] - 1: Imposta contesto utente V2. Salvare l'argomento.

Per altre informazioni sulle variabili di contesto utente usate dall'agente e su come farvi riferimento nell'agente, vedere Progettare le procedure consigliate per l'agente Self-Service dipendente.

Passaggio 7: Risoluzione delle identità per i tenant non UPN

Workday usa un provider di identità (IdP) per l'accesso. La configurazione semplificata funziona quando l'IDP di Workday viene Microsoft Entra ID direttamente o un IDP di terze parti con cui Microsoft Entra è federato. Queste topologie corrispondono al Entra federato con un IdP di terze parti basato sul cloud e non Entra federato con righe IdP di terze parti nella matrice di autenticazione workday nei prerequisiti di employee Self-Service.

Per i tenant in cui Microsoft Entra UPN corrispondono agli ID di accesso di Workday, non sono necessarie altre azioni. Il percorso di autenticazione integrata Microsoft Entra ID risolve automaticamente l'identità dell'utente connesso.

Per i tenant in cui Microsoft Entra UPN non corrispondono agli ID di accesso di Workday e l'IDP di Workday è un IDP di terze parti con cui Microsoft Entra è federato, Workday risolve l'identità dell'utente dalle attestazioni SAML ricevute dall'IDP di terze parti. Un argomento di mapping di runtime non UPN personalizzato non è necessario per la maggior parte delle distribuzioni.

Personalizzazioni per l'integrazione di Workday

Usare Modelli per completare le personalizzazioni necessarie per l'integrazione di Workday. I modelli sono oggetti XML che definiscono le informazioni di connessione e le informazioni sull'estrazione dei dati. Qui si usano i modelli per recuperare informazioni da Workday.

Modelli inclusi nella soluzione

Di seguito sono elencati i modelli seguenti e gli argomenti copilot associati:

Panoramica della struttura dei modelli

I modelli vengono suddivisi in due componenti chiave: scenario e requestTemplates.

<WorkdayEntityConfigurationTemplate>
    <Scenario name="GetJobTaxonomy">
        <apiRequests>
            <apiRequest>
                <authType>User</authType>
                <endpoint>...
                </endpoint>
                <requestParameters>...
                </requestParameters>
                <responseProperties>...
                </responseProperties>
            </apiRequest>
        </apiRequests>
    </Scenario>
    <RequestTemplates>
        <RequestTemplate name="Template_GetWorkerRequest">...
        </RequestTemplate>
    </RequestTemplates>
</WorkdayEntityConfigurationTemplate>

Scenario

L'oggetto scenario è un oggetto XML utilizzato per gestire scenari specifici dei clienti nei flussi dell'agente employee Self-Service. Il scenario nodo XML contiene un name attributo che descrive lo scenario da una prospettiva generale. All'interno dell'oggetto scenario sono apiRequests presenti etichette e .

apiRequest

I apiRequest nodi contengono informazioni che comunicano al flusso dell'API Workday come richiedere i dati.

<apiRequest>
    <authType>User</authType>
    <endpoint>
        <request>msdyn_HRWorkdayHCMManagerJobTaxonomy_GetWorkerRequest</request>
        <serviceName>Human_Resources</serviceName>
        <version>v41.0</version>
    </endpoint>
    <requestParameters>
        <parameter>
            <name>Include_Roles</name>
            <value>true</value>
        </parameter>
    </requestParameters>
    <responseProperties>
        <property>
            <extractPath>//*[local-name()='Role_Assigner_Reference']/*[local-name()='ID' and @*[local-name()='type']='Organization_Reference_ID']/text()</extractPath>
            <key>OrganizationReferenceID</key>
        </property>
    </responseProperties>
</apiRequest>

requestTemplates

I modelli di richiesta sono oggetti XML che definiscono il corpo della richiesta che viene inviato a Copilot. Questi modelli contengono spesso valori sostituibili compilati come parte del flusso. I valori sostituibili vengono visualizzati tra parentesi {example_replaceable_value}graffe.

<requestTemplates>
    <requestTemplate name="msdyn_HRWorkdayHCMManagerJobTaxonomy_GetWorkerRequest">
        <bsvc:Get_Workers_Request xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="v41.0">
            <bsvc:Request_References bsvc:Skip_Non_Existing_Instances="false" bsvc:Ignore_Invalid_References="true">
                <bsvc:Worker_Reference bsvc:Descriptor="Employee_ID">
                    <bsvc:ID bsvc:type="Employee_ID">{Employee_ID}</bsvc:ID>
                </bsvc:Worker_Reference>
            </bsvc:Request_References>
            <bsvc:Response_Filter>
                <bsvc:As_Of_Effective_Date>{As_Of_Effective_Date}</bsvc:As_Of_Effective_Date>
            </bsvc:Response_Filter>
            <bsvc:Response_Group>
                <bsvc:Include_Roles>true</bsvc:Include_Roles>
            </bsvc:Response_Group>
        </bsvc:Get_Workers_Request>
    </requestTemplate>
</requestTemplates>

L'esempio seguente è un modello di esempio completo:

<?xml version="1.0" encoding="utf-8" ?>
<workdayEntityConfigurationTemplate>
    <scenario name="GetJobTaxonomy">
        <apiRequests>
            <apiRequest>
                <authType>User</authType>
                    <endpoint>
                        <request>Template_GetWorkerRequest</request>
                        <serviceName>Human_Resources</serviceName>
                        <version>v42.0</version>
                    </endpoint>
                    <responseProperties>
                        <property>
                            <extractPath>//*[local-name()="Position_Title"]/text()</extractPath>
                            <key>JobTitle</key>
                        </property>
                        <property>
                            <extractPath>//*[local-name()="Business_Title"]/text()</extractPath>
                            <key>BusinessTitle</key>
                        </property>
                        <property>
                            <extractPath>//*[local-name()="Job_Profile_Name"]/text()</extractPath>
                            <key>JobProfile</key>
                        </property>
                        <property>
                            <extractPath>//*[local-name()='Job_Profile_Summary_Data']/*[local-name()='Job_Family_Reference']/*[local-name()='ID' and @*[local-name()='type']='Job_Family_ID']/text()</extractPath>
                            <key>JobFamilyId</key>
                        </property>
                    </responseProperties>
            </apiRequest>
        </apiRequests>
    </scenario>
<requestTemplates>
    <requestTemplate name="Template_GetWorkerRequest">
        <bsvc:Get_Workers_Request xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="v41.0">
            <bsvc:Request_References bsvc:Skip_Non_Existing_Instances="false" bsvc:Ignore_Invalid_References="true">
                <bsvc:Worker_Reference bsvc:Descriptor="Employee_ID">
                    <bsvc:ID bsvc:type="Employee_ID">{Employee_ID}</bsvc:ID>
                </bsvc:Worker_Reference>
            </bsvc:Request_References>
            <bsvc:Response_Filter>
                <bsvc:As_Of_Effective_Date>{As_Of_Effective_Date}</bsvc:As_Of_Effective_Date>
            </bsvc:Response_Filter>
            <bsvc:Response_Group>
                <bsvc:Include_Employment_Information>true</bsvc:Include_Employment_Information>
            </bsvc:Response_Group>
        </bsvc:Get_Workers_Request>
    </requestTemplate>
</requestTemplates>
</workdayEntityConfigurationTemplate>

Personalizzare i dati di riferimento di Workday

La soluzione Workday viene fornita con 17 set di dati di riferimento, ognuno archiviato come record di configurazione del modello in Dataverse. Questi record vengono sottoposti a seeding da un tenant workday canonico. Se il tenant di Workday ha personalizzato uno di questi cataloghi, allineare la configurazione del modello corrispondente al tenant.

Quando personalizzare i dati di riferimento

Personalizzare i dati di riferimento quando si verifica una delle operazioni seguenti:

• Un argomento che restituisce un elenco (ad esempio, "mostrami i miei passaporti", "mostrami i miei visti" o "mostrami la mia istruzione") restituisce un risultato vuoto o restituisce etichette che sembrano sbagliate per il tenant.
• Un'operazione di scrittura workday restituisce un Invalid_Reference_ID errore. Questo errore indica che l'agente ha inviato un ID riferimento che il tenant di Workday non riconosce.
• Il team HRIS di Workday ha confermato che il tenant usa ID di riferimento personalizzati per uno o più tipi elencati nella tabella seguente.

Se non vengono visualizzati errori e tutti i valori sono corretti, non è necessario personalizzare i dati di riferimento.

I 17 record di dati di riferimento

Ogni set di dati di riferimento viene archiviato nella tabella Employee Self-Service Template Configuration (msdyn_employeeselfservicetemplateconfig). Nella tabella seguente sono elencati i record, insieme agli argomenti dell'agente che li utilizzano.

Trovare i valori corretti in Workday

L'elenco autorevole per ogni tipo di riferimento si trova in Workday, dietro l'attività Gestisci ID di riferimento . Per esportare l'elenco canonico:

1. Accedere a Workday come utente con accesso alla configurazione dell'integrazione. Questo utente è in genere un amministratore di Workday o un utente del team HRIS.
2. Nella barra di ricerca di Workday immettere Mantieni ID riferimento ed eseguire l'attività.
3. Nel prompt visualizzato selezionare il tipo di ID riferimento che si desidera convalidare. I nomi dei tipi di ID riferimento in Workday sono mappati direttamente ai record della tabella precedente. Ad esempio:
   • Il tipo di ID Passport viene mappato a msdyn_HRWorkdayHCMReferenceData_PassportIdType.
   • Il tipo di ID nazionale è mappato a msdyn_HRWorkdayHCMReferenceData_NationalIdType.
   • Il tipo di ID visa è mappato a msdyn_HRWorkdayHCMReferenceData_VisaIdType.
   • Degree esegue il mapping a msdyn_HRWorkdayHCMReferenceData_Degree.
   • Il linguaggio esegue il mapping a msdyn_HRWorkdayHCMReferenceData_Language.

Workday restituisce l'elenco di ID di riferimento configurati nel tenant. La colonna ID riferimento è il valore usato come chiave. La colonna Nome o Descrizione è il valore usato come etichetta di visualizzazione.

Le attività workday alternative restituiscono gli stessi dati e potrebbero essere più veloci da accedere, a seconda del profilo di sicurezza:

• Visualizza ID di riferimento: visualizzazione di sola lettura degli stessi elenchi, con accesso più ampio rispetto a Mantieni ID di riferimento.
• Mantieni linguaggi, Gestisci funzionalità del linguaggio e Mantieni le proficienze del linguaggio: ogni attività espone gli stessi ID di riferimento con ambito al tipo di riferimento del linguaggio pertinente.

Se il tenant di Workday ha personalizzato in modo significativo questi cataloghi o usa una configurazione di identità di terze parti, chiedere al team di Workday HRIS di esportare gli elenchi.

Modificare un record di dati di riferimento

Dopo aver ottenuto l'elenco autorevole da Workday, modificare il record corrispondente in Dataverse. Per visualizzare e modificare questi record, è necessario il ruolo di sicurezza di Environment Maker nell'ambiente Power Platform.

1. Nel portale di Power Apps Maker aprire Tabelle e selezionare Employee Self-Service Template Configuration (Configurazione modello Self-Service dipendente).

2. Filtrare i record in base alla colonna Nome univoco . Immettere msdyn_HRWorkdayHCMReferenceData_ per visualizzare tutti i 17 record.

3. Aprire il record che corrisponde al tipo di riferimento da aggiornare.

4. Aprire la colonna Valore . Il codice XML è simile all'esempio seguente:

   <workdayEntityConfigurationTemplate>
     <scenario name="HRWorkdayHCMReferenceData_PassportIdType">
       <seedData type="Passport_ID_Type_ID" count="42">
         <i k="Passport_ID_Type_USA" v="United States Passport"/>
         <i k="Passport_ID_Type_GBR" v="United Kingdom Passport"/>
       </seedData>
     </scenario>
   </workdayEntityConfigurationTemplate>
   

   L'attributo k in ogni <i> elemento è l'ID riferimento di Workday inviato dall'agente a Workday durante le operazioni di scrittura. L'attributo v è l'etichetta di visualizzazione visualizzata dall'agente all'utente finale. Entrambi devono corrispondere a quanto accettato da Workday.

Per ogni elemento nell'elenco, confrontare con l'esportazione workday:

• Se un k valore non viene visualizzato nell'elenco Workday, l'agente non riesce a scrivere tale valore con un Invalid_Reference_ID errore. Aggiornare l'attributo k a un valore esistente nel tenant di Workday oppure rimuovere la voce se non è applicabile.
• Se nella configurazione del modello manca un ID riferimento workday, gli utenti finali non lo vedono nella selezione agente. Aggiungere una nuova voce nel modulo <i k="YourReferenceId" v="Display label"/> all'interno del <seedData> blocco .
• Se un'etichetta v non è aggiornata o non corrisponde alle convenzioni della lingua locale, aggiornare l'attributo v . L'etichetta è di sola visualizzazione e non viene rispedita a Workday.

Salvare il record. La modifica ha effetto sulla chiamata dell'agente successiva. Non è necessario riavviare un flusso o ripubblicare una soluzione.

Eseguire il backup delle personalizzazioni

Le personalizzazioni dei record di configurazione dei modelli vengono reimpostate quando viene aggiornata la soluzione Workday, perché questi record vengono forniti come parte del pacchetto gestito. Prima di qualsiasi aggiornamento futuro:

1. Aprire ogni record personalizzato in msdyn_HRWorkdayHCMReferenceData_*.
2. Copiare il contenuto completo della colonna Valore (l'intero blocco XML) in un percorso sicuro. Un documento di SharePoint nel tenant, un file con versione nel repository runbook o una cassetta postale del team sicura sono tutte scelte ragionevoli.
3. Al termine dell'aggiornamento, incollare nuovamente il codice XML salvato nella colonna Valore del record corrispondente.

Finché non è disponibile un approccio di conservazione della personalizzazione, questo passaggio di backup e ripristino è il modello supportato.

Articoli correlati

• Aggiornare la soluzione Workday per Employee Self-Service
• Aggiornare un'integrazione workday esistente alla configurazione semplificata
• Creazione di report per l'integrazione di Workday
• Introduzione a Employee Self-Service
• Integrare ServiceNow con la distribuzione employee Self-Service
• Integrare Workday con la distribuzione employee Self-Service (riferimento ISU e RaaS legacy)