Promoting a Workday Extend app to Implementation, Sandbox and Production: deadlines, undoing it, and the security you need

How to promote an Extend app from Development to Production

You promote an Extend app from the Workday Developer Site, one level at a time: Development to Implementation, Implementation to Sandbox, Sandbox to Production. Each promotion replaces whatever version sat at the target level, and an app with model components only becomes installable on the target tenant after the next Weekly Service Update, so the timing is set by a weekly deadline, not by when you click.

Open Console > Apps, select the app, and go to the Promotions tab. From there you deploy to Development tenants, promote to the next level, and install on Implementation, Sandbox and Production tenants. The wdcli app promote <appRefId> --level implementation command does the same, and Workday's CLI reference says it follows the same deadlines as the Developer Site.

What each step actually promotes:

Each level only offers a promotion to the next one, so an app reaches Production through Implementation and Sandbox. Implementation always gets the most recent build of the latest Development version that passed: if your newest upload fails to build, promoting sends the last passing build, not the code you just changed.

The weekly promotion deadline for model components

Business objects, business processes, security domains, tasks, reports and other model components don't deploy on promotion. They deploy to Implementation, Sandbox and Production tenants as part of Workday's Weekly Service Update on Friday night. Workday's promotion deadlines reference sets the cut-off by data center:

Promote before the deadline and the model components deploy that Friday night. Promote after it and they wait for the Friday a week later. Until they arrive, you can't install the app on that tenant.

Two related timings are easy to miss:

• Other updates to the app reach the tenant straight away, except when model components from that app are already queued for an upcoming Weekly Service Update. Then the whole update waits for the service update to finish.
• After promotion, Implementation tenants can take up to 1 minute to refresh the cached app, and Sandbox and Production tenants up to 15 minutes.

For a first go-live, Workday says to promote an app with model components to Production 1 week before your Production tenant is created from the Gold tenant. Otherwise the app isn't installable in Production until after a later promotion.

You can't undo a promotion, only replace or retire

There is no demote. Three documented rules make promotion effectively one-way:

1. Installed apps stay installed. Once you install an app on an Implementation, Sandbox or Production tenant, you can't remove it from that tenant.
2. Most model changes are add-only. Workday's model components page says a later version can't remove model components that deployed in an earlier one: you add components, fields and security domains. The allowed updates reference lists the exceptions property by property. A report, a task, a model profile group or a derived field can be removed; a business object or an ordinary field can't. Among the changes allowed, a field's label, name and security domain can change, enableReportingFromTarget can only go from false to true, and an Approval step can lose actions but never all of them or only SEND_BACK.
3. Deleting is replaced by retirement. A promoted app can't be deleted from App Hub; it must be retired.

To roll back a bad change, fix the source, let a new build pass in Development, and promote it forward again. The new version replaces the old one at each level. Plan model changes with that in mind; the guide to Extend schema changes covers how to evolve business objects you can no longer remove fields from.

What retiring an app does

Retirement happens at the app's highest promotion level (an app promoted to Implementation is retired there), only a Company Admin can do it, and only from the Retire App option on the app's action menu, not the CLI. It removes the app and all its versions from every promotion level, it's irreversible, and the reference ID can never be reused, though the name can.

A retired app stops working: pages and orchestrations stop, and its model tasks disappear from search, related actions, dashboards, hubs, journeys and the other places they were surfaced. Custom Agent Actions in it stop too and should be removed from every agent they're registered with. Workday keeps the security domains, report fields, business objects, data sources and query indexes in the tenant. Retiring from Production frees the app's entitlement and stops it counting towards future data limits; data already used still counts. See Concept: App Retirement for the full list.

Security each non-Development tenant needs

Promotion makes an app available; it doesn't make it usable. Each Implementation, Sandbox and Production tenant needs this before install:

• Workday Extend enabled on the tenant. Workday enables Implementation, Production, Sandbox and Sandbox Preview tenants when Extend is purchased. The setting lives on the Manage Workday Cloud Platform task, and the same setting must be enabled in Sandbox and Production.
• Extend domain policies. Use Create Security Policy for Domain for the Workday Extend domain in the System functional area, then create policies for Custom Business Process, Custom Task, Manage: App Manager and WQL for Workday Extend, and run Activate Pending Security Policy Changes. Workday's install page asks for these policies to grant Modify access.
• The App Manager worklet on the installer's Home page.

After install, open the app in App Manager, click Configure, and set up the tenant-specific pieces: domain security policies for the app's model security domains, business process definitions and their security policies, custom tasks, app attributes and ISUs. The Extend security domains guide explains how those domains map to pages and tasks.

ISUs and credentials

If the app uses the simplified ISU authentication scheme, repeat the ISU setup in each non-Development tenant: create the ISU, assign it to the app in App Manager and create its API client there. Then a Company Administrator must open Console > API Clients on the Developer Site, select that tenant's API client for the app, click Modify Authorized Tenants and add the tenant. Development tenants are authorized automatically; non-Development tenants aren't. After an Implementation or Sandbox refresh from Production, those tenants are tied to the Production API client, so the administrator adds their consent to that client.

Apps using OAuth or the legacy WCPISU scheme need their Cred Store entries re-created with Create External Client CredStore in each tenant, with the App ID matching the appId in the SMD's authTypes. On Sandbox, create refresh tokens in both Sandbox and Sandbox Preview; Workday warns that missing Sandbox Preview tokens cause HTTP 500 errors on business objects there. Apps with connectors need a Production account configured for each connector before you promote to Production.

Refreshes that undo an install

The one way an install disappears is a tenant refresh. If you refresh Implementation from a tenant where the app isn't installed, or Sandbox refreshes before the app is installed in Production, you must reinstall the app and re-create its business process definitions, business process security policies, custom tasks and domain security policies. Installing in Production promptly after promotion avoids the second case. The Sandbox refresh guide lists what else a refresh resets.

How to confirm a promotion landed

• On the Developer Site Promotions tab, the target level shows the version you expect.
• On the target tenant, App Manager lists the app on Ready to Install the first time, and afterwards on Custom Apps, where the App Information column shows the version name and Promotion Level shows the level. When Ready to Install displays a reason the app can't be installed, check whether you made the Thursday deadline: an app with model components can't be installed until they deploy.
• If model components still don't appear after the service update, Workday's install page says to contact your Developer Support Contact about running the Refresh Extend Model Components Cache task.