What Global Tenant Connect does
Global Tenant Connect is Orchestration Builder's single sign-in between the app you have open and one Workday tenant: you connect once, and every orchestration in that app uses the same connection for deploying, running, debugging, importing credentials and linking integration systems. The connection belongs to the app, lasts at most 60 minutes, and can only point at a development, implementation or sandbox tenant in your Developer Site organisation, never Production.
Workday documents the feature on two identical pages, one under Extend apps and one under integration apps, so it behaves the same whichever kind of app you are building.
How to connect, switch and disconnect
Click Connect to Tenant in the Orchestration Builder header, pick a tenant and click Connect. If the tenant sends you to a single sign-on provider and you need to sign in with a tenant account instead (a test persona, for example), tick Bypass single sign-on first; it opens the tenant's own login page.
Once connected, the same header button shows which tenant you are on and offers two actions:
- Switch Tenant moves the app's connection to another tenant.
- Disconnect ends it. Workday's page says to reload the browser page afterwards.
If you have not connected and a step needs the tenant, Orchestration Builder sends you to Manage Tenant Connection to connect there and carry on.
What the connection is used for
Five activities read the connection, and each follows it when you switch:
| Activity | What uses the connected tenant |
|---|---|
| ActivityDeployment | What uses the connected tenantDeploy sends the app to the connected tenant. After a switch, the next deploy goes to the new tenant. |
| ActivityRunning | What uses the connected tenantA run executes on the connected tenant. |
| ActivityDebugging | What uses the connected tenantThe debug bar names the connected tenant, and Select Previous Run lists runs from that tenant only. |
| ActivityCredential import | What uses the connected tenantOrchestration Builder lists the app's Integration Credstore entries on the connected tenant. |
| ActivityTriggering integrations | What uses the connected tenantLink Integration System on a Trigger Integration step opens on the connected tenant and imports the chosen integration system with its launch parameters. |
The deployment row is the one that causes mistakes. Because the target follows the connection, a switch made to inspect a sandbox run means the next Deploy also goes to that sandbox. Read the tenant name in the header before deploying, not after.
The credential row explains a common surprise. An Integration Credstore created with Create Integration CredStore is tied to exactly one app through its App ID field (the app's Application Reference), and to one tenant because it lives there. So when you click Connect to a Tenant on the Mutual Auth settings to import a TLS configuration, you see only that app's Credstore entries on the tenant you are connected to. If the list is empty, check those two things: that the Credstore was created on the tenant you are connected to, and that its App ID holds this app's reference. The JWT and mutual TLS credentials guide covers setting those Credstore entries up.
For Trigger Integration, linking is a convenience rather than a requirement. Workday's Triggering Integrations concept page says the integration system doesn't have to be available on the connected tenant, because you can configure the step manually; linking imports the child's launch parameter definitions for you, and Refresh Launch Parameters resets their defaults to the child's later. Using the step to call Studio integrations is covered in calling Studio integrations from Orchestrate.
Why Orchestration Builder asks you to sign in again
Three documented reasons cause a new sign-in, and a fourth connection is easy to confuse with this one.
The 60-minute limit. Each connection lives for at most 60 minutes. After that you are asked to choose a tenant and connect again. Nothing about your build is lost when this happens; only the session to the tenant ends.
You opened another app. The connection is per app. Opening a second app does not reuse the first app's connection, so you connect again. You can hold separate connections for several apps in one browser session and switch between them, each to its own tenant.
Developer Copilot. Workday states that Developer Copilot is not yet part of Global Tenant Connect. When Copilot needs the tenant it asks you to sign in separately, even while the header shows you connected.
API Explorers and App Builder (a different connection). The Developer Site's Manage Tenant Connections icon is a different connection, shared by the Graph, REST and SOAP API Explorers and App Builder, with its own access token that also expires after 60 minutes. The two are separate, but the sign-in carries over: if you are already signed in to a tenant from the Developer Site, connecting in Orchestration Builder does not ask for a password.
Why Production is never in the tenant list
Workday states that Orchestration Builder can't connect to a Production tenant. It is a limit of the tool rather than a missing permission, so changing security in the tenant won't make Production appear.
It has a practical consequence for debugging. Workday's debugging page says an orchestration built on the Workday Integration System template, or one whose suborchestrations use lp or intsys functions or components such as Store Document, Log to File, Add Integration Message or Trigger PDF Generation, must be deployed and run at least once on a tenant before you can debug it. When you debug, Orchestration Builder asks you to pick a recent run, and it imports that run's launch parameters, authentication tokens and documents. Since the debugger only sees runs on the connected tenant and Production can't be connected, a failure that only happens in Production has to be reproduced in a sandbox, by launching the integration there with the same parameters, before you can step through it. Sandbox tenants are refreshed weekly with production data, which makes them the closest place to do that.
Debugging itself is also unavailable for Trigger Business Process, Trigger Integration and Trigger PDF Generation steps, and for Send HTTP Request steps that use polling. For those steps the run logs on the connected tenant are the evidence.
How to check you are connected to the right tenant
Three places confirm the target, and they should all agree before you deploy or debug:
- The Orchestration Builder header, which names the connected tenant.
- The Debugging panel, which shows the connected tenant beside the current step name; Manage Connections at the top of that panel switches it.
- After a deploy, the App Manager worklet in that tenant, where the app should appear on the Installed tab (or Ready to Install for an implementation or sandbox tenant you have not installed it on yet).
If a run you expect is missing from Select Previous Run, check the header first: the list only ever shows runs from the tenant you are connected to now.