Extend pages are for people who sign in to the tenant

The pages and tasks of a Workday Extend app run inside the customer's Workday tenant, for a signed-in Workday user, under the app's security domains. Every place Workday documents for opening an Extend task is part of the tenant's own navigation: the Global Navigation Menu, dashboards, hubs, landing pages, Shortcuts, announcements, alerts, To Dos and Journeys (Concept: Use Model Tasks to Access Extend Apps in Workday). The documentation lists no entry point on an external career site or any other public page.

So if the people who need the app are job candidates, applicants or anyone else without a Workday sign-in, an Extend page is the wrong tool. Workday's documented answer for an audience outside the tenant is an external Extend app: a third-party application with its own UI that reads and writes Workday data through APIs and orchestrations. External apps can use orchestrations, do not use presentation or model components, and do not run on a Workday tenant (Concept: External Extend Apps).

First decide which kind of "external" user this is

The design depends on whether the person can sign in to Workday.

They have a Workday account. Anyone who signs in to the tenant is an ordinary user to an Extend app: put their security group on the app's domains and give them a task entry point, as for employees. To route or restrict by a person, the business object can carry a secureByTarget field; see secureByTarget and Extend security domains.

They have no Workday account. Candidates are the common case. Workday is explicit that a business process step cannot be reassigned to someone without an active Workday account, and names a candidate as the example (Reassign Tasks). Without a Workday sign-in they cannot open your Extend pages or work an Extend task. They need an external app.

Internal users working on candidate data are a third case, and Extend pages suit them well. A recruiter-facing Extend app can keep its own business object that references Candidate or Job Application through a SINGLE_INSTANCE field; Workday's restrictions page describes how purges and duplicate-person merges affect such references, so read it before relying on them (Concept: Restrictions on Target Workday Business Objects). The View Business Objects Available to Extend report shows which delivered objects support a target.

The external app pattern

An external app has three parts:

  1. Your UI, hosted wherever you host web applications. Workday offers the open-source Canvas Kit and the Canvas Design System if it should look like Workday.
  2. An API client registered in the Developer Site Console under API Clients, with a redirect URI, the scopes for the REST resources you call, and, for browser calls, the authorized CORS domains in the form protocol://domain:port (Create Your API Client).
  3. The Workday side: REST or Graph API calls, or an orchestration that does the work and returns a result. Orchestration Builder's Download OpenAPI on the Settings tab exports the orchestration's interface for the external developer to build and test against (Export OpenAPI Specifications for Orchestrations).

As a design choice rather than a documented rule, put multi-step logic in an orchestration instead of many direct API calls: the external app stays small, and validation and writes run inside Workday, where you can read the run. How to design that interface is covered in exposing an orchestration as an API.

Choosing the authorization flow

Workday Extend supports four OAuth 2.0 flows; access tokens are bearer tokens that expire after 60 minutes (Concept: Authorization Flows).

  • Authorization Code, or Authorization Code with PKCE. The authorization request shows a tenant sign-in page, so use these when the external users do have Workday accounts. Authorization Code is for a web app running on a server; PKCE lets a public client protect the code exchange.
  • Implicit. For browser apps that retrieve the token directly. The authorization request still shows the tenant sign-in.
  • Client Credentials. No user. The client ID and secret are exchanged for a token whose subject is an Integration System User you map to the client with Create Client Credentials Mapping (Authenticate Using the Client Credentials Grant Type).

For candidates, only Client Credentials fits, because there is no Workday user to sign in. That shapes the security of the whole app:

  • Run the token exchange on your server. The client secret must never reach the candidate's browser, so the browser talks to your server, not to Workday directly.
  • Every call runs as the Integration System User. Give that ISU only the domains the app needs, and decide in your server what each candidate may submit or see; Workday cannot tell one candidate from another when they all arrive as the same system user.
  • Validate input on your server and again in the orchestration before writing anything.

The ISU and API client setup is covered in integration system users and API clients.

A worked example: a candidate-facing intake form

Suppose recruiting wants candidates to submit a profile and résumé from a public page. The Recruiting REST API (v4) has POST /prospects, which requires candidate.name.country.id at minimum, and POST /prospects/{ID}/resumeAttachments, which requires fileName and attachmentContent. Both are secured by the Create External Prospects and Set Up: External Career Site Access domains, so the Integration System User needs those. The flow:

  1. The candidate fills in the form on your site.
  2. Your server gets a Client Credentials token for the mapped ISU and calls an orchestration (or the Recruiting API directly) with the submitted fields.
  3. The orchestration validates the data, creates the prospect, attaches the résumé and returns a reference your page can show as confirmation.
  4. Recruiters work the result inside Workday, where an Extend page or a standard report can pick it up.

Both endpoints list the Recruiting scope; scopes come from the endpoint descriptions in the REST API Explorer, and you select them on the API client.

Moving from Development to a customer tenant

You build and test the API client against your development tenant. Before the external app can call an implementation or production tenant, the client ID must be on that tenant's allowlist, and only a Company Administrator can add tenants with Modify Authorized Tenants (Create Your API Client). Plan for that step and the matching Client Credentials mapping in each tenant.

How to prove it works

Test from outside, as the real audience would:

  1. Open the external page in a private browser session with no Workday sign-in, submit a test record and confirm your page shows the confirmation.
  2. In the tenant, find the record the call created (the prospect, or your business object instance) and confirm every field and attachment arrived intact.
  3. Read the orchestration's run and its step messages in the app's logs, and confirm each step did what you expected.
  4. Try a submission the server should reject, such as a missing required field, and confirm nothing was written in Workday.
  5. In the browser's developer tools, confirm no request carries the client secret and no request goes from the browser straight to the Workday token endpoint.

Sources checked