An Extend app already has a door into HCM before anyone asks

In the reviews I run, the first Workday Extend app on a tenant is rarely the one governance saw first. Someone in HR shared services or a center of excellence gets a builder profile, sees how directly Extend reaches into Worker, Position, and Compensation objects, and has a working prototype running against real tenant data before a security conversation happens. That speed is the entire point of the platform. It is also why the first app deserves scrutiny before it ships, not after it is already the thing three teams depend on.

An Extend app is not a spreadsheet macro sitting outside the system, and it is not an integration a middleware team can throttle from a control room. It runs inside the tenant, reads and writes through Workday objects and orchestrations, and inherits whatever the account behind it can already see. Three questions decide whether that reach is safe: which data the app can reach, who tested it against data that behaves like payroll, and who owns it once the person who built it moves on. None of the three take long to answer, and all three get skipped on a tight deadline.

Which Workday objects the app can actually reach

Every Extend app runs under a security context, usually an integration system user or a security group set up for the app, and that context decides which domains it can query and update. The gap I see most often is reuse. A team building a small app to show managers which direct reports have certifications expiring soon reaches for a security group or an integration system user that already exists, because provisioning a narrow one takes an extra ticket. The app only needed a handful of fields. The account behind it could read compensation history and personal data for the entire population.

That gap does not show up in a demo. It shows up months later, usually during an audit or an unrelated security incident review, when someone asks why an app nobody remembers approving can read fields nobody scoped it for. The fix costs almost nothing at the start. Name the objects and domains the app touches, write them down, and route the access decision through the same review a security role change already gets on your tenant. If that review does not exist for security roles either, Workday Extend is not the place to build one from scratch, and neither is governance in general.

Who tests the app against data that behaves like payroll

A UI bug gets caught in a UI. A data bug in an Extend app usually gets caught downstream, in a payroll run or a benefits feed, by someone who has no idea an app is even involved. I reviewed an open enrollment reminder app that had been built and tested entirely against a sandbox that had not been refreshed in months, so every test worker had a single clean assignment and no history worth mentioning. The first week it ran against production it hit workers with retroactive transfers and multiple assignments, sent reminders carrying the wrong coverage effective date, and the first anyone heard about it was a payroll analyst asking why several deduction amounts looked wrong.

None of that traced back to a coding mistake. It was a testing gap. Extend apps that touch HCM data need to run against a tenant refresh that still has terminated workers, retroactive changes, and messy assignment histories in it, not ten tidy records built for a demo. Whoever validates a payroll cutover already knows what that kind of data looks like, and the same person or the same checklist should sign off before an Extend app touching the same data goes anywhere near production.

The app is one motivated builder's project until it isn't

Extend rewards a single person who understands both the business problem and the platform. That is also its weak point. A scheduling coordinator I reviewed had built a shift swap approval app for a call center almost alone, including the orchestration logic that routed approvals by team. When she moved into a different role six months later, nobody else knew how the routing worked, and when the org chart changed, the app kept sending approvals to a supervisor who had already left the team. Nobody had touched the code. The business had simply moved around it.

That failure mode is not specific to Workday. Power Platform teams hit the same wall, which is why governance that keeps low-code moving starts by naming an owner and a second person before the first screen exists rather than after the first outage. An Extend app needs the same two names, plus a note on where the credentials and the orchestration documentation live, because ownership with no name attached to it is the pattern behind most automation that quietly stops working and nobody notices for weeks.

A short intake form before the first sandbox build

None of this needs a governance board. It needs ten minutes with the builder before the first sandbox build starts, and a place to write the answers down where the next person can find them. I ask five questions on every Extend app I review, and I ask them once, before build, when the answers still cost nothing to change.

  • Name every Workday object and domain the app reads or writes, and record whether the access comes from a security group scoped to this app or from an existing integration system user.
  • Name who reviews that access, and route it through the same approval a security role change already gets rather than a separate low-code exception.
  • Name the tenant refresh the app will be tested against before go live, and confirm it carries terminated workers, retroactive transactions, and multiple assignments, not a handful of clean records.
  • Name the app's owner and a second person who can read the orchestration logic, both current employees, and record where the credentials and documentation live.
  • Name what breaks downstream if the app gets it wrong, such as a payroll run or a benefits feed, and who gets paged when it does.

A ten minute conversation beats a form nobody reads

Every few reviews someone proposes a heavier process instead, a review board, a twenty field intake form, a monthly meeting every Extend build has to wait for. I understand the instinct. The problem is what actually happens next. Builders keep working in a sandbox until the app is too useful to say no to, and the board ends up approving something it can no longer stop rather than shaping something it could have scoped early.

What works instead is small and fast enough that nobody routes around it. Five questions, ten minutes, written down before the first sandbox build starts. The next time someone on your team mentions they are prototyping something in Extend, ask them the five questions before you ask how the demo went.