The week of work that disappeared over a weekend
A benefits analyst at a manufacturer spent eight working days building an Extend app in the Sandbox tenant. On the Monday she opened it to demo, the app was gone, along with the orchestrations behind it and the custom object she had shaped over two days. Nothing had failed. The tenant had been refreshed from Production over the weekend, on the schedule it had always run on, and her work had never existed in Production.
She had done nothing wrong inside the app. She had built it in a tenant that gets overwritten, without asking who overwrites it or when. That is the most common way an Extend project loses a week, and it happens before anyone has thought about versions, promotion, or who supports the app after go-live.
Building an Extend app is the short part of owning one. Everything after the build carries the cost, and most teams meet each stage for the first time at the worst moment to meet it. Deciding the sequence up front takes an afternoon.
Pick the build tenant before anyone opens the builder
Build where the work persists. In most Workday estates that means an implementation tenant that exists for the project and is not overwritten from Production automatically. Sandbox is a copy of Production, which makes it good for testing against realistic data and bad for holding the only copy of your source. Confirm which tenant types you have and how each one is refreshed, because that differs by contract.
The refresh schedule belongs to someone else. It moves for cutovers, for testing windows, and for tenant decisions taken at group level that nobody mentions to the person building a leave request app. Read the calendar, plan around it, and never assume it will hold.
Three questions before the first build. Which tenant holds the source of truth for this app. When is that tenant refreshed and who decides. Write the answers into the project notes, because whoever inherits the app in two years will not reconstruct them.
Rehearse the move between tenants
An Extend app has to travel from where it was built to where people use it, and there is a defined way to package it and bring it into another tenant. Learn that path in week one. The mechanism is usually straightforward. The surprises sit in what the package does not carry.
Security configuration, reference data the app reads, endpoint addresses and credentials that differ per tenant, notification setup. Some travels and some has to be rebuilt on the far side, and that split is the most useful thing you can write down about your own estate. You establish it by promoting into a non-production tenant and listing everything that broke.
Rehearse at least twice, with a named person running it and a written sequence to follow. The first time anyone performs these steps under pressure, they should be performing steps they have performed before. A release checklist for shared solutions transfers here with almost no changes.
Nobody can say which build is in Production
The question that arrives during an incident is always the same. What changed, and which build is running. An app that used to work has started returning nothing for a subset of workers, somebody is on a call about it, and the only honest answer is that Production holds whatever was last pushed by whoever last pushed.
Version discipline is the fix and it is unglamorous. Every promoted build carries a version identifier, and beside it sits one short record of what changed, who approved it, and the date it reached Production. Keep that record where support will look, which is the ticket system the service desk already has open rather than the project folder.
Workday retains some version information in the platform, and you should confirm what your own tenant keeps before relying on it. That history is technical. An incident needs the business history, meaning why the change was made and who agreed to it. Keep the previous build available too, because rolling back usually means promoting the last good version.
A testing obligation twice a year, forever
Workday delivers two feature releases a year to every tenant, and custom surfaces built in Extend ride that schedule with everything else. There is no staying on an older release while you catch up. Whatever a release changes about the underlying objects, the security model, or the way a custom page renders, your app meets it on the date the rest of the tenant does.
The preparation window before each release runs about five weeks in a tenant carrying the new release ahead of Production, and checking the exact dates for your own tenant each cycle is part of the job. That window is already full. Payroll, benefits and absence teams are testing their own configuration in it, which is the context the Workday release calendar lays out. Extend testing joins that queue.
Say the cost out loud to whoever approves the app. Each Extend app buys two test cycles a year, every year, until it retires, and that belongs in somebody's capacity plan. The organisations I see struggling rarely hold one large app. They hold fourteen small ones, built by people who have since moved on, none with a named maintainer. End the approval conversation with a name, which is the gap governance before the first custom app is meant to close.
The failures that stay quiet
An app that works for its builder and for nobody else is the most common go-live failure I see in Extend. The builder's account can already reach what the app reaches, so the app looks finished. The first real user opens it and gets an empty page, a permission error, or a page rendering part of the data with no sign anything is missing. Test in the target tenant with an account from the population who will use it, and confirm which security configuration travelled and which has to be rebuilt, because security group sprawl gets harder to unpick every year.
Documentation has one job, which is to survive the builder leaving. One page covers it. What the app does and who asked for it, the objects it touches, the security groups it needs, how to check it still works, and who to contact when it does not. Without that page the app's documentation is a person, and people change jobs.
Monitoring gets skipped because an Extend app has no obvious place to watch. An app that throws an error is survivable, because somebody rings the service desk. The dangerous one stops writing records and says nothing, then gets found nine months later by an auditor asking why the register has a gap. A scheduled report counting what the app created last week, sent to its owner, catches most of that. Before an app reaches Production, I want all of this in place.
- A build tenant that is not refreshed from Production while the app is being worked on.
- A full promotion rehearsed end to end by the person who will run it on the day.
- A version identifier on the build, with a note of what changed and who approved it.
- A test pass run by someone from the population the app serves, in the target tenant.
- One page naming the owner, the objects touched, and who to call when it stops.
- A scheduled check proving the app is still doing work, sent to a named person.
- An owner with the authority to switch the app off, not only to request changes.
Somebody has to be able to switch it off
Retirement is the stage nobody plans, which is why tenants accumulate apps that three people use and nobody will decommission. Name the owner at build time and give that person authority to end the app. Otherwise every app survives by default, and each survivor takes two test cycles a year from the same team.
Check usage before switching anything off, over a period long enough to catch the quarterly and annual cases. An app used twice a year for a compliance return looks dead in June. Look at what it has created across at least two full release cycles and ask the owning team directly. Then withdraw access before deleting anything and see who complains, because the complaints come from the people the usage data missed.
The data the app created outlives the app. Custom records feed reports, carry retention obligations, and sometimes hold the only evidence a process happened. Decide before decommissioning whether that data stays in the tenant, moves to your retained records, or is disposable, and take that decision from the team who would answer in an audit. Then list every Extend app in your tenant this week and write two names beside each one, the person who owns it and the person who tested it at the last feature release. Any row with a blank is the work.
