Einrichten der vereinfachten Workday-Integration für Employee Self-Service

Der Mitarbeiter-Self-Service-Agent basiert auf Copilot und verwendet KI, um den Mitarbeitern relevante Informationen bereitzustellen und Maßnahmen für ihre PERSONALdaten zu ergreifen.

Wenn Ihr organization ein Personalverwaltungssystem verwendet, benötigt der Mitarbeiter-Self-Service-Agent Zugriff auf dieses System, um am effektivsten zu funktionieren. Dieser Artikel führt Sie durch die vereinfachte Workday-Integration, bei der der Mitarbeiter-Self-Service-Agent eine Verbindung mit Workday über die Identität des angemeldeten Benutzers über eine einzelne OAuth-Verbindung herstellt.

Technische Zusammenfassung

Dieses Diagramm zeigt die allgemeinen Komponenten, die die Gesamtlösung für den Mitarbeiter-Self-Service-Agent und die vereinfachte Workday-Integration bilden. Der Mitarbeiter-Self-Service-Agent stellt über eine einzelne OAuth-Verbindung eine Verbindung mit Workday her. Der Zugriff auf Workday-REST- und SOAP-Endpunkte erfolgt über dieselbe Verbindung, und die Identität des angemeldeten Benutzers wird zur Laufzeit für jeden Workday-API-Aufruf verwendet.

Unterschiedliche Rollen müssen verschiedene Aktivitäten sowohl für die erste Bereitstellung als auch für den laufenden Betrieb ausführen. Da diese Lösung mehrere Plattformen umfasst, empfehlen wir Ihnen, die Dokumentation zu lesen und den Prozess zu verstehen, bevor Sie mit der Integration beginnen. Ein erster Schritt besteht darin, Projektbeteiligte zu identifizieren, die eine Umgebung zum Bereitstellen des Mitarbeiter-Self-Service-Agents einrichten.

Voraussetzungen

Abonnementvoraussetzungen

• Ein Microsoft Entra Benutzerkonto mit aktivem Abonnement
• Workday-Abonnement, für das einmaliges Anmelden (Single Sign-On, SSO) aktiviert ist

Außerdem müssen Sie die Voraussetzungen für die Bereitstellung des Mitarbeiter-Self-Service-Agents erfüllen.

Einrichten Copilot Studio Kapazität

Es wird empfohlen, Copilot Studio Kapazität einzurichten, um die Kapazitätsnutzung des Mitarbeiter-Self-Service-Agents im Laufe der Zeit zu überwachen. Erfahren Sie mehr über den Bereitstellungsprozess für den Mitarbeiter-Self-Service-Agent.

Anforderungen für Bereitstellungsrollen

Infrastruktureinrichtung für die Integration externer Systemlösungen von Drittanbietern

Die meisten Unternehmensorganisationen schützen ihre Personalverwaltungssysteme und Wissensquellen aus externen Netzwerken, da es wichtig ist, vertrauliche Informationen über Mitarbeiter, Organisationen, Wissensressourcen und vieles mehr zu schützen.

Wenn Sie diese Unternehmenssysteme in den Mitarbeiter-Self-Service-Agent integrieren, wird dies zu einer zuverlässigeren Quelle für die Bereitstellung von Informationen für Ihre Benutzer. Um diese Systeme zu integrieren, müssen Sie sie für die Power Platform-Umgebung zugänglich machen, in der der Mitarbeiter-Self-Service-Agent gehostet wird.

Sie müssen diese Systeme mit Zulassungslisten für die Quell-IP-Adressen konfigurieren, von denen aus der Mitarbeiter-Self-Service-Agent gehostet und ausgeführt wird, z. B. die Power Platform-Umgebung. Informationen zum Abrufen der Liste der IP-Adressbereiche, die in der Netzwerkumgebung konfiguriert werden sollen, finden Sie in der folgenden Dokumentation:

• Erfahren Sie mehr über die allgemeinen URLs und IP-Adressbereiche von Power Platform.
• Erfahren Sie mehr über ausgehende IP-Adressen von verwalteten Connectors.

Für die Workday-Integration verwendet der Mitarbeiter-Self-Service-Agent die Workday-REST- und SOAP-Endpunkte über eine einzelne OAuth-Verbindung. Arbeiten Sie mit Ihrem InfoSec-Team zusammen, um den Mitarbeiter-Self-Service-Agent für die Kommunikation mit beiden Endpunkten auf die Zulassungsliste zu setzen. Die meisten vorhandenen SOAP-Firewallregeln decken den REST-Endpunkt ab. einige Kunden benötigen möglicherweise eine separate Überprüfung.

Wenn weitere Datensicherheitsanforderungen für SOAP- und REST-Austausch erfüllt werden müssen, arbeiten Sie mit Ihren Sicherheitsexperten zusammen, um die Sicherheit für Daten während der Übertragung zu erhöhen.

Einrichten des einmaligen Anmeldens für Workday mit Microsoft Entra

Informationen zum Einrichten des einmaligen Anmeldens für Workday mit Microsoft Entra: Microsoft Entra Integration des einmaligen Anmeldens (Single Sign-On, SSO) mit Workday finden Sie in dieser Dokumentation.

Einrichten des Workday-Connectors in Microsoft Entra

1. Öffnen Sie https://portal.azure.com.
2. Navigieren Sie zu App-Registrierungen.
3. Suchen Sie die Anwendung, die für das Workday SSO-Setup erstellt wurde.
4. Notieren Sie sich den Anwendungs-ID-URI für einen späteren Zeitpunkt.
5. Wechseln Sie zu Verwalten>Eine API verfügbar machen.
6. Fügen Sie einen Bereich für user_impersonationhinzu:
   • Wählen Sie + Bereich hinzufügen aus.
   • Bereichsname: user_impersonation
   • Wer darf einwilligen?: Administratoren und Benutzer
   • Geben Sie Die Namen und Beschreibungen der Zustimmungsanzeige ein.
7. Fügen Sie unter Autorisierte Clientanwendungen die folgende Workday-Connector-App-ID hinzu: 4e4707ca-5f53-46a6-a819-f7765446e6ff.
8. Stellen Sie sicher, dass für die neue Clientanwendung der user_impersonation Bereich im vorherigen Schritt hinzugefügt wurde. Fügen Sie unter API-Berechtigungen die openidMicrosoft Graph-Berechtigungen , profileund User.Read hinzu:
   • Wählen Sie + Berechtigung hinzufügen aus.
   • Wählen Sie Microsoft Graph aus.
   • Wählen Sie Delegierte Berechtigung aus.
   • Wählen Sie , profileund User.Readausopenid.
9. Wählen Sie Administratoreinwilligung erteilen aus.

Konfigurieren von Workday für den Mitarbeiter-Self-Service-Agent

Die folgenden Konfigurationsaufgaben müssen in Workday von einem Workday-Administrator ausgeführt werden:

1. Erstellen des öffentlichen X.509-Schlüssels
2. Bearbeiten des Mandantensetups – Sicherheit
3. Verwalten von Authentifizierungsrichtlinien
4. Registrieren des API-Clients

Aufgabe 1: Erstellen des öffentlichen X.509-Schlüssels

Verwenden Sie den von Microsoft Entra bereitgestellten öffentlichen X.509-Schlüssel, um einen neuen Schlüssel in Workday zu erstellen.

Aufgabe 2: Bearbeiten der Mandanteneinrichtung – Sicherheit

1. Konfigurieren Sie Ihre Umleitungs-URL.

   

2. Aktivieren Sie OAuth 2.0-Clients und DIE SAML-Authentifizierung, indem Sie in den Abschnitten OAuth 2.0-Clients aktiviert und SAML-Authentifizierung aktivieren die Option Ja auswählen.

3. Konfigurieren Sie den SAML-Identitätsanbieter. Überprüfen Sie die folgenden Felder, wenn SSO bereits für Workday mit Microsoft Entra konfiguriert ist:

Aufgabe 3: Verwalten von Authentifizierungsrichtlinien

Bearbeiten Sie die Authentifizierungsrichtlinie für den Workday-Mandanten. Wenn noch keine Authentifizierungsrichtlinien konfiguriert sind, erstellen Sie zuerst eine.

1. Führen Sie den Bericht Authentifizierungsrichtlinien verwalten aus. Wählen Sie dann die Schaltfläche Bearbeiten für die Richtlinie für den Mandanten aus.
2. Sie können die Authentifizierungsrichtlinie auf die OAuth-Clientidentität festlegen, die vom Mitarbeiter-Self-Service-Agent verwendet wird. Integrationssystembenutzer werden in der vereinfachten Einrichtung nicht verwendet.
3. Wählen Sie SAML als Zulässiger Authentifizierungstyp aus. Wenn sowohl die METHODEN SAML als auch User Name Password verwendet werden, lassen Sie beides zu.
4. Stellen Sie sicher, dass die OPTION SAML für die Sicherheitsgruppe Alle Mitarbeiter zusammen mit jeder anderen erforderlichen Methode in Ihrer Workday-Umgebung aktiviert ist.
5. Führen Sie die Aufgabe Alle ausstehenden Authentifizierungsrichtlinienänderungen aktivieren aus, um alle ausstehenden Änderungen an Authentifizierungsrichtlinien zu aktivieren. Dieser Schritt ist erforderlich, um alle Änderungen der Authentifizierungsrichtlinie abzuschließen.

Aufgabe 4: Registrieren des API-Clients

Diese Aufgabe ist erforderlich, um Workday-APIs aus einem externen System wie dem Mitarbeiter-Self-Service-Agent aufzurufen.

Melden Sie sich bei Workday als Administrator an, der API-Clients verwalten kann. Geben Sie im Workday-globale Suche api-Client registrieren ein, und wählen Sie dann api-Client registrieren aus den Ergebnissen aus.

Fügen Sie beim Konfigurieren des Bereichs (Funktionsbereiche) auf dem API-Client die folgenden Funktionsbereiche hinzu, die für die vereinfachte Einrichtung von Employee Self-Service erforderlich sind:

• Hauptabrechnung
• Organisationen und Rollen
• Personal
• Freizeit und Urlaub

Diese vier Funktionsbereiche sind der Mindestumfang , der für die sofort einsatzbereite Mitarbeiter-Self-Service erforderlich ist. Wenn Sie employee Self-Service mit benutzerdefinierten Themen oder Flows erweitern möchten, die zusätzliche Workday-Domänen verwenden (z. B. Recruiting, Learning oder Ausgaben), fügen Sie auch die entsprechenden Funktionsbereiche hinzu.

Legen Sie Workday Owned Scope einschließen auf Ja fest, damit workday-eigene Webdienste (z. B. der REST-Endpunkt /workers/me , der für die Benutzerkontextsuche verwendet wird) zusammen mit den von Ihnen ausgewählten Funktionsbereichen eingeschlossen werden.

Die Client-ID und die Endpunkte, die nach der Erstellung des Clients automatisch generiert werden, müssen sicher mit Microsoft Entra Administratoren für Microsoft Entra Konfiguration für den Mitarbeiter-Self-Service-Agent freigegeben werden.

Installieren des Workday-Erweiterungspakets für den Mitarbeiter-Self-Service-Agent

Der Mitarbeiter-Self-Service-Agent ist so konzipiert, dass er über separate Erweiterungspakete für jede externe Systemlösung eines Drittanbieters verfügt. Sie müssen das Erweiterungspaket installieren, bevor Sie Konfigurationen oder Anpassungen starten.

Die folgenden Schritte sind erforderlich, um das Workday-Erweiterungspaket zu installieren und zu aktivieren.

Schritt 1: Installieren der Erweiterung

1. Öffnen Sie den Mitarbeiter-Self-Service-Agent in Copilot Studio.
2. Navigieren Sie zu Einstellungen.
3. Wählen Sie im linken Navigationsbereich Anpassen aus.
4. Wählen Sie Workday und dann Installieren aus. Bestandskunden können ein installiertes Paket aktualisieren, indem sie unter Einstellungen>Anpassen die Option Workday und dann Aktualisieren auswählen. Das Paketupdate wirkt sich erst auf den Produktions-Agent aus, wenn Sie ihn übernehmen.
5. Wenn Sie dazu aufgefordert werden, aktualisieren Sie die Verbindungen wie beschrieben, indem Sie die Auslassungspunkte (...) auf der rechten Seite für jede Verbindung auswählen.

Schritt 2: Einrichten der Verbindungsauthentifizierung

Derzeit unterstützt der Workday-Connector in Power Platform drei Arten der Authentifizierung:

• Standard
• Microsoft Entra ID Integriert
• Microsoft Entra ID integriert mit API Management

In diesem Artikel erfahren Sie, wie Sie die Microsoft Entra ID integrierte Authentifizierungsmethode einrichten. Sie müssen die SSO-Konfiguration abschließen, um dieses Setup durchzuführen.

Wenn Sie den Workday-Connector installieren, besteht der erste Schritt darin, Verbindungen mithilfe des Formulars einzurichten. Füllen Sie die folgenden Felder aus.

Microsoft Entra-Ressourcen-URL (Anwendungs-ID-URI)

Microsoft Entra App-Registrierung, die für Workday SSO erstellt wurde. Erfahren Sie, wie Sie auf App-Registrierungen zugreifen.

1. Wählen Sie Alle Anwendungen aus.
2. Wählen Sie die richtige Anwendung aus, die für Workday SSO erstellt wurde.
3. Verwenden Sie im Abschnitt Übersicht den Anwendungs-ID-URI auf der Registerkarte Essentials .

Workday OAuth-Token-URL und Client-ID

Workday-API-Clienteinstellungen weisen die OAuth-Token-URL auf.

1. Melden Sie sich bei Workday mit Berechtigungen für api-Client anzeigen an.
2. Identifizieren Sie den richtigen API-Clienteintrag aus der Tabelle, und öffnen Sie ihn (erstellt beim Einrichten des einmaligen Anmeldens unter Bearbeiten des Mandantensetups – Sicherheit in Workday).
3. Suchen Sie auf der Seite API-Client anzeigen nach Tokenendpunkt.
4. Der Wert für Client-ID wird oberhalb des Tokenendpunkts angezeigt.

SOAP-Basis-URL

Der Bericht Öffentliche Workday-Webdienste enthält die SOAP-Basis-URL. Das vereinfachte Setup verwendet keine Berichte als Dienst (Reports as a Service, RaaS). Führen Sie daher die folgenden Schritte aus, um die SOAP-Endpunkt-URL zu ermitteln.

1. Geben Sie in der Workday-Suchleiste Öffentliche Webdienste ein, und öffnen Sie dann den Bericht Öffentliche Webdienste .

   

2. Suchen Sie den Webdienst, den Sie benötigen, z. B. Personalwesen, Personal oder Recruiting. In diesem Beispiel wird Human Resources (Public) verwendet.

3. Wählen Sie das Menü Verwandte Aktionen (drei Punkte) neben dem Webdienst und dann Webdienstansicht>WSDL aus.

   

4. Wenn die WSDL-Seite geöffnet wird, suchen Sie nach soapbind:address.

5. Kopieren Sie den Wert des location Attributs für das soapbind:address -Element. Dieser Wert ist die SOAP-Endpunkt-URL, die für die Integration verwendet werden soll.

   

Der location Wert hat die folgende Form:

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

Workday REST-Basis-URL

Die Workday REST-Basis-URL wird auf derselben Ansichtsseite des Workday-API-Clients verfügbar gemacht, die zum Abrufen der OAuth-Token-URL und der Client-ID verwendet wird. Geben Sie die REST-Basis-URL in der Verbindungskonfiguration an. Dieses Feld ist ein neues Feld für die vereinfachte Einrichtung.

Kopieren Sie den Wert workday REST API Endpoint so, wie er von Workday angezeigt wird. Host und Pfad variieren je nach Workday-Bereitstellung. Erstellen Sie die URL also nicht manuell. Kürzen Sie dann den kopierten Wert so, dass er bei /apiendet. Entfernen Sie alles nach /api (z. B. das Mandantensuffix oder einen beliebigen /v1 oder Ressourcenpfad, den Workday angibt). Im Feld REST-Basis-URL wird erwartet, dass der Endpunkt nur bis zu /api ist. Wenn Sie den nachfolgenden Pfad in belassen, schlägt der vereinfachte Flow im Hintergrund fehl.

Schritt 3: Konfigurieren von Verbindungen

Während der Installation des Workday-Erweiterungspakets werden Sie zur Eingabe der folgenden Verbindungskonfigurationen aufgefordert:

Stellen Sie sicher, dass jede Verbindung explizit mit einem eigenen Konto eingerichtet ist, auch wenn die Verbindung status nach der ersten Verbindungseinrichtung möglicherweise grün wird.

Schritt 4: Aktivieren der Berechtigung zum Freigeben von Parametern zulassen

Öffnen Sie in der Workday-Verbindung die Registerkarte Verbindungsparameter , und legen Sie Berechtigung zum Freigeben von Parametern zulassen auf Ein fest. Vergewissern Sie sich, dass alle Parameterfelder (einschließlich REST-Basis-URL) aufgefüllt sind, und wählen Sie dann Speichern aus.

Schritt 5: Bestätigen, dass die Workday-Flows aktiviert sind

1. Öffnen Sie die Workday-Projektmappe auf der Seite Lösungen.
2. Wählen Sie auf der Randleiste Cloudflows aus, und überprüfen Sie, ob beide Workflows aktiviert sind.
3. Wenn die Cloudflows nicht aktiviert sind, wählen Sie die Anzeigenamen aus, um den Cloudflow zu öffnen, und klicken Sie auf der Symbolleiste auf Aktivieren .

Schritt 6: Einrichten des Themas zum Benutzerkontext

Vergewissern Sie sich, dass das Benutzerkontextthema auf die V2-Version festgelegt ist. Wechseln Sie Microsoft Copilot Studio zu Agents>ESS HR/IT-Themen>, und öffnen Sie das Thema [Admin] – Benutzerkontext – Setup. Überprüfen Sie im Knoten Thema das Thema, auf das verwiesen wird:

• Wenn es bereits Workday [System] - 1: Benutzerkontext V2 festlegen ist, ist keine Änderung erforderlich.
• Wenn dies nicht der Fall ist, wählen Sie den vorhandenen Themenverweis aus, wählen Sie Thema auswählen aus, suchen Sie nach v2, und wählen Sie dann Workday [System] – 1: Benutzerkontext festlegen V2 aus. Speichern Sie das Thema.

Weitere Informationen zu den Benutzerkontextvariablen, die der Agent verwendet, und wie sie in Ihrem Agent darauf verweisen, finden Sie unter Entwerfen bewährter Methoden für den Mitarbeiter-Self-Service-Agent.

Schritt 7: Identitätsauflösung für Nicht-UPN-Mandanten

Workday verwendet einen Identitätsanbieter (IdP) für die Anmeldung. Das vereinfachte Setup funktioniert, wenn der IdP von Workday entweder direkt Microsoft Entra ID oder ein Drittanbieter-IdP ist, mit dem Microsoft Entra verbunden ist. Diese Topologien entsprechen dem Entra, der mit einem cloudbasierten Drittanbieter-IdP verbunden ist, und Entra NICHT mit IdP-Zeilen von Drittanbietern in der Workday-Authentifizierungsmatrix in employee Self-Service prerequisites verbunden.

Für Mandanten, bei denen Microsoft Entra UPNs mit Workday-Anmelde-IDs übereinstimmen, ist keine weitere Aktion erforderlich. Der Microsoft Entra ID Integrierte Authentifizierungspfad löst die Identität des angemeldeten Benutzers automatisch auf.

Bei Mandanten, bei denen Microsoft Entra UPNs nicht mit workday-Anmelde-IDs übereinstimmen und der IdP von Workday ein Drittanbieter-IdP ist, mit dem Microsoft Entra verbunden ist, löst Workday die Identität des Benutzers aus den SAML-Ansprüchen auf, die er vom Drittanbieter-IdP erhält. Für die meisten Bereitstellungen ist kein benutzerdefiniertes Thema zur Laufzeitzuordnung ohne UPN erforderlich.

Anpassungen für die Workday-Integration

Verwenden Sie Vorlagen , um die anpassungen abzuschließen, die für die Workday-Integration erforderlich sind. Vorlagen sind XML-Objekte, die Verbindungsinformationen und Datenextraktionsinformationen definieren. Hier verwenden Sie Vorlagen, um Informationen aus Workday abzurufen.

In der Lösung enthaltene Vorlagen

Die folgenden Vorlagen und die zugehörigen Copilot-Themen sind hier aufgeführt:

Übersicht über die Vorlagenstruktur

Die Vorlagen sind in zwei Hauptkomponenten unterteilt: scenario und 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>

Szenario

Das scenario -Objekt ist ein XML-Objekt, das verwendet wird, um bestimmte Kundenszenarien in den Mitarbeiter-Self-Service-Agent-Flows zu steuern. Der scenario XML-Knoten enthält ein name Attribut, das das Szenario aus einer allgemeinen Perspektive beschreibt. Innerhalb des scenario -Objekts gibt apiRequests es - und -Bezeichnungen.

apiRequest

Die apiRequest Knoten enthalten Informationen, die dem Workday-API-Flow vermitteln, wie Daten anzufordern sind.

<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

Anforderungsvorlagen sind XML-Objekte, die den Anforderungstext definieren, der an Copilot gesendet wird. Diese Vorlagen enthalten häufig ersetzbare Werte, die im Rahmen des Flows aufgefüllt werden. Ersetzbare Werte werden in geschweiften Klammern {example_replaceable_value}angezeigt.

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

Das folgende Beispiel ist eine vollständige Beispielvorlage:

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

Anpassen von Workday-Verweisdaten

Die Workday-Lösung enthält 17 Referenzdatasets, die jeweils als Vorlagenkonfigurationsdatensatz in Dataverse gespeichert sind. Diese Datensätze werden von einem kanonischen Workday-Mandanten aus seeded. Wenn Ihr Workday-Mandant einen dieser Kataloge angepasst hat, sollten Sie die entsprechende Vorlagenkonfiguration mit Ihrem Mandanten in Einklang bringen.

Wann Verweisdaten angepasst werden sollen

Passen Sie Verweisdaten an, wenn eine der folgenden Aktionen erfolgt:

• Ein Thema, das eine Liste zurückgibt (z. B. "Show me my passports", "show me my visas" oder "show me my education"), gibt ein leeres Ergebnis zurück oder gibt Etiketten zurück, die für Ihren Mandanten falsch aussehen.
• Ein Workday-Schreibvorgang gibt einen Invalid_Reference_ID Fehler zurück. Dieser Fehler bedeutet, dass der Agent eine Verweis-ID gesendet hat, die Ihr Workday-Mandant nicht erkennt.
• Ihr Workday HRIS-Team hat bestätigt, dass der Mandant benutzerdefinierte Verweis-IDs für einen oder mehrere der in der folgenden Tabelle aufgeführten Typen verwendet.

Wenn keine Fehler angezeigt werden und alle Werte richtig aussehen, müssen Sie keine Verweisdaten anpassen.

Die 17 Referenzdatensätze

Jedes Verweisdataset wird in der Tabelle Employee Self-Service Template Configuration (msdyn_employeeselfservicetemplateconfig) gespeichert. In der folgenden Tabelle sind die Datensätze zusammen mit den Agent-Themen aufgeführt, die sie nutzen.

Suchen der richtigen Werte in Workday

Die autoritative Liste für jeden Verweistyp befindet sich in Workday hinter dem Task Verweis-IDs verwalten . So exportieren Sie die kanonische Liste:

1. Melden Sie sich bei Workday als Benutzer mit Integrationskonfigurationszugriff an. Dieser Benutzer ist in der Regel ein Workday-Administrator oder jemand in Ihrem HRIS-Team.
2. Geben Sie in der Workday-Suchleiste Verweis-IDs beibehalten ein, und führen Sie die Aufgabe aus.
3. Wählen Sie in der angezeigten Eingabeaufforderung den Verweis-ID-Typ aus, den Sie überprüfen möchten. Die Namen der Verweis-ID-Typen in Workday werden direkt den Datensätzen in der vorherigen Tabelle zugeordnet. Zum Beispiel:
   • Passport ID Type wird zugeordnet msdyn_HRWorkdayHCMReferenceData_PassportIdType.
   • Der Nationale ID-Typ wird zugeordnet msdyn_HRWorkdayHCMReferenceData_NationalIdType.
   • Der Visa-ID-Typ wird zugeordnet msdyn_HRWorkdayHCMReferenceData_VisaIdType.
   • Degree wird zugeordnet msdyn_HRWorkdayHCMReferenceData_Degree.
   • Die Sprache wird zugeordnet msdyn_HRWorkdayHCMReferenceData_Language.

Workday gibt die Liste der Verweis-IDs zurück, die im Mandanten konfiguriert sind. Die Spalte Verweis-ID ist der Wert, den Sie als Schlüssel verwenden. Die Spalte Name oder Beschreibung ist der Wert, den Sie als Anzeigebezeichnung verwenden.

Alternative Workday-Aufgaben geben dieselben Daten zurück und können je nach Sicherheitsprofil schneller darauf zugreifen:

• Verweis-IDs anzeigen: Eine schreibgeschützte Ansicht derselben Listen mit breiterem Zugriff als Verweis-IDs verwalten.
• Verwalten von Sprachen, Verwalten von Sprachfähigkeiten und Verwalten von Sprachfunktionen: Jeder Task macht die gleichen Verweis-IDs verfügbar, die auf den relevanten Sprachverweistyp festgelegt sind.

Wenn Ihr Workday-Mandant diese Kataloge stark angepasst hat oder ein Identitätssetup eines Drittanbieters verwendet, bitten Sie Ihr Workday HRIS-Team, die Listen für Sie zu exportieren.

Bearbeiten eines Verweisdatensatzes

Nachdem Sie über die autoritativen Liste von Workday verfügen, bearbeiten Sie den übereinstimmenden Datensatz in Dataverse. Sie benötigen die Sicherheitsrolle Environment Maker in der Power Platform-Umgebung, um diese Datensätze anzeigen und bearbeiten zu können.

1. Öffnen Sie im Power Apps Maker-Portal Tabellen , und wählen Sie Employee Self-Service Template Configuration aus.

2. Filtern Sie die Datensätze nach der Spalte Eindeutiger Name . Geben Sie ein msdyn_HRWorkdayHCMReferenceData_ , um alle 17 Datensätze anzuzeigen.

3. Öffnen Sie den Datensatz, der dem Verweistyp entspricht, den Sie aktualisieren möchten.

4. Öffnen Sie die Spalte Wert . Es wird XML angezeigt, das wie im folgenden Beispiel aussieht:

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

   Das k Attribut für jedes <i> Element ist die Workday-Referenz-ID, die der Agent bei Schreibvorgängen zurück an Workday sendet. Das v -Attribut ist die Anzeigebezeichnung, die der Agent dem Endbenutzer anzeigt. Beide müssen mit dem übereinstimmen, was Workday akzeptiert.

Vergleichen Sie für jedes Element in der Liste mit dem Workday-Export:

• Wenn in k Ihrer Workday-Liste kein Wert angezeigt wird, kann der Agent diesen Wert nicht mit einem Invalid_Reference_ID Fehler schreiben. Aktualisieren Sie das k Attribut auf einen Wert, der in Ihrem Workday-Mandanten vorhanden ist, oder entfernen Sie den Eintrag, wenn er nicht zutrifft.
• Wenn eine Workday-Referenz-ID in der Vorlagenkonfiguration fehlt, wird sie endbenutzern nicht in der Agentauswahl angezeigt. Fügen Sie im -Block einen neuen Eintrag im Formular <i k="YourReferenceId" v="Display label"/><seedData> hinzu.
• Wenn eine v Bezeichnung veraltet ist oder nicht ihren lokalen Sprachkonventionen entspricht, aktualisieren Sie das v Attribut. Die Bezeichnung wird nur angezeigt und nicht an Workday zurückgesendet.

Speichern Sie den Eintrag. Die Änderung wird beim nächsten Agentaufruf wirksam. Sie müssen einen Flow nicht neu starten oder eine Lösung erneut veröffentlichen.

Sichern Ihrer Anpassungen

Anpassungen an Vorlagenkonfigurationsdatensätzen werden zurückgesetzt, wenn die Workday-Lösung aktualisiert wird, da diese Datensätze als Teil des verwalteten Pakets enthalten sind. Vor jedem zukünftigen Upgrade:

1. Öffnen Sie jeden benutzerdefinierten Datensatz unter msdyn_HRWorkdayHCMReferenceData_*.
2. Kopieren Sie den vollständigen Inhalt der Spalte Wert (den gesamten XML-Block) an einen sicheren Speicherort. Ein SharePoint-Dokument in Ihrem Mandanten, eine Datei mit Versionsverwaltung in Ihrem Runbookrepository oder ein sicheres Teampostfach sind geeignete Optionen.
3. Fügen Sie nach Abschluss des Upgrades den gespeicherten XML-Code wieder in die Spalte Wert des entsprechenden Datensatzes ein.

Bis ein Ansatz zur Beibehaltung von Anpassungen verfügbar ist, ist dieser Sicherungs- und Wiederherstellungsschritt das unterstützte Muster.

Verwandte Artikel

• Aktualisieren der Workday-Lösung für Employee Self-Service
• Aktualisieren einer vorhandenen Workday-Integration auf das vereinfachte Setup
• Erstellen von Berichten für Ihre Workday-Integration
• Einführung in Employee Self-Service
• Integrieren von ServiceNow in Ihre Employee Self-Service-Bereitstellung
• Integrieren von Workday in Ihre Employee Self-Service-Bereitstellung (Legacy-ISU + RaaS-Referenz)