The security model is the whole argument for building inside
The strongest reason to build something in Workday Extend is that the app sits on Workday business objects and inherits the tenant's security model. A worker record stays governed by the same domain policies whether a delivered page or a custom one touches it, and field level access follows the person rather than the app. If you are still working out what Workday Extend actually is, start with that inheritance, because every other part of the boundary decision follows from it.
The strongest reason to build outside is the mirror of it. The work is not about Workday data, or it needs a processing pattern, a runtime, or a third party library that has no business running inside an HR system. Heavy document generation, a scheduling solver, an integration that fans out to six systems and retries for two days. Extend gives you none of that, and stacking orchestration steps will not change the answer.
Almost every proposal I have reviewed sits between those two. The argument in the room is about an app that reads a lot of Workday data, writes a little, and calls two outside services on the way through. The boundary gets drawn badly there, usually by whoever is most enthusiastic rather than by whoever will carry the app in two years.
Mostly reading Workday is a fit, mostly orchestrating is not
An app that reads Workday data and writes a small amount back is usually a good fit. A manager tool that pulls a team's position and compensation context onto one page and submits a single business process at the end is the shape Extend was designed for. The reads stay governed, the write goes through a real business process with its own approvals and audit trail, and no second copy of the worker record ever has to exist.
An app that orchestrates several external systems and happens to touch Workday is usually the wrong fit. Take an onboarding coordinator app that sequences a background check vendor, a badge system and an IT provisioning queue, then stamps one field on the worker record at the end. Workday is one participant out of four, and every interesting failure lives in the other three. Building it in Extend buys a security model the coordination logic never needed, while inheriting release constraints it did not need either.
The test I use is to count reads and writes by system rather than by importance. If Workday carries most of the traffic and the other systems are lookups or notifications, build inside. If Workday is one endpoint among several and the app's job is sequencing work across them, put the sequencing in the integration layer you already run and let it call Workday through the normal API. Settling where the business logic should live first saves the rewrite.
What a call out to an outside service really costs
Extend apps can call external services, and the question that matters is what happens to the person staring at the page while the call is in flight. A user facing page that waits on a third party API has taken that API's latency and its availability into a Workday screen. When the vendor endpoint slows to four seconds, the page takes four seconds. When it returns an error at nine in the morning during open enrollment, the page is what looks broken, and the ticket lands with the Workday team.
Failure handling inside a synchronous page is thin. Show an error, let the user try again, and you have used most of the repertoire. There is no dead letter queue in front of a button press and no backoff window a person will sit through. Retry strategies worth having assume the work can outlive the session, and a page cannot.
So the guidance is blunt. A synchronous dependency on a service you do not operate does not belong in a user facing Extend page. Move it behind an asynchronous pattern, where an orchestration or a scheduled integration does the external work and the page reads a result already sitting in Workday, or take it out of the page entirely. If the call has to happen while a user waits, the vendor has to be one you can hold to a latency commitment, and somebody has to own the alerting for when it starts failing.
Custom surfaces move with the tenant's release schedule
Anything built in Extend lives inside the tenant and moves with it. Weekly service updates and the twice yearly feature releases arrive on your custom app whether or not the team has capacity that month. A delivered page that changes behaviour, an object model adjustment, a deprecated API version inside an orchestration, all of it lands on Workday's calendar rather than the app owner's.
That is a real operating cost and it should be priced before the build. Every Extend app adds regression testing to two release windows a year, permanently. Ten apps means a test pass somebody runs and somebody signs, on dates you did not choose. Teams that skip it hear about the breakage from managers halfway through a comp cycle.
Building outside does not escape the problem, it relocates it. External code that calls Workday APIs still tracks version deprecation and object model changes, but you decide when that code moves and you can hold a version while you work. Whichever side of the line you land on, add the app to the release regression list the day it goes live, and pair that with the governance questions that belong before a first custom app.
An Extend app has no natural home team
Ownership decides more Extend outcomes than architecture does. Most organisations have a Workday HCM team that owns configuration and business processes, an integrations team that owns Studio and EIBs, and a development group that owns anything with a source repository. An Extend app fits none of those descriptions. The HCM team calls it code, the developers call it configuration, and the integrations team does not recognise it at all.
The apps that survive are the ones somebody was assigned, in writing, with a name recorded somewhere other than a meeting. The apps that rot quietly are the ones where the builder changed roles and the app kept running correctly until a business process shifted underneath it. Nobody edited the code. The organisation moved and the app did not.
Before the build, name the team that takes the support call, the person who approves changes, and the second person who can read the orchestration when the first is on leave. If no team will claim it, you have your architecture answer already. An app nobody will own inside Workday will not find an owner outside it either.
The test to run on the proposal in front of you
Take the proposal and strike out every requirement that is about Workday data governed by Workday security. Read what survives. If very little is left, build in Extend and take the inheritance gladly. If most of the requirement is still standing, the work belongs outside the tenant.
Then sort the decision into what you can reverse and what you cannot. Moving an Extend app's presentation layer somewhere else later is tedious but doable, because the data never left Workday. Standing up a parallel worker store outside the tenant is not reversible in any practical sense, and neither is a set of external integrations that have started writing to worker records through a path nobody wrote down. Keeping the data inside Workday holds your options open for years. Copying it out closes them inside a quarter.
The question that gets skipped is the one about money and pagers. Ask the sponsor who pays for the regression pass in March and September, and who takes the call when the vendor API behind the page is down. If neither answer exists, the proposal is not ready no matter how clean the architecture looks. Write both into a small integration contract and get the sponsor to sign it before the first build.
