The argument is about security and about joins
The meeting always opens as a tooling preference. HR wants reporting to stay in Workday because that is where the data lives, and the data team wants an extract because that is where everything else lives. Two questions actually decide it. Who is allowed to see whose record, and what other data has to sit next to a worker row before the answer means anything.
Answer those and the tooling falls out of them. Skip them and you get a nightly extract nobody scoped, a warehouse holding salary next to performance rating, and an access model somebody rebuilt from memory. None of this depends on which reporting or extract capabilities your contract includes, and those vary by module, so confirm what your tenant actually has before designing around any of it. The structural decision underneath does not move.
Workday already knows who may see whose record
Start with the strongest reason to keep analytics inside the tenant. Worker data sits among the most sensitive an organisation holds. Pay, performance rating, leave reasons, disciplinary notes, home address. The access model in Workday HCM works on the relationship between a person and a record, so a manager sees their own team, an HR partner sees the supervisory organisation they support, a payroll administrator sees pay for the population they run.
A report built inside that boundary inherits all of it without anyone writing a rule. The same report definition run by three people returns three different row sets, because the restriction sits on the data rather than on the report. Move a department and the answer changes on its own the day the move takes effect.
Every copy outside gives that up. Somebody has to rebuild the access model in a different technology, get it exactly right, then keep it right as people join, move, change manager and leave. That work never appears in the plan that authorised the extract. It turns up two years later as a ticket asking who can restrict a workspace nobody can explain. If your groups in the tenant are already hard to describe out loud, read what security group sprawl does to a tenant before mirroring them anywhere else.
The question you actually have needs a join
Now the other side, which is stronger than HR teams usually admit. The questions a business cares about rarely stay inside worker data. Whether overtime in the distribution centres tracks order volume. Whether the teams with the worst voluntary attrition also carry the worst customer outcomes. Whether time to hire moves the revenue a territory books. Every one of those puts a worker row next to something Workday does not hold.
A system holding one side of a join cannot answer a question spanning both. No amount of report building inside the tenant closes that gap, and pushing operational data into the HR system from the other direction is usually worse than the problem. So the extract happens. In most organisations that is the real driver, and it is a legitimate one rather than a failure of the HR system.
Scan cost is the smaller reason, and the people who own the tenant feel it during a compensation cycle or a payroll run. That one yields to design, and tuning report performance buys more than an extract does. The join is the part design cannot fix.
The copy is an obligation somebody has to carry
Once worker data lands in a shared platform, the organisation has taken on something genuine. A warehouse that can put salary beside performance rating beside demographic attributes is a serious disclosure risk, and access there is almost always coarser than at the source. A person gets a role, the role gets a schema, and the schema holds the whole population.
Aggregation stops being a nicety at that point. Set a minimum group size, enforce it in the model rather than in each report, and suppress any cell below it. The right floor depends on your population, your regulators and your works councils. Without it, an analyst who can see headcount by team, by gender and by pay band can name individuals from three filters even though no row carries a name.
Decide which fields never leave. Pay carries a different risk from cost centre. A performance rating carries a different risk from a hire date. Free text in a leave reason should almost never be copied. Most warehouse loads I have reviewed take the whole worker object because the connector made it easy, and afterwards nobody can say who asked for the salary column.
Effective dating does not survive a naive extract
HR data is time-sliced in a way most warehouse modelling is not. A worker has one job profile from one date and another from a later one, a manager who changed in April, a cost centre that changed in July. The tenant answers against the date you ask about. A flat extract of current values keeps only today.
The failure is quiet. Ask for last quarter's headcount by division and a naive model answers from today's org structure, so the twelve people who moved in the reorganisation look as though they were always where they sit now. The total comes out right and every breakdown comes out wrong. Nobody catches it, because the number looks reasonable and no one has the old structure to check against. That is how a company ends up with a metric nobody can reproduce twice.
Doing it properly means carrying the date ranges into the model and asking every question with an as-of date attached. That costs modelling effort, storage and an engineer who understands that a worker row has a start and an end. Budget it early. Retrofitting history into a warehouse that flattened it means reloading from source, and the source may no longer hold what the first extract discarded.
Sort the questions before you argue about tools
The frame that survives contact with a real programme is plain. Questions confined to worker data, needing current-state accuracy and tight access, belong in the source. Headcount for a manager's own team, an open position list, a compensation review, anything where the reader should only ever see their own population. Those answers are correct and safe in the tenant by default, and more expensive and more dangerous everywhere else.
Questions that join across domains, need long history or feed an executive view of the whole business belong in the platform, with controls that were designed rather than inherited. Attrition against customer outcomes. Labour cost against production output. Five-year trends the tenant was never sized to scan. Finance has been having the same argument for years, and where a lake meets a ledger lands in the same shape.
Most organisations need both, and the mistake is pretending one will serve. The second mistake is copying everything rather than the fields the questions require. Making analytics questions a requirement turns a vague nightly copy of the worker object into a short field list with a named owner, and that list is impossible to backfill once the pipeline runs.
Write the access rule before the first extract runs
Before any worker data is copied anywhere, get one document on paper with a named person against it. A written statement of who may see which worker fields in the destination, expressed in the terms the tenant uses, meaning by supervisory organisation, by management chain, by country, by population. Then the review. For each group in that statement, who checks it when somebody changes job, and how often.
That document decides the rest. If nobody can write it, the copy is not ready, whatever the pipeline can do. If it comes out four lines long and reads the same as the tenant, ask what the copy was for. If it runs to three pages and needs different rules per country, you have found the real cost of the programme, and the storage was never the expensive part.
Name the person who re-runs that review after the next reorganisation while you are there. A reorganisation is when the copy quietly stops matching the source, and also when nobody is looking at the warehouse, because everybody is busy in the tenant.
