Workday
Arcade Optimized
Arcade.dev tools for interacting with Workday
Author:Arcade
Version:
1.0.3Auth:User authorization
7tools
7require secrets
Arcade's Workday toolkit connects to a Workday tenant on behalf of the signed-in worker via OAuth 2.0, enabling agents to inspect time-off entitlements, balances, history, and status, validate dates, and submit or draft time-off requests.
Capabilities
- Worker identity — Resolve which Workday worker the active OAuth session belongs to before any other operation; all tools act on that worker exclusively.
- Time-off eligibility & date validation — Retrieve the full set of time-off types the worker may request (including rules for quantities, reasons, positions, and clock times), and pre-validate candidate dates against Workday before writing anything.
- Balance & history inspection — Read current balance by plan (exactly as Workday calculates, no projection) and browse historical requests within a configurable date window, with paging and capped-read disclosure.
- Request status tracking — List pending and past requests with per-group status, action guidance, and flags for items requiring Workday UI action (drafts, sent-back requests); paging by request ID with capped-read handling.
- Draft and submission workflow — Create time-off requests in draft mode by default (safe for review) or submit on explicit worker instruction; Workday owns all downstream validation; existing requests must be modified or cancelled in the Workday UI.
OAuth
This toolkit uses OAuth 2.0 with Workday as the provider. Users authorize access through their Workday account. Arcade has no dedicated docs page for this provider.
Secrets
Two secrets must be configured before the toolkit can make API calls.
-
WORKDAY_BASE_URL— The base URL of your Workday REST API endpoint. This is the root URL specific to your organization's Workday environment (e.g.,https://wd2-impl-services1.workday.com). You can find this in your Workday tenant's API client configuration or by consulting your Workday administrator. It must not include a trailing slash or path segments beyond the host. -
WORKDAY_TENANT_NAME— The unique identifier for your Workday tenant (e.g.,mycompany_previewormycompany). This appears in your Workday login URL and in the paths of all Workday REST API requests. Your Workday administrator can confirm the exact tenant name. It is also visible in the Workday web URL after login (typically the segment following/ccx/or at the subdomain level depending on your deployment).
Configure secrets in the Arcade dashboard or via the API: https://docs.arcade.dev/en/guides/create-tools/tool-basics/create-tool-secrets (secrets can also be managed at https://api.arcade.dev/dashboard/auth/secrets).
Available tools(7)
7 of 7 tools
Operations
Behavior
| Tool name | Description | Secrets | |
|---|---|---|---|
List the time-off types the signed-in worker can request, with their rules.
Each entry includes its display name and time_off_type_id. Retrieve the options here
and pass the chosen ID to the date check and request tools. Each entry also carries what
Workday reports for that type: a default quantity, whether a reason is mandatory
and which reasons are allowed, whether a position must be named, and whether clock
times are required, determine the quantity, or may cross midnight. `draft_support`
reports evidence of existing drafts. Requests use draft mode by default; set mode
to submit only when the worker asks for submission.
Each type's unit is the unit to use for request quantities; do not pass fractions
of a full day for an hourly type. start_and_end_time_required requires both clock
times. calculate_quantity_based_on_start_and_end_time means Workday determines the
recorded quantity from those times. crossing_over_midnight_enabled permits an
earlier end time on the following date, keeping the span under 24 hours. | 2 | ||
Show how much time off the signed-in worker has left, by plan.
Balances come back exactly as Workday calculates them for the as-of date; this
tool never projects or totals an accrual Workday did not return. It reads the
signed-in worker record to address the balances to that worker. Read `coverage`
before relaying an empty list: it says whether no plan is tracked for this worker
or the read simply did not finish, and a worker whose time off is not
balance-tracked can still request time off. | 2 | ||
Browse the time off the signed-in worker has already logged.
Matching entries come back in ascending date order, earliest first. Defaults to a
three-month window either side of today. These date bounds are sent to Workday
before paging, so a narrow window does not scan the worker's whole history.
A request with mixed attributes
appears as separate groups sharing one request_id. All matching groups stay on
one page and count as one request. Dates and quantities cover only matching day
entries, including only the in-window portion of an overlapping request. A capped
read marks groups incomplete and omits totals; narrow the window to reduce the
upstream read. Existing requests must be changed
or cancelled in Workday; this toolkit cannot modify them.
requests[].dates are YYYY-MM-DD dates inside the selected window; out-of-window
days of the same request are excluded. Each group's unit applies only to that group.
result_count, total_count, limit, and offset count distinct request IDs, not groups.
Page with has_next_page and next_offset. results_truncated means the upstream read
was capped; no offset completes that read, so narrow the date bounds or check Workday.
requires_workday_ui_action identifies drafts or sent-back groups needing action;
use their workday_ui_action, falling back to the response's shared guidance.
status=unknown means Workday's status was missing or unrecognized. Check Workday
to confirm its state and any required action; requires_workday_ui_action=false
does not establish that no action is needed for an unknown status. | 2 | ||
Show where the signed-in worker's time-off requests stand right now.
Defaults to no date bound, subject to the read cap. Provide dates to narrow the
upstream search when results are incomplete. Requests come back in ascending order
of their earliest matching date. The first page contains the earliest matching
requests, which may be years in the past when no lower date bound is supplied.
For upcoming or next time off, set from_date to today's date in YYYY-MM-DD;
the unbounded first page does not identify the next time off.
A request with different types, units, statuses, positions, reasons, or notes
appears as separate groups sharing one request_id. All matching groups stay on
one page and count as one request. Dates and quantities describe only matching
entries within the requested window. Capped reads mark groups incomplete and omit
quantity totals. Each group reports its own status and action guidance. Existing
requests must be changed or cancelled in Workday; this toolkit cannot modify them.
requests[].dates are YYYY-MM-DD dates inside the selected window; out-of-window
days of the same request are excluded. Each group's unit applies only to that group.
result_count, total_count, limit, and offset count distinct request IDs, not groups.
Page with has_next_page and next_offset. results_truncated means the upstream read
was capped; no offset completes that read, so narrow the date bounds or check Workday.
requires_workday_ui_action identifies drafts or sent-back groups needing action;
use their workday_ui_action, falling back to the response's shared guidance.
status=unknown means Workday's status was missing or unrecognized. Check Workday
to confirm its state and any required action; requires_workday_ui_action=false
does not establish that no action is needed for an unknown status. | 2 | ||
Check whether Workday accepts each date for the selected time-off type.
Send the candidate dates together before creating a request. Each result separates
date acceptance from the configured default and existing bookings. A default does
not establish a maximum, and a missing default says nothing about the worker's
schedule. Accepted dates therefore have unknown capacity; Workday validates the
requested quantity on submission.
Booking totals include only matching known units and position scope. Incompatible
units or ambiguous positions leave the total unknown. Worker-based checks include
bookings regardless of their position reference; position-scoped checks exclude
bookings against another position. Incomplete booking lookups omit all booked totals
and disclose that the booking names shown are partial results.
dates[].valid reports date acceptance, not available quantity. valid_count counts
accepted dates. bookable_spans stays empty because maximum capacity is unknown;
this does not mean none of the dates are valid. Read coverage_note for lookup limits. | 2 | ||
Request time off for the signed-in worker, asking for a draft by default.
Set mode to submit only when the worker asks for submission. Existing drafts must
be submitted in the Workday UI; existing requests must also be changed or cancelled
there. The receipt reports the confirmed state, or created_status_unknown when
read-back cannot confirm it. In that case, look up the request's status using the
returned identifiers; do not repeat the create. Recorded amounts appear in days;
requested_days preserves the values sent, and missing amounts are unconfirmed. The type's
rules are resolved from Workday first, so a reason, a position, and an omitted
quantity are checked against that type before anything is written. Workday owns the
rest of the validation; its rejections come back as errors describing what to change.
In the receipt, days[].date matches the requested date and days[].unit labels only
that entry's recorded amount. Missing quantity means unconfirmed, never zero.
requested_days contains the quantities (including defaults) and clock times sent.
status is draft_saved, submitted, approved, or sent_back when confirmed;
created_status_unknown means the request exists but its state is unknown, and
blocked_by_warning means nothing was written. requires_workday_ui_action=false
on an unconfirmed receipt means no action was established; read status before advising. | 2 | ||
Identify the Workday worker the connection is signed in as, and their jobs.
Call this before acting on the worker's record so the answer is anchored to the
right person and tenant. Every other tool in this toolkit acts on this same worker
and cannot be pointed at anyone else. | 2 |
Last updated on