This page covers the MCP server, which lets AI clients call Workday tools. To sync Workday accounts and access into C1 for access reviews, see the Workday connector or the Workday Accounts connector instead.
How C1 connects to Workday
C1 hosts the Workday MCP server, so your users’ AI clients only ever see MCP tools. They never call Workday directly. When an AI client calls one of these tools, C1 makes the matching request to your tenant’s Workday REST API with the calling user’s OAuth token, then returns the result to the AI client. Your Workday tenant uses two hosts, and the OAuth flow uses both:
Each request is limited twice. The API client’s functional areas decide which Workday APIs C1 can call at all. The signing-in user’s security groups decide what data that user can see or change through those APIs.
Before you begin
- AI access management must be enabled for your tenant. See Enable AI access management.
- A Workday account in a security group with Modify permission on these domains, both in the System functional area. Workday’s Security Administrator security group is one example.
- Set Up: Tenant Setup - Security, which secures the Edit Tenant Setup - Security task.
- Security Administration, which secures the Register API Client task.
- Every user who will connect needs a Workday account whose security groups grant access to the domains for the data they’ll use. The API client doesn’t extend anyone’s access.
If you don’t see Workday in your MCP server catalog, contact the C1 support team to enable it for your tenant.
Enable OAuth 2.0 clients in your tenant
Workday accepts API clients only after OAuth 2.0 clients are enabled for the tenant. If your tenant already uses OAuth API clients, this box is already selected.1
In the Workday search bar, search for and open the Edit Tenant Setup - Security task.
2
Under OAuth 2.0 Settings, select OAuth 2.0 Clients Enabled.
3
Select OK.
Register a Workday API client
Register one API client that C1 uses to send each user through Workday’s sign-in. For Workday’s own walkthrough, see Connect to Workday Using OAuth.1
In the Workday search bar, search for and open the Register API Client task. Use this task, not Register API Client for Integrations.
2
Enter a Client Name that identifies C1 for your team, such as
C1.3
Set Client Grant Type to Authorization Code Grant. You can’t change the grant type after you register the client.
4
Leave Access Token Type set to Bearer.
5
Set Redirection URI to exactly whichever matches your C1 tenant’s domain:
- Default instance:
https://accounts.conductor.one/auth/callback - EU data residency instance:
https://accounts.c1eu.ai/auth/callback
https redirect URIs.6
Select Non-Expiring Refresh Tokens, so C1 can keep renewing each user’s access without asking them to sign in again.
7
Optional. Select Grant Administrative Consent to skip the consent screen Workday otherwise shows each user the first time they connect.
8
Under Scope (Functional Areas), add the functional areas for the tools you want. See Workday functional areas for the recommended set.
9
Select OK.
10
Copy the Client ID and Client Secret that Workday shows. Workday doesn’t show the client secret again.
Collect your Workday endpoint values
Workday’s View API Clients report lists your tenant’s endpoints at the top of the page, above the list of API clients.1
In the Workday search bar, search for and open the View API Clients report.
2
Copy the Token Endpoint and Authorization Endpoint values shown at the top of the report.
The report also shows a Workday REST API Endpoint. C1 doesn’t use it, so don’t paste it as the Instance URL: it carries a path, and C1 builds each API path itself.
Workday functional areas
Workday doesn’t use OAuth scope strings. Instead, you choose functional areas on the API client, and Workday applies them to every token that client issues. C1 sends no scopes when users authorize, so you manage access entirely in Scope (Functional Areas) on the API client. In the functional area picker, the Workday REST API group lists only some of these areas. Search the picker by name to find the rest, such as Recruiting or Time Tracking.Recommended functional areas
These areas cover the core tools: workers, organizations, jobs, skills, check-ins, direct reports, time off, inbox tasks, and business processes.Optional functional areas
Add these areas only if you want the matching tool groups.
A tool whose functional area is missing from the API client returns a Workday permission error, not an empty result. To add an area later, open the Edit API Client task, select your API client, and add the area under Scope (Functional Areas).
A functional area lets C1 call an API, but it doesn’t grant anyone data access. A user whose security groups lack the domain that secures the data gets a
permission denied error with code S22, even when the area is on the API client.Register the Workday MCP server in C1
With your API client and endpoint values ready, register the server and enter its credentials.1
Follow Register an MCP server and select Workday from the catalog.
2
Enter the Workday settings from Collect your Workday endpoint values:
3
When you configure authentication, choose per-user OAuth.
4
Enter the API client’s Client ID and Client Secret.
5
Set Authorization URL to your Authorization Endpoint and Token URL to your Token Endpoint. If C1 shows either URL with placeholders, replace them with your values.
6
Leave the scopes field empty. Workday applies the functional areas you chose on the API client.
7
Save your changes. The first time a user calls a Workday tool from their AI client, C1 prompts them to connect their Workday account.
Tools the Workday MCP server provides
The server exposes read tools across Workday’s HCM services and write tools that start or act on Workday business processes. Each user’s Workday security still limits what their calls can do.
Write tools start real Workday business processes, which then follow your tenant’s approval routing. Review them before you approve them in C1, and
delete_worker_time_block in particular, which removes a worker’s recorded time. approve_event_step and deny_event_step also need care: once a step is approved or denied, the tools can’t undo it.
Limits of the Workday tools
Workday enforces its own business process security and rules on every write, so a write tool approved in C1 can still fail in Workday:- Business process security applies to every write. A user can act only on a step that’s awaiting them. For example,
approve_event_stepreturns an error for a step assigned to someone else. - Send-back targets come from a list.
send_back_event_stepneeds the step to send the event back to. Calllist_send_back_targetswith theeventStepyou want to send back, and use a returned ID as the target. - Time tracking needs worker setup.
create_worker_time_blockworks only for workers who have time tracking set up in Workday, including a period schedule and a time entry template. - Mentorship close reasons aren’t listed.
close_mentorshipneeds a valid close-reason reference ID from your tenant, and the server doesn’t provide a list of reasons. - Some lists need a filter. Workday returns no rows for these lists without one, so the server rejects a call that omits it:
list_eventsneedsworkerorinitiator.list_balancesneedsworker.list_organizationsneedsorganizationType. Uselist_organization_typesto find the type IDs.list_valid_time_off_datesneeds bothdateandtimeOff.list_send_back_targetsneedseventStep.
How Workday credentials are shared
Each user authorizes with their own Workday account, so tool calls run under that user’s Workday identity and security groups. Workday records that user as the initiator of any business process a write tool starts. The client ID, client secret, instance URL, tenant, and endpoint URLs are shared settings on the server, and they apply to every user. C1 also records each call in the AI tool usage audit log. For how shared and per-user credentials work across MCP servers, see Configure authentication.Discover and govern tools
After you register the server, C1 runs tool discovery against Workday. Discovered tools appear on the server’s Tools tab. Each tool starts as either Pending review or automatically Approved, depending on the option chosen when the server was set up or your tenant’s default tool settings in AI > MCPs > Settings. See Require tool approval and Default tool classification. Before anyone can call a Workday tool, it must be approved, added to a toolset, and bound to an access profile. Continue to Govern tools and toolsets to set this up.Tool discovery runs even if your credentials are incorrect, so seeing discovered tools doesn’t confirm that authentication is working. You confirm your Workday setup when an approved user successfully calls a Workday tool from their AI client.
Manage your Workday credentials
- Rotate the client secret with the API client’s Generate New Client Secret action in Workday, then update the secret on the server’s authentication settings in C1.
- Adjust access by adding or removing functional areas under Scope (Functional Areas) in the Edit API Client task. See Workday functional areas.
- Stop all access by selecting Disabled on the API client in the Edit API Client task.
Troubleshoot Workday MCP server errors
Most setup problems show up during a user’s first connection or tool call. Workday returns errors as JSON with anerror message and a code.