Deploy, promote and install are three different actions on three different objects

A clean validation, covered in Workday Extend validation errors: find the real failure, only proves the app's source is legal. It says nothing about whether the tenant you're pushing to is ready to receive it. Getting an app live involves four separate actions, each against a different system, and each can fail on its own: Build, when App Hub compiles uploaded source into a versioned build; Deploy, when that build is pushed to a WCP Development tenant and labeled the Development promotion level; Promote, done from the Developer Site Console's Apps section, which moves the latest passing build to the next promotion level — Development, Implementation, Sandbox, then Production, in that order, never skipping one; and Install, done from the Workday Extend App Manager worklet on the target tenant, which makes a promoted version usable there.

When someone says an app “won't deploy,” the first thing to pin down is which of these four actions is actually the one refusing — the fix, and the system that owns it, is different for each.

What has to exist before the first non-Development install

Before you can install a Workday Extend app on any tenant beyond Development, Workday requires: the Workday Extend App Manager worklet added to that tenant's Workday Home page; every Workday Extend security domain in the System functional area enabled, with a security policy created for each one; and membership in a security group with Modify access on the Manage: App Manager domain, since that's what App Hub checks before it lets you deploy at all.

If the Workday Extend App Manager worklet shows your app on its Needs Attention tab on the Development tenant, redeploy it there first. Nothing beyond Development will accept a build that Workday still considers unresolved on its own home tenant.

The target tenant may not be enabled for Workday Extend at all

When you purchase Workday Extend, Workday automatically enables your Implementation, Production, Sandbox and Sandbox Preview tenants for it. The setting itself sits on the Manage Workday Cloud Platform task, secured to the Security Administration domain; your Named Support Contact enables it, and Workday notes that the same setting has to be enabled on that task in your Sandbox and Production tenants.

Before assuming a promote or install failure is the app's fault, run the Domain Security Policies for Functional Areas report against the System functional area on the target tenant and confirm the Workday Extend domain has active security policies there. An app that promotes cleanly through the Developer Site can still have nowhere to install if the receiving tenant was never enabled.

A security domain that isn't enabled, or isn't activated, blocks the deploy at two different levels

There are two separate sets of security domains involved, and both have to be current on the target tenant. At the platform level, Custom Business Process, Custom Task, Manage: App Manager and WQL for Workday Extend each need their own security policy, created through Create Security Policy for Domain and pushed live with Activate Pending Security Policy Changes. A policy that's saved but never activated behaves, from the app's point of view, as if it doesn't exist.

At the app level, a security domain authored inside App Builder defaults to the label My Security Domain until you rename it, and only takes effect once the corresponding flag is set — enabledForPageSecurity for a page, enabledForOrchestrationSecurity for an orchestration. Each of those app-defined domains still needs its own security policy configured, and activated, separately on every tenant the app is installed to; a policy that exists in Sandbox doesn't travel with the app when it promotes to Production.

Orchestration credentials belong to the tenant, not to the app version

An orchestration's authentication — API Key, Basic Authentication, OAuth, or Integration System User — is configured as a named credential, and that credential is tenant-specific. A credential created while developing on the Development tenant does not exist on Implementation, Sandbox, or Production; it has to be recreated on each tenant the app is promoted to, under the same credential name the app's source expects.

Sandbox and Sandbox Preview are a common trap: even though they can share the same promoted app version, each needs its own refresh tokens created separately on the external client credential store. Create a business object in Sandbox Preview without a matching refresh token there, and requests against it return HTTP 500 even though the identical request works on Sandbox. For the specific error text these credential problems produce at runtime, see Workday Orchestrate errors and what they mean.

Model components move on Workday's weekly schedule, not on your click

An app's model components — its business objects, business processes and the security domains defined on them — only reach a tenant during Workday's Weekly Service Update, not immediately when you promote. Promote before your region and data center's weekly deadline (Thursday, in most cases) and the update lands the following Friday night; promote after it, and the update waits a full week. Until that update runs, you can't install the app on that tenant at all, no matter how many times you click Install.

If a colleague reports that an already-installed app is missing model components, that's usually a caching issue rather than a failed deploy: ask your account's Developer Support Contact whether the Refresh Extend Model Components Cache task needs to run before you go looking for a defect in the app itself.

Promotion only moves one step at a time, and it replaces what's already there

You can promote an app from Development to Implementation, Implementation to Sandbox, or Sandbox to Production — never further in one step, and never out of order. Each promotion replaces the version of the app currently sitting at that level; there's no side-by-side versioning once you're past Development. Promoting to Production specifically requires reading a checklist on the Developer Site and confirming My app meets these criteria before Workday lets the promotion through.

Once an app is installed on an Implementation, Sandbox, or Production tenant, it can't simply be removed from that tenant — only retired. Plan the first install on a non-Development tenant accordingly; it's a one-way door for that tenant.

A model change rejected at promotion is a lifecycle rule, not a syntax error

Once an app has been promoted past Development, Workday only allows specific changes to its model components. On a business object, you can still change a label, a name, or a security domain assignment, or flip a handful of named attributes — but not, for example, change a field's underlying type. Business processes, tasks and reports have their own, shorter lists of what's still changeable after promotion. A field or property that isn't on the allowed list is rejected at promote time, even though the exact same source validates and builds cleanly as a standalone change on Development.

When a promotion fails only on a later version of an app that's already live somewhere beyond Development, compare the specific model property you changed against what's actually allowed after promotion, rather than re-reading the component's validation rules again — validation already passed; this is a different check.

A Sandbox refresh can silently uninstall your app

Sandbox tenants are refreshed regularly from Production data, and Implementation tenants get refreshed too. If a Sandbox tenant refreshes before you've installed your latest version on Production, or an Implementation tenant refreshes from a source tenant where the app was never installed, the app has to be reinstalled on that tenant from scratch — and reconfigured: business process definitions, business process security policies, custom tasks and domain security policies all have to be recreated, not just the app itself reinstalled.

If a deploy that worked last week suddenly fails, or the app's configuration has reverted, check whether the tenant was refreshed in between before debugging the app. See what a Sandbox refresh actually resets for the refresh cadence and what it does and doesn't preserve.

Confirm the fix at the same tenant, not just on the Developer Site

A promotion or install that finally goes through on the Developer Site still isn't proof the app works for its users on that tenant — security domain activation, model component timing and installed configuration all sit outside what the Console shows you. Use the Workday Extend testing method to confirm the deployed app behaves correctly for the intended roles once it's actually installed.

kiweely builds, validates and deploys Extend apps against a client's own tenant, one step at a time, so it hits these same tenant-level checks — a missing security policy, an uncreated credential, a tenant that isn't Extend-enabled — directly rather than guessing from the source alone.

For component-level validation or build failures that happen before any of this, go back to Workday Extend validation errors: find the real failure.

Sources checked