What has to be switched on before anyone can build

Orchestrate for Integrations is turned on from your Production tenant, not from the Developer Site. If your organisation is on the Universal Main Service Agreement (UMSA) the feature is already available; on the older Main Service Agreement (MSA) someone with the Manage: Innovation Services domain has to opt in, and in both cases a Developer Site company with an administrator has to exist before anyone can open Orchestration Builder.

You can find which agreement you are on from your organisation's profile on Workday Community, where the Subscription Service Agreement value reads either UMSA or MSA. UMSA tenants have no Innovation Services tasks or reports at all, so a search for them that returns nothing is expected.

For an MSA tenant, the opt-in is five steps in Production:

  1. Run the Innovation Services and Data Selection Opt-In report.
  2. On the Available Services tab, open the WCP section.
  3. Select Workday Orchestrate for Integration.
  4. Click Next, Next, then OK.
  5. Run Maintain Workday Build Company for Orchestrate for Integration and enter the name and email of the person who will administer the company on the Developer Site.

That administrator can then sign in to developer.workday.com and add the people who will build, from Console > Users > Add a User. Two limits from Workday's user-management page affect planning: a customer company holds at most 55 users, and it must always keep at least 2 active Company Administrators, so name a second administrator early or you will not be able to change the first one's role later. New users' email domains must match the domain you gave Workday.

Which tenants you will actually build and test in

Workday's Orchestrate course manual states that customers who buy only the Orchestrate for Integrations SKU do not get Development tenants; those come with the Workday Extend SKU. In practice that means your first deploy goes to an Implementation tenant, and from there the app is promoted to Sandbox Release and then Production Release. Promotion cannot be reversed: once you promote, the next round of testing happens in the next environment in the chain.

If you have an Extend subscription, or you are learning on a personal Developer Site account, you do have a Development tenant, and deploying to it installs the app there automatically. The personal and company developer accounts differ in more than tenants, so check which one you are signed in with before you start.

Build the app and its first orchestration

Everything you build lives inside an integration app. On the Developer Site home page choose Create an Integration App, then Start from Scratch (the other options copy an App Catalog app or upload a zip). Give it a name and a Reference ID. The Reference ID matters more than the name: the integration system in the tenant finds your app by it.

On the app's Overview tab, Add Orchestration asks for a template. For a scheduled or launched integration pick Workday Integration System; Orchestration Builder then opens the orchestration with an Integration Framework Trigger at the top and Orchestration End at the bottom. The other template, Workday Business Process, starts from a Business Process Trigger instead, and the difference between the two is covered in Integration System vs Business Process templates.

A first orchestration that proves the wiring works needs only one step. Drag Add Integration Message from the Orchestration Logic group of the Components panel between the trigger and the end, leave Severity at INFO, and set Summary to a string such as "Equipment Request export started". That message is written to the integration event in the tenant, which is exactly what you will look for when you test.

Click Validate to run schema, semantic and syntax checks before saving. Workday notes that Orchestration Builder does not run every schema check as you type, so a clean canvas is not proof that the build will succeed. Save to App Hub validates again and produces a build log; build failures, including ones in orchestrations you do not have open, show in Build Logs at the bottom of Orchestration Builder.

Deploy from Console > Apps, choose the app, and on the Promotions tab click Deploy beside the target tenant. In an Implementation, Sandbox or Production tenant the app then has to be installed: open the App Manager worklet, find the app on Ready to Install and click Install. App Manager requires the Workday Extend security domains in the System functional area to be enabled, with security policies that give Modify access. Installation is one-time per tenant and is permanent; later versions do not need a reinstall, but the app cannot be removed from that tenant once it is there.

The orchestration does nothing until an integration system points at it. In the same tenant:

  1. Run Create Integration System, give it a name, and choose Orchestrate Integration Template as the template.
  2. From the integration system's related actions choose Integration System > Configure Integration Attributes.
  3. Set Orchestration Name to the orchestration's name exactly as it appears above the Components panel in Orchestration Builder.
  4. Set Application Reference ID to the app's Reference ID, copied from the About section of the App Overview page.

Those two attributes are the whole link. A typo in either, or an app deployed to a different tenant from the integration system, are the two causes Workday's tutorial tells you to check when a first launch fails.

Promotion only moves the app. The course manual is explicit that the integration system, and any custom report a RaaS step reads, have to be moved to the next tenant separately, for example with Object Transporter. If you are moving configuration between tenants, the Object Transporter errors guide covers what goes wrong there.

How to prove the first run worked

From the integration system's related actions choose Integration > Launch / Schedule, click OK twice, and refresh the View Background Process page until the event finishes. Open the Messages tab. Your INFO message should be there with the summary text you set. If it is missing, or an error sits in its place, check three things in this order: that App Manager shows the app installed in this tenant, that the Orchestration Name matches character for character, and that the Application Reference ID is complete.

Once the message appears, the plumbing is proven and you can add real work. Workday's own outbound tutorial grows the same orchestration step by step:

  • Add launch parameters on the integration system with Maintain Launch Parameters (for example a required Date called "Effective Date" that defaults to Current Effective Date at runtime).
  • Read them in a Create Values step with the lp global functions: lp.date("Effective Date") returns the date as an ISO string with offset, and lp.simpleData("Name") returns a text parameter. The label must match the launch parameter name exactly.
  • Call Workday with Send Workday API Request, for example a GET to /staffing/v4/workers with a search query parameter, and set the response type to Json on the Settings tab.
  • Pull fields out with stringAtJsonPath, such as $.data[0].primaryJob.businessTitle.
  • Format the output with Create Text Template and attach it with Store Document, setting Attach document to integration event to boolean true (not the string "true").

After the next launch the file appears on the Output Files tab of the background process, which is the proof for an outbound integration.

Authentication you will need before going past a test

Workday's tutorial leaves the API call on Default Workday API Credential and notes that with an integration system user you would pick the ISU's credential instead. For a scheduled production integration, an ISU is the usual choice. That needs the WCP Integration System User Security domain, an ISU assigned to the app in App Manager > Configure, an API client created from that row, and an ISU credential on the orchestration's Settings > Credentials tab. The setup and the errors it produces are in the ISU and API client guide.

While you build, Orchestration Builder deploys, runs, debugs and imports credentials through a single tenant connection per app. How that connection works, and why it asks you to reconnect after 60 minutes, is in Global Tenant Connect in Orchestration Builder.

kiweely is useful at the linking stage: working in your Implementation or Sandbox tenant as you, it can create the integration system, set the two attributes from the app's real Reference ID, launch the integration and read the Messages and Output Files back, so a mismatch shows up as a specific value rather than a failed event.

Sources checked