Do I need Workday Extend, or is this a configuration change?

If the request is a new field, a new approval step, a rule that decides which path a business process takes, a report, or a notification — it's configuration, and building an Extend app for it is over-engineering. If the request needs its own screen with custom logic, its own data model with its own security, a multi-step guided task Workday doesn't already have, or a step that talks to another system, that's when an Extend app earns its complexity.

Most requests that sound like "we need an app" are actually a custom object, a condition rule, or a calculated field away from done. The rest of this guide walks through both sides of that line with concrete examples, so you can place a specific request correctly before you scope it.

What Workday already does without Extend

Workday's own configuration layer covers more ground than most requests need:

  • Custom objects and custom fields — attach new data to a Workday business object (Worker, Position, Organization, Supervisory Organization, and others). Each extendable business object supports up to 200 active custom fields, split across effective-dated and non-effective-dated versions of the object, and a multi-instance custom object can hold up to 1,500 instances managed from the Workday UI. That covers nearly every "track this extra thing about a worker or position" request.
  • Business processes — add, remove, or reorder approval steps; route a step to a different security group; add a condition that skips a step entirely.
  • Condition rules — the decision logic behind a business process step: whether a step runs, who approves it, which value a field defaults to.
  • Calculated fields — derive a value from existing data (tenure, a lookup across related objects, a formatted string) for use in a report, a condition rule, or a notification.
  • Custom reports — surface any of the above, including custom object data, in a report your users already know how to run and filter.
  • Notifications and Workday-delivered tasks — alert someone when a step completes or a value changes, using the task and event framework Workday already ships.

All of this lives in Workday's own configuration screens. You still move it between tenants, but there is no separate app to build, version or deploy.

When an Extend app is genuinely warranted

Reach for Extend when the request needs one of these, which configuration can't provide:

  • A custom page or custom task with its own layout, validation, and interaction — not a form Workday's delivered tasks can be configured to produce.
  • Extend business objects — a data model that doesn't map onto a Workday business object at all: it needs its own fields, its own instances, and its own security domains, independent of any existing Workday object.
  • Orchestrations and integrations — a step that has to call an external system, run asynchronous logic, or coordinate a sequence of actions across services, not just evaluate a condition against data already in the tenant.
  • Multi-step guided experiences — a workflow that walks a user through several screens with branching logic, not a single business-process step.

Example requests, and which way each goes

  • "Track a certification expiration date on each worker." Custom object with a Date field on Worker. Configuration.
  • "Skip the second approval if the requested amount is under a threshold." Condition rule on the business process step. Configuration.
  • "Show tenure in years, rounded, on a report." Calculated field. Configuration.
  • "Let managers submit a request through a multi-screen wizard that checks eligibility against three unrelated systems before it lets them proceed." Extend app — custom pages, orchestration to the external systems, and business logic no condition rule can express.
  • "Store and secure a dataset that has nothing to do with any existing Workday object — vendor certifications with their own approval workflow and their own audience." Extend business object with its own security domains. Configuration can't create data that isn't attached to a Workday object.
  • "Send an email when a business process completes." Notification. Configuration.

Custom object vs. Extend business object

These sound similar and are easy to conflate. A custom object extends a Workday business object — it adds fields to Worker, Position, or another object Workday already ships, and you secure it with a domain you configure for it and report on it alongside the object it extends. It's created and edited entirely in Workday's own configuration screens.

An Extend business object is a model component built as part of an Extend app. It defines its own fields, its own security domains, and its own instances, independent of any Workday-delivered object. An app can define up to 20 business objects, each with up to 50 fields, and a custom page or orchestration can then read and write those instances.

Use a custom object when the data genuinely belongs to a Workday object and reporting on it next to that object is what you want. Use an Extend business object when the data has no natural home on an existing object, or needs security and behavior that a custom object's model can't express.

What each path costs to own

Licensing decides whether Extend is available at all — that's a separate conversation with Workday. Setting cost aside, the two paths differ in what they cost to run once they're built:

  • Configuration moves between tenants with Workday's own migration tools and takes effect when it is saved. An Extend app is versioned and promoted independently, and an app with model components only becomes available in a tenant as part of a Weekly Service Update — so a change has to be promoted ahead of a weekly deadline, not just saved.
  • Configuration limits are generous but real. 200 active custom fields per business object, 1,500 UI-managed instances per multi-instance custom object (10,000 via the REST API). An Extend app has its own ceilings per app — 20 business objects, 50 fields per business object, 5 business processes, 20 tasks — which shape how many distinct concerns you can fit into one app before it needs to split.
  • An Extend app is a maintained asset, not a one-time configuration change. It has its own security model to keep current, its own versions to promote through Sandbox and Production, and its own dependency on the app's continued compatibility with tenant updates. Configuration has none of that separate lifecycle to own.

This is the same question kiweely answers before it starts building: whether a request is a configuration change Workday already supports, or genuinely needs an Extend app, so the app that gets built is the one the request actually needed.