Connect Workday to Kula
Last updated: August 17, 2026
Connecting Workday lets you push a hired candidate straight into Workday as a new employee, with the details you already hold in Kula filling the form for you.
Who can do this: Super Admin, Admin
Where to find it: Settings → Organization → Organization integrations → HRIS and onboarding
What the connection window looks like
Turning the toggle on does not connect Workday straight away. It opens a secure connection window: the permissions Kula is asking for, then your Workday REST API endpoint, then the credentials you generate in Workday.
Workday's permission list includes Read employee document categories, which lets Kula show you Workday's own document folders when you attach an offer letter to a hire. Scroll the list — it continues below the visible area.
Permission | What Kula can do |
|---|---|
Read legal entities | Read your legal entity data |
Read work locations | Read your work location data |
Read employees | Read your employee data |
Read employments | Read your employment data |
Read groups | Read your group data |
Read employee document categories | Read your employee document category data |
Every screen has a View Guide button in the footer, next to "Need help? Check out our detailed connection guide." Use it. It opens , which has screenshots of every Workday screen you need to click through — this article tells you what to do, the guide shows you what it looks like on Workday's side.
Before you connect — set aside about 30 minutes
Workday is by far the longest HRIS connection to set up, and it is the one most likely to need your Workday administrator rather than your recruiting team. Nothing about it happens inside Kula until the very last step.
You must be a Workday administrator. Search Workday for View API Clients — if that task does not appear, you are not an admin. Find out who is and ask them to grant you permissions or run the setup themselves.
You will do three things in Workday, then bring four values back to Kula:
In Workday, you will | Why |
|---|---|
Create an integration system user (ISU) and a security group for it | Gives Kula a dedicated account rather than using a person's login |
Grant that security group the required permissions, then activate the changes | Without activating, none of the permissions take effect |
Register an API client and generate a refresh token | Produces the credentials Kula needs |
The exact permissions and scopes are shown inside Kula's connection flow and are specific to your tenant. Do not copy them from an example or from another company's setup.
Step 1 — Collect four values from Workday
Follow the detailed walkthrough in the How to set up link on the Workday card, which has Workday screenshots for every task. By the end you need:
Value | Where it comes from |
|---|---|
Workday REST API Endpoint | The View API Clients page. Follows the pattern |
Client ID | Shown when you register the API client |
Client Secret | Shown at the same time — copy it before leaving the page |
Refresh Token | Generated afterwards via API Client → Manage Refresh Tokens for Integrations |
When you register the API client, make sure Non-Expiring Refresh Tokens is turned on. When you create the ISU, we recommend ticking Do Not Allow UI Sessions so the account cannot be used to log in to Workday directly.
Step 2 — Activate your changes in Workday
This step is skipped often and it silently breaks everything else.
Search Workday for Activate Pending Security Policy Changes.
Run the task and add a comment describing the change.
Click OK, then tick Confirm and click OK again.
Until you do this, the permissions you assigned have no effect, even though they look correct.
Step 3 — Enter your endpoint and credentials in Kula
Kula asks for the REST API endpoint on its own screen first, then the rest of your credentials.
Return to the Kula connection window. If you closed it, reopen the Workday card from Settings → Organization → Organization integrations.
On the Workday REST API Endpoint screen, paste the endpoint you copied from View API Clients. It follows the pattern
https://{domain}/ccx/api/v1/{tenant}.Click Continue.
Enter the Client ID, Client Secret and Refresh Token you generated.
Complete the connection.
The field mapping screen opens automatically straight after a successful connection, so you can set your mappings while you are already there. You can reopen it at any time — see below.
Map your Kula fields to Workday
Field mapping decides which Kula value fills which Workday field, so the employee form arrives prefilled instead of blank.
Hover over the connected Workday card.
Click Edit.
Match each Workday field to the Kula field that should fill it.
Save.
These Kula fields are available to map, from your job, requisition and offer records:
Group | Fields you can map |
|---|---|
Organisation | Department, Sub Department 1, Sub Department 2, Sub Department 3 |
Address | Full Address, Street, City, State, Country, Zipcode |
Office | Office Name, Office Location |
Dates | Hire Date — the date the candidate was last moved to the Hired stage |
Push a hired candidate to Workday
Once the mapping is set, open the hired candidate's application and send them to Workday. Kula loads the Workday employee form, prefills every mapped field, and fetches Workday's own dropdown options live so the values you pick are always valid.
You can also attach documents from the application — offer letters and other files — and choose which Workday document category each one goes into.
For the full flow, see [Push a hired candidate to your HRIS]
Fix an invalid connection
If the card shows Invalid, the credentials were revoked or rotated in Workday, or the security policy changes were reverted, and pushes will fail.
Hover over the Workday card.
Click Re-authenticate.
Enter your current credentials.
Your existing field mappings are kept — you do not have to set them up again.
If the credentials are correct and it still fails with Invalid username or password!, the ISU is being blocked by your Workday authentication policy. In Workday, search Manage Authentication Policies, edit the policy, add an authentication rule for the security group you created, set Allowed Authentication Types to Specific: User Name Password or Any, then run Activate All Pending Authentication Policy Changes.
Good to know
Only hired candidates can be pushed. If the application is not in the Hired stage, Kula blocks the push.
Documents are limited to 20 MB per file. Anything larger is rejected. Files over 10 MB, and any push covering more than one document category, upload in the background — the push itself completes straight away and the documents follow.
Pushing the same person twice fails. If the employee already exists in Workday, Kula reports it rather than creating a duplicate.
A permissions error means Workday, not Kula. If the push fails with a permission error, the Workday credentials that authorised the connection do not have rights to create employees. Ask your Workday administrator to widen them and re-authenticate.
Where a job or requisition has more than one office, the first office is used when sending to Workday.
Setting up Workday takes around 30 minutes and needs a Workday administrator. Plan it in rather than attempting it the day you need to push a hire.
If you do not run Activate Pending Security Policy Changes, nothing you configured takes effect. The permissions will look right in Workday and the connection will still fail.
Copy the Client Secret when it is first shown. Leaving that page without copying it means registering the API client again.
FAQ
Workday keeps rejecting the connection with "Invalid username or password" even though the credentials are right. What now? This is usually your Workday authentication policy blocking the integration system user, not a wrong password. In Workday, search Manage Authentication Policies, add an authentication rule for the security group you created with Allowed Authentication Types set to Specific: User Name Password or Any, then run Activate All Pending Authentication Policy Changes.
Kula is asking for a Workday REST API Endpoint — where is that? In Workday, search View API Clients in the top bar and open that page; the endpoint is at the top. It follows the pattern https://{domain}/ccx/api/v1/{tenant}. If View API Clients does not appear when you search, you are not a Workday administrator. For more, see , which screenshots every Workday task.
Can our recruiting team set up Workday themselves? Usually not. Creating an integration system user, a security group and an API client are Workday administrator tasks, and the setup takes around 30 minutes. Involve whoever administers Workday from the start.
Can I send a candidate to Workday before they are marked as hired? No. The push is only available once the application reaches the Hired stage — Kula blocks it before then to avoid creating employees for candidates who have not accepted.
We changed our field mapping — do we need to reconnect Workday? No. Mapping and connection are separate. Hover over the card, click Edit, change the mapping and save; the connection is untouched.
Can Kula create the position in Workday as well as the employee? No. Kula pushes a hired candidate into Workday as an employee. Creating Workday positions from Kula is a separate, unbuilt capability.
Need help? If you have questions or need assistance, reach out to us at support@kula.ai or use the in-app chat.