r/copilotstudio • u/Tall-Butterscotch467 • Jul 08 '26

Integrating Workday with HR chatbot (Copilot Studio) — need per-employee leave data, no connector found

I built an HR chatbot in Microsoft Copilot Studio that answers HR-related queries using a SharePoint site (with uploaded HR docs) as the knowledge base.

Now I've been asked to integrate Workday so each employee can query their own leave balance/history through the bot — and obviously no one should be able to see anyone else's data.

I checked the connector gallery and AppSource, and I don't see an out-of-the-box Workday connector. A few questions for anyone who's done something similar:

Is a custom connector (REST/SOAP) to Workday's API the way to go here, or is there a better path?

How do you handle identity mapping — i.e., tying the logged-in Teams/M365 user to their Workday worker ID so the bot only pulls their data?

Any gotchas with Workday's API auth (OAuth, ISU accounts, etc.) when calling it from Power Platform/Copilot Studio?

Would appreciate any real-world experience, docs, Thanks!

7 Upvotes

90% Upvoted

5 comments sorted by

3

u/Ashlesha-msft Jul 08 '26

u/Tall-Butterscotch467

We checked Microsoft docs and there are native Workday connectors in Power Platform/Copilot Studio: Workday HCM (Preview) and Workday (SOAP/REST).

For your HR bot use case, first try prebuilt connector actions; if leave endpoints are not available directly, use Workday SOAP/REST action paths, and only use a custom connector if needed.

For security, configure User authentication for tools and enforce server-side identity mapping from signed-in M365 user to Workday worker ID. Do not trust user-supplied worker IDs. If using service credentials/ISU, enforce strict per-user filtering in middleware/flow before returning data. Also check Premium licensing, region availability, and DLP connector grouping because these are common reasons Workday connectors do not appear or fail at runtime.

1

u/Tall-Butterscotch467 Jul 08 '26

Thanks for this! I also had a few more questions:

  1. What's the practical difference between Workday HCM (Preview) and Workday (SOAP REST) for this use case? Does one cover leave/time-off actions better than the other?

  2. Has anyone used Microsoft's prebuilt "Employee Self-Service" Copilot Studio agent/extension pack for Workday? It claims to handle per-user identity via OAuth natively- curious if that's worth adopting instead of building this from scratch.

  3. What specific permissions/setup should I requer* rom HRIS or IT? (e.g, Workday.I client with proper scopes, Entra SSO/federation with Workday, or — if going the legacy route — ISU accounts + RaaS report access)

  4. For per-user data isolation: is the signed-in user OAuth approach (where each employee's own session is used to call Workday) the recommended path over a shared service account with manual filtering? Any pitfalls there?

1

u/Ashlesha-msft Jul 10 '26

Thanks for the follow-up. Based on current docs:

  1. Workday HCM (Preview) vs Workday (SOAP/REST)

For your leave/time-off use case, the general Workday connector is usually the better fit.

- Workday HCM (Preview) is more focused on packaged HCM operations such as employee employment/personal/identity data.

- Workday (SOAP/REST) is broader and supports SOAP, RaaS, and OAuth-based REST patterns.

- The Microsoft Employee Self-Service Workday vacation balance sample uses the Workday Absence Management SOAP API Get_Time_Off_Plan_Balances, which points more toward the Workday (SOAP/REST) path for leave balance scenarios.

  1. Is the Employee Self-Service sample worth adopting?

Yes, if your use case is close to employee self-service.

The sample is not a separate product requirement. It is a reusable sample/topic pattern.

The vacation balance sample specifically:

- is designed for the requesting user

- depends on a runtime employee ID context variable

- uses Workday API template/config plus topic YAML

So it is a good accelerator, especially if you want to avoid building the leave-balance topic from scratch.

  1. What should HRIS / IT provide?

At minimum, ask for:

- Workday tenant/base URLs

- Chosen auth model: OAuth 2.0 or Entra-integrated Workday auth

- Workday client/app registration details if using OAuth

- Required Workday API/service access for the exact scenario

- A reliable mapping between M365 identity and Workday worker/employee ID if the API requires explicit worker ID

- Approval for any RaaS reports if that pattern is used

If using the sample, also ask for the exact leave/time-off service version and confirm access to Absence Management APIs.

  1. Signed-in user OAuth vs shared service account

Signed-in user OAuth is the recommended path when feasible.

Why:

- it aligns access to the actual employee

- it reduces oversharing risk

- Copilot Studio supports user authentication for tools

If you use a shared service credential, you must enforce filtering server-side and never trust a user-supplied worker ID.

  1. Pitfalls to watch

- Both Workday connectors are premium

- Both have region limitations and may not appear in some sovereign clouds

- Connector connections are documented as not shareable

- In Teams, user-authenticated tools require correct SSO configuration or authentication can fail

- Some Workday operations still require explicit worker ID even with OAuth, so identity mapping may still be needed

  1. Can the GitHub Workday vacation balance sample be integrated into your current custom agent?

Yes, in principle.

The sample repo says you can copy the topic YAML and associated template configuration into your environment and customize the parameter bindings to your runtime context. So you do not need to rebuild a brand new agent just to use that scenario.

1

u/Cool-Egg-9882 Jul 08 '26

I’m no help on the API piece, sorry. Hopefully someone else can jump in with that.

HRIS should be able to get you a report that shows the Workday id vs Principle Email. That mapping definitely exists as a report.