14.4 Report Security, Sharing & Ownership
Key Takeaways
- Design reports with the runner's security in mind: sharing grants the ability to run a report, but Domain Security Policy access still filters which rows and fields each runner sees.
- Configure sharing options (specific users, security groups, or broader share patterns) to define who can run or access the report definition path—not who bypasses data security.
- Transfer Ownership reassigns who can edit, share, or delete the custom report; use it when authors leave or responsibilities move.
- Least privilege applies to reporting: share to the smallest appropriate audience and avoid assuming unconstrained visibility because a report is "shared."
- Task T64 ties Report Writer to Configurable Security—report design without security design is incomplete on Workday Pro HCM Core.
14.4 Report Security, Sharing & Ownership
Quick Summary: Share a custom report so the right people can run it. Design columns and filters knowing each runner still sees only data their security groups and Domain Security Policies allow. Transfer Ownership when the maintainer must change. Sharing never means "show all rows to everyone."
Task T64 is where Report Writer meets Configurable Security. Many wrong answers on practice items assume shared reports inherit the author's access or bypass domains. They do not.
Design Reports Considering Users' Security Access
When you build or copy a report for an audience, you are not only choosing columns—you are choosing a data experience for people with different security scopes.
The dual gate model
| Gate | Question it answers | Configured where |
|---|---|---|
| Report share / run access | May this person open and run this report definition? | Report sharing options |
| Data security | Which instances and secured fields may this person see in the results? | Security groups + Domain Security Policies (and related constraints) |
Both gates must pass. A user who can run a report but lacks domain View on compensation fields will not see those values (columns may be blank, hidden, or rows constrained depending on how security applies). A user with broad data access who was never shared the report may not find or run that custom definition.
Can run report? -- Share Report / report access
|
v
What data appears? -- Runner's own security (groups + domain policies + org constraints)
Golden rule for the exam: When User A shares a Custom Report with User B, User B's own security filters visible rows and fields. Not User A's security. Shared reports do not show all data regardless of the runner. Output type (Excel/PDF) does not determine data visibility.
Configuration scenario: An HRIS admin (broad access) builds Enterprise Worker Detail including compensation grade. She shares it with all Managers. Managers can run the report for their teams but only see workers and fields their constrained Manager security allows—not the entire enterprise population the admin sees. If compensation domains exclude Manager View, grade columns do not become visible just because the admin shared the report.
Design implications (T64 "design considering security")
- Audience analysis: Who runs this—HR Partners, Managers, executives, integrations?
- Column sensitivity: Do not put highly sensitive fields on a report shared broadly if most runners lack (and should lack) that domain access—or expect blank/hidden results and support tickets.
- Filters vs security: Filters express business intent (Active = Yes); security expresses authorization. Do not rely on filters alone as a security control for confidential data.
- Constrained roles: Role-based constrained groups (Manager, HR Partner) naturally scope rows; unconstrained or admin groups see wider populations—design demos and tests accordingly.
- Integration runners: RaaS callers use Integration System Users with domain Get—share/enable thoughtfully and grant least-privilege Get, not human admin rights.
| Design question | Secure choice |
|---|---|
| Who needs this operationally? | Share to that security group, not "everyone" by default |
| Does it include comp/PII-sensitive fields? | Limit audience; confirm domain View for that audience |
| Will Managers run it? | Test as constrained Manager, not only as admin |
| Is it for middleware? | RaaS + ISSG Get; avoid sharing sensitive UI reports publicly |
Sharing Options (Who Can Run)
Share Report (sharing configuration on the custom report) is where you set who can run/view the report definition in practical exam language. Sharing options commonly include patterns such as:
| Sharing pattern | Typical use |
|---|---|
| Specific users | Small pilot or named analysts |
| Security groups | Scalable operational access (HR Partners, Finance Partners) |
| Broader / many users patterns | Only when the report is truly general and low sensitivity |
Exact UI labels can vary by report type and tenant configuration; the exam cares about the concept: sharing controls report run access, and runners still need domain access to underlying data.
Where you set who can RUN the report
Exam-style question: "On a Custom Report, where do you set who can RUN the report?" → Share Report (and the runner still needs underlying domain access). Not Report Tags, not Output Type, not definition comments alone.
| Control | Does it set who can run? |
|---|---|
| Share Report | Yes (primary answer) |
| Report Tags | Organize/find—not the main run ACL |
| Output Type | Format of results |
| Comments | Documentation |
| Domain Security Policy | Data access when running—not the same as share membership |
Exam trap: "Sharing alone grants data access." → False. Sharing without domain permission still fails data visibility. "Domain permission alone always lists every custom report in Search for everyone." → Not the full story; run access and discovery still involve how the report is shared and secured as a report object.
Configuration scenario: Northwind shares Store Roster with the constrained Manager role-based security group and Regional Headcount with HR Partner. Both reports might use similar columns, but audiences differ. Tags help managers find rosters; tags do not replace sharing.
Ownership and Transfer Ownership
Every custom report has an owner—the user (or accountable principal) who can edit, share, and delete the report as part of normal ownership rights (admins with elevated report permissions may also intervene depending on tenant security design).
What Transfer Ownership does
Transfer Ownership reassigns the report's owner to a designated user. The new owner can edit, share, or delete the report. This is the standard response when:
- An HRIS report author leaves the company.
- Reporting responsibilities move between teams.
- A personal "sandbox" report must become a team-owned operational asset.
| Statement | Verdict |
|---|---|
| Transfer ownership permanently deletes the report | False |
| Transfer makes the report read-only for everyone | False |
| Transfer copies the report to another tenant | False (within-tenant reassignment) |
| New owner can edit/share/delete; prior owner may retain access depending on configuration/share | True (ownership moves; access details follow share/security) |
Who can transfer: Typically the current owner or an administrator with the appropriate permission—not a random shared runner with run-only access.
Configuration scenario: When Maya leaves Contoso, her colleague Raj receives Transfer Ownership on fifteen custom HCM reports. Raj renames a few to the team naming standard, adjusts sharing from Maya's personal test users to security groups, and keeps RaaS endpoints stable for integrations that depend on those definitions.
Ownership vs Sharing vs Data Security
Keep the three concepts separate under exam timing:
| Concept | Primary question |
|---|---|
| Ownership | Who maintains the definition (edit/share/delete/transfer)? |
| Sharing | Who is allowed to run/access the report as a report? |
| Domain / group security | What data appears when they run it? |
Owner --maintains--> Report Definition
|
Sharing --allows run by--> Users / Security Groups
|
Runtime --applies--> Each runner's domain and org security
End-to-End Security Design Scenario
Scenario. Compensation wants a report of workers with grade and base pay for annual review, runnable by Compensation Partners only, maintained by HRIS.
- Build/copy report with required columns on an appropriate data source.
- Filter to active employees; prompt by Supervisory Organization or Company as needed.
- Share only with the Compensation Partner security group (not all Managers).
- Confirm Compensation Partner groups have domain View on the compensation data domains involved.
- Test as a constrained Compensation Partner and as a Manager (Manager should not run—or should not see pay if somehow run access were wrong).
- Set ownership to the HRIS service account or lead so transfers are clean; document the owner in the team runbook.
- If an external planning tool needs the file, either schedule delivery (T65) or enable RaaS with an ISU that has Get—still least privilege.
If step 4 fails, partners run the report but pay columns are empty: that is domain security, not a broken sort.
Common Exam Traps
| Trap statement | Correction |
|---|---|
| Shared reports use the sharer's security for the runner | Runner's security applies |
| Sharing bypasses domain security | Never |
| Output type controls which data is visible | Format only |
| Transfer ownership deletes the report | Reassigns owner |
| Report Tags set who can run | Share Report does |
| RaaS needs no Get | ISU still needs domain Get |
| Filters alone are enough for confidential pay data | Authorization is domain/group security |
Connection Back to Security Chapter
Configurable Security taught Functional Areas, Domains, BP policies, and groups. Report Writer reuses that model:
- Domains secure reportable data and many report/task items.
- Security groups (user-based, role-based constrained/unconstrained, Workday-Assigned, ISSG) determine membership.
- Activation of policy edits still matters when you change domain policies to support a new report audience—not when you only share an existing report under already-live policies.
Study Checklist for T64
- State the dual gate: share to run + domain/group security to see data.
- Answer "who sees what when A shares with B?" with B's security.
- Name Share Report as the place you set who can run.
- Describe Transfer Ownership as reassignment of edit/share/delete ownership—not delete, not cross-tenant copy.
- Design least-privilege sharing for sensitive HCM columns.
- Test as the real audience role, especially constrained roles.
Report Writer Fundamentals (T57–T64) now form a complete loop: copy or create → choose data source and fields → sort, filter, prompt → share and own securely. Advanced Reporting (T65–T69) adds scheduling, Matrix, Discovery Boards, calculated fields, and deeper performance—but every advanced feature still sits on this foundation.
When User A shares a Custom Report with User B, what determines which rows and fields User B sees when running the report?
On a Custom Report, where do you primarily set who can RUN the report?
What happens when you Transfer Ownership of a Custom Report?
An administrator builds a worker report that includes base pay and shares it with all Managers. Managers report that many pay values are missing even though the admin sees them. What is the best explanation?