Reference · built on requestConnectorHR, scheduling & workforce

Workday

Workers, absence balances, time clock events, and staffing changes from a Workday tenant through its REST services and SOAP web services.

About

Workday is a cloud HCM suite that runs as a tenant on a Workday-hosted URL. Its REST Services Directory publishes an OpenAPI 2.0 schema per service: Absence Management v5, Staffing v7, Time Tracking v6, Person v4, and Common v1 among them, each rooted at https://<tenantHostname>/<service>/<version>. Every endpoint is secured by one or more Workday security domains and a functional scope. Older SOAP services such as Human_Resources and Time_Tracking remain in the Workday Web Services directory.

An operator on Fibric reads workers, absence balances, time clock events, and time blocks, and proposes time off requests or check-in corrections for your approval. Each proposal leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Workday and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Workers and current staffing information through GET /workers in the Staffing v7 and Absence Management v5 services
  • Absence plan and leave of absence balances per worker through GET /balances in Absence Management v5
  • Time off details, leaves of absence, and eligible absence types for a worker, addressed by Workday ID, Employee_ID, or me
  • Time clock events, check in and check out, for a worker over a date range through GET /timeClockEvents in Time Tracking v6
  • Worker time blocks and a summary of reported hours per period through /workerTimeBlocks and /workers/{ID}/timeTotals
  • Supervisory organizations with their members and org charts, plus job profiles, job families, and jobs
  • Change Job and Change Organization Assignment events through the Staffing v7 jobChanges and organizationAssignmentChanges resources

Proposed actions

  • Target capability: propose a time off request for a worker through POST /workers/{ID}/requestTimeOff, which starts the Request Time Off business process
  • Target capability: propose a time off correction through POST /workers/{ID}/correctTimeOffEntry
  • Target capability: propose check-in and check-out events for workers through POST /timeClockEvents
  • Target capability: propose a worker time block through POST /workers/{ID}/workerTimeBlock
  • Target capability: propose a Change Job request through POST /workers/{ID}/jobChanges, its PATCHed details, and POST /jobChanges/{ID}/submit

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a missed punch before the period closes

    Read time clock events and time totals for the period, flag workers with an open check-in or no reported hours, and propose the correction for a manager to approve.

    With Missed Punch, Timesheet Signoff

  • Keep leave and the roster in step

    Read absence balances and leaves of absence, compare them with scheduled shifts, and propose a time off request or a coverage change.

    With Leave Conflict, Shift Coverage

  • Act on a job change the day it takes effect

    Watch Change Job and organization assignment events, then propose the access and equipment steps a move implies.

    With Onboarding Checklist, Offboarding Sweep

Requirements

  • A Workday tenant and its hostname; each REST service is rooted at https://<tenantHostname>/<service>/<version>
  • An OAuth 2.0 client the tenant authorizes for the functional scopes in use, for example Time Off and Leave, Staffing, and Time Tracking
  • Security domain access for each endpoint, for example Process: Time Clock Event REST API's or FLW Service
  • A Workday Community login to read Workday's own authentication and setup guides, which are not public
Authentication
OAuth 2.0 against the tenant's authorization hostname, as declared in each service's OpenAPI schema; the tenant grants the security domains each endpoint names.

Limits

  • Endpoints are gated by Workday security domains and business process types; an endpoint the tenant has not opened cannot be read
  • Requesting time off is a three-step sequence: eligibleAbsenceTypes, then validTimeOffDates, then requestTimeOff as a multipart request
  • GET /workerTimeBlocks omits incomplete time blocks, time offs, and overtime request blocks; the Staffing workers resource covers non-terminated workers only
  • Workday's REST Services Directory documents no request rate limits; pacing is agreed per deployment

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Workday ↗

Questions and answers

Which Workday services does this connector read?
Absence Management v5, Staffing v7, and Time Tracking v6 from Workday's REST Services Directory, each with its own OpenAPI 2.0 schema. Person v4 and Common v1 cover contact and organization data. Older SOAP services such as Human_Resources remain in the Workday Web Services directory at v47.0.
How is a REST call authorized in Workday?
With OAuth 2.0. Each service schema declares an OAuth2 security definition against the tenant's authorization hostname, and each endpoint names the security domain and functional scope it is secured by, for example FLW Service and Time Off and Leave. Your tenant administrator grants those domains.
Can the connector identify a worker without a Workday ID?
Yes. Worker endpoints accept a 32-character Workday ID, a reference ID in the form Employee_ID=value or Contingent_Worker_ID=value, or the named entry me for the calling user.
Ask about Workday

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.