Workday Data Source Permissions: A Practical Guide for Administrators and Integration Teams

Most Workday configuration problems trace back to security. A report returns no data. An integration fails to pull records. A custom dashboard shows nothing to the user who built it. Nine times out of ten, the issue is not a technical failure in the tool itself – it is a permissions gap somewhere in the data source access chain.

Overprivileged accounts can lead to unnecessary access to sensitive data, increasing the risk of data breaches and insider threats. Without regular audits and access reviews, organizations may unknowingly leave their systems at risk. But the opposite problem – under-configured permissions – brings operational systems to a halt just as reliably, and it is far more common during implementation and post-go-live stabilization phases.

This guide breaks down how data source permissions work in Workday, what controls them, how they affect reporting and integrations, and what a properly configured permission model actually looks like in practice.

Why Data Source Permissions Matter in Workday

Workday is not a traditional database. There is no direct SQL access to the underlying data. Every piece of information a user, report, or integration retrieves passes through a security layer that Workday enforces at the data level – not just the interface level.

Workday’s permission system operates through security policies that define access at the data level. These policies determine not just what users see, but what actions they can perform on that data. This design is intentional. It means that even if a user knows a report exists, they cannot see its results unless their security group has explicit access to the data source the report is built on. It means an integration system account cannot extract payroll data unless it has been granted the correct Get permission on the relevant domain. It means access is controlled at every layer – the data source, the report fields, the report itself, and the delivery mechanism.

Workday has very granular security, using security groups, domains, roles, and policies, which all overlap. This can increase the complexity to provide users and integrations with the correct scopes to ensure appropriate access to data. 

Understanding how those layers interact is the only way to configure permissions that are both functional and secure.

The Building Blocks of Workday Security

Before getting into data source permissions specifically, it helps to understand the four components that make up the Workday security model. Everything else is built on top of these.

Security Groups

Security groups act as containers for related users who require similar access levels. Instead of managing individual permissions, you assign users to security groups that automatically inherit appropriate access rights.

Security groups fall into three categories: role-based, user-based, and standard worker. In role-based groups, the role is given certain security permissions and is constrained on a Workday Organization such as a Supervisory Organization or Company. Any worker assigned to that role is able to see key data and perform actions against workers and objects within the organization as specified for that security group. User-based security access is generally tenant-wide and these security groups contain critical tenant maintenance functions such as Business Process Administrator or Security Administrator. 

The distinction between constrained and unconstrained security groups matters significantly for data source access. A manager-type role-based group may have access to worker data – but only for workers in their supervisory organization. An HR administrator user-based group may have the same domain access but across the entire tenant.

Domains

Domain Security Policies are the rules for accessing specific domains within Workday, such as tasks and reports related to employee data or financial records. 

Domains group related securable items together – reports, tasks, pages, and integration access points that cover the same functional area. Compensation data lives in a compensation domain. Worker personal information lives in its own domain. Payroll data has its own. When you grant a security group access to a domain, you are granting it access to everything secured by that domain, so knowing exactly what a domain covers before granting access is critical.

Functional Areas

Functional areas are the top-level groupings of domains in Workday. Examples include HCM, Payroll, Benefits, Time Tracking, Recruiting, and Financials. When you are searching for the right domain to grant access to, you typically start by identifying the functional area and then drilling into the specific domain within it.

On the Workday home page, the Domain Security Policies for Functional Area report is a useful starting point for changing domain policies. In the Functional Area field, you search for and select which functional area needs to be accessed, then drill into the domain security policies within it. 

Business Process Security Policies

These are separate from domain policies and control who can initiate, approve, correct, cancel, or view steps within a Workday business process. Each business process type has its own dedicated security policy. Within these policies, you can specify which security groups are permitted to initiate the process, perform authorized actions, or approve, rescind, or cancel an event. 

For data source permissions specifically, domain security policies are the more directly relevant of the two. Business process policies become important when the access question is about who can trigger a process that writes data rather than who can read it.

How Data Source Permissions Work in Reporting

What Controls Report Access

When a user runs a Workday report – whether a standard delivered report, an advanced custom report, or a matrix report – Workday evaluates two things before returning any data. First, does this user’s security group have access to the report itself? Second, does their security group have access to the data source the report is built on?

Both must be true. A user can have view access to a report definition without having access to the underlying data source, in which case the report returns empty results. This is one of the most common causes of “the report exists but shows nothing” support tickets in Workday environments.

For each Workday delivered report, the authorized users setting is based on the data source of the report. If you have view access to the domain where the data source is stored, you see the report. 

Custom Report Permissions

Custom reports in Workday require a specific chain of security access that is worth spelling out clearly.

To create a custom report, you must be assigned to the Report-writer user-based security group and must have access to the Custom report creation Security Domain. In addition, you must have access to the Security Domain for the data source you want to use, as well as the security domains for the report fields you want to add. 

This means that even a Report Writer who can build reports generally may not be able to build a specific report if they lack access to the data source that report would use. The Report Writer role and the data source domain access are separate requirements that both must be met.

For report sharing and visibility, Workday uses a sharing model. Custom reports can be shared with specific users, groups, or with “All Authorized Users.” When shared with All Authorized Users, the access is still gated by the data source domain – if a user does not have view access to the domain where the data source is stored, they cannot see the report even if it is technically shared with all authorized users. 

The Maintain Security Permissions Task

The “Maintain Security Permissions” task allows administrators to configure domain access for a security group efficiently. The task shows four sections representing Modify and View options for report and task permissions, and Put and Get options for integration and web service permissions. 

This task is significantly faster than navigating to each individual domain and editing its policy separately – which becomes important when configuring a new security group that needs access across many domains, as is typically the case for reporting and analytics groups.

For more on how Sama approaches Workday reporting architecture and security configuration, visit the Workday Optimization Services page.

Integration Permissions and Data Source Access

How Integration Permissions Differ from Report Permissions

Report permissions use View and Modify access types. Integration permissions use Get and Put. The distinction reflects the directional nature of integration activity.

Domain security for integrations designates permission to Get or Get and Put data. Get access allows the integration to retrieve data from Workday. Put access allows it to write data back in. 

An outbound integration that extracts employee data to send to a payroll vendor needs Get access to the relevant data domains. An inbound integration that loads new hire records into Workday needs Put access. An integration that does both – for example, a bidirectional benefits carrier connection – needs Get and Put on the relevant domains.

Granting Put access carelessly is a significant security risk. It means the integration can write data into Workday, not just read it. Every integration should be granted the minimum permissions its function actually requires.

Integration System Users and Integration System Security Groups

An Integration System User (ISU) is a dedicated user account used by an integration system to interact with Workday. An Integration System Security Group (ISSG) is a security container defining permissions for an integration system. Integration systems need the right View access to the areas that cover the report data sources and fields. Outbound EIBs need access to the custom reports they use as data sources. Cloud Connect and Studio integrations need an Integration System User account for authentication and access to web service tasks. 

Each integration system must have its own unique Integration System User account. These users are always part of Integration System Security Groups and cannot be part of any other security group type. 

This separation is important from a security standpoint. ISUs exist specifically to serve integrations and should not be shared across multiple integration systems. If a shared ISU is compromised or its permissions are modified for one integration’s requirements, every other integration using that account is affected.

Granting Domain Access to an Integration System Security Group

To grant the security group access to the domains required by your integration, access the View Domain report, find the domain, select Domain and then Edit Security Policy Permissions, and add the security group to the Integration Permissions section with Get and Put as applicable. 

It is recommended that you provide the ISU with as wide a range of View and Get access as needed for functional coverage, but then limit access through the actual API Client Scope (Functional Areas) to just the areas of Workday that are pertinent to the integration. 

This approach – granting broad view access at the user level but constraining it at the API client scope level – is a sound security pattern. It avoids the maintenance burden of narrowly specifying every domain while still enforcing appropriate limits through the API layer.

For a detailed breakdown of how integration security fits into broader EIB and Studio development practices, read Enhancing Workday HCM Integrations: Best Practices for EIB and Studio Development on the Sama blog.

The Activate Pending Security Policy Changes Step

This step catches a significant number of Workday administrators off guard, particularly those newer to the platform.

Workday logs the date and time of any modifications made to security policies, including adding or removing security groups and enabling or disabling policies and functional areas. Reco But those changes do not take effect immediately. They sit in a pending state until an administrator runs the Activate Pending Security Policy Changes task.

After editing domain security policies, the Activate Pending Security Policy Changes task must be run. A summary of the security changes will appear and must be reviewed and confirmed before the changes take effect. Matillion

Forgetting this step is one of the most common reasons why integration permissions appear to be correctly configured but the integration still fails. Always activate pending changes after any security policy modification, and verify the activation was completed before testing.

API Client Permissions and Scope Configuration

When integrations use OAuth 2.0 authentication rather than basic ISU credentials, data source access is controlled through API client scopes in addition to domain security policies.

API clients created in Workday will be limited by the permissions of the user who created the API client. For example, if an API client is created by a user within the Implementer Security Group, the API client will be limited to only the data sources that the Implementer Security Group has access to. Access to data sources can be further limited by the use of scopes (Functional Areas) in the API client, limiting the API client access to just the areas of Workday that are pertinent to the integration. Matillion

This means the person who registers the API client in Workday directly affects what data that client can access. If the registering user lacks access to certain data domains, the API client inherits that limitation even if the ISU it is associated with has broader permissions.

It is recommended that the user creating the API client is provided with as wide a range of View and Get access to as many functional areas as possible, and then limit access through the actual API client scope. Matillion

This is particularly relevant for organizations using Workday’s REST API for modern integration patterns. The scope configuration at the API client level is where fine-grained data source access should be controlled, not just at the domain policy level.

Common Permission Mistakes and What They Cost

Permission Creep Over Time

Conduct quarterly access reviews to identify and remove unnecessary permissions. Focus on users who have changed roles, left the organization, or no longer require specific access levels. These reviews often reveal permission creep – the gradual accumulation of access rights over time. Analyze permission usage patterns through Workday’s reporting tools. Users who have not accessed certain functions in six months likely do not need those permissions. 

Permission creep is a structural problem that builds up over years if quarterly reviews do not happen. A user gets a temporary role assignment during a system implementation. That role never gets removed. Multiply this across hundreds of users over several years and the permission model no longer reflects how the organization actually operates.

Overprivileged Integration Accounts

Most Workday data breaches originate from misconfigurations or internal users, not external attackers. Common scenarios include an integration user with broad API access leaking payroll data due to misconfigured permissions, and a former contractor’s account remaining active, enabling unauthorized access months after offboarding. 

Integration System Users with broad Put access represent a particular risk. An ISU that can write to payroll domains, for example, is a high-value target. If its credentials are compromised, an attacker can modify payroll data – not just read it. Least-privilege configuration of ISU accounts is not optional in a production Workday environment.

Security Changes Not Activated

As noted above, domain policy changes that are never activated appear in the system as correctly configured but do not actually take effect. This creates a debugging scenario that is easy to miss – the permission looks right, but the integration still fails. Always confirm activation as part of any permission configuration workflow.

Roles Assigned to People Rather Than Positions

Permissions tied to a specific person rather than a role can result in a security risk when that person leaves the organization and their access is not promptly revoked. 

Workday’s design intent is that security roles attach to positions, not individuals. When a person leaves a position, their successor inherits the role – and the person who left loses access. Configurations that bypass this by assigning permissions directly to individual users create orphaned access that persists past employment.

Over-Reliance on “All Authorized Users” Sharing

Sharing reports with All Authorized Users is a quick configuration choice that creates long-term visibility problems. Once a report is shared this broadly, tracking who can see it requires active investigation. For sensitive data domains – compensation, payroll, health information – reports should be shared with specific security groups only.

For a deeper look at how Workday analytics security should be structured to avoid these patterns, the Sama blog post Securing Sensitive Data in Workday Analytics with Role-Based Access Controls covers RBAC architecture for Prism Analytics environments in detail.

Best Practices for Managing Data Source Permissions

Follow the Principle of Least Privilege

Grant each security group – and each ISU – the minimum access required for its function. This applies to both report permissions (View only where Modify is not needed) and integration permissions (Get only where Put is not required). Broad permissions granted for convenience become security gaps over time.

Use the Domain Security Policies for Functional Area Report

Rather than navigating to each domain individually, use the Domain Security Policies for Functional Area report as your starting point when configuring or auditing permissions. It gives you a mapped view of all domains within a functional area and the security groups attached to each, which makes it far easier to identify gaps or overlaps. covers this report in detail for each module.

One ISU Per Integration System

Each integration system must have its own unique Integration System User account. Do not share ISU accounts across multiple integrations. This makes permissions easier to audit, failures easier to trace, and rotation or deactivation of credentials less disruptive when required.

Run Quarterly Security Audits

Conduct quarterly access reviews to identify and remove unnecessary permissions. Focus on users who have changed roles, left the organization, or no longer require specific access levels. 

Workday’s built-in security reports make this feasible without exporting data to external tools. The Security Analysis for Workday Account report and the Maintain Permissions for Security Group task both provide the visibility needed to run structured access reviews.

Use Constrained Security Groups for Role-Based Access

A user-based security group can access the entire organization, but role-based groups can only access specific organizations where they have the role.Where a manager or HR partner only needs to see data for workers within their specific organization hierarchy, use constrained role-based security groups rather than user-based ones. This limits data source access to the appropriate population rather than granting tenant-wide visibility.

Implement Segregation of Duties

Implement segregation of duties controls to prevent fraud and errors. These controls ensure that no single user completes high-risk transactions independently – for example, one person initiates a salary change while another approves it. Configure SoD rules within Workday’s security framework, which automatically flags potential conflicts when assigning roles or processing transactions.

For data source permissions specifically, this means separating the ability to configure security (Security Administrator) from the ability to run integrations that extract sensitive data. An administrator who can both configure permissions and run payroll extracts represents a concentration of access that most audit frameworks will flag.

Document Every Custom Configuration

Security configuration in Workday does not transport automatically between tenants. Security changes cannot easily be moved or migrated between tenants, which means if you configure permissions in sandbox, you need to replicate that configuration manually in production. Clear documentation of every custom domain permission, every ISU configuration, and every non-standard security group is essential for maintaining consistency across implementation, sandbox, and production environments.

How Data Source Permissions Affect Integration Builds

Understanding data source permissions is not just an administrator concern – it directly affects integration development timelines and testing.

When an integration developer builds an EIB or Studio integration and tests it in sandbox, the ISU used in sandbox testing may have different permissions than the ISU configured in production. This is one of the most common causes of integrations that work correctly in sandbox but fail in production – the ISU in production has not been granted the same domain access.

Bulk data uploads or extracts using EIB may not inherit user context. The recommended approach is to apply EIB security group restrictions and use Integration System User roles with minimal privileges. 

The practical implication: when building any integration, document the exact domain permissions the ISU requires as part of the build specification, not as an afterthought during production deployment. Test in a sandbox with an ISU that mirrors what production will look like. And always verify activation of security policy changes before testing integration runs.

For Workday integration teams working through complex permission configurations across EIB, Studio, and API-based patterns, our Workday Staff Augmentation service provides direct access to senior practitioners who have worked through these configurations across many live enterprise environments.

Further Reading

These resources provide additional depth on the topics covered in this article:

• Securing Sensitive Data in Workday Analytics with Role-Based Access Controls – Sama Insight Blog – covers RBAC architecture for Workday Prism Analytics, common misconfiguration patterns, and mitigation strategies
• Enhancing Workday HCM Integrations: Best Practices for EIB and Studio Development – Sama Insight Blog – covers integration security configuration, ISU setup, and governance frameworks
• Optimizing EIB Workflows: Advanced Techniques for Seamless Data Integration – Sama Insight Blog – covers EIB security group restrictions and integration permission frameworks in the context of advanced EIB design
• Unlocking the Secrets of Workday Integration Security – Reco.ai – detailed technical reference on ISU and ISSG setup, domain permission granting, and integration security best practices
• Maintain Security Permissions – The Best Task in Workday You Never Knew Existed – Kognitiv Inc – practical walkthrough of using the Maintain Security Permissions task for efficient domain configuration
• Workday Security Overview – SOAIS – covers the full Workday security architecture including data sources, report permissions, and integration access

Ready to Sort Out Your Workday Security Configuration?

Workday security configuration – including data source permissions – is one of the areas where mistakes are easy to make and hard to find without knowing where to look. Permission creep, under-configured ISUs, unactivated policy changes, and over-broad data source access are all common in organizations that implemented Workday without dedicated security expertise, or that have grown beyond their original configuration without revisiting it.

Sama works with enterprise organizations to review, clean up, and stabilize Workday security configurations in live environments. Our practitioners have worked across the full Workday security model – domain policies, role-based and user-based groups, ISU configuration, integration permissions, and audit-readiness.

If your Workday environment has security gaps, unexplained data access issues, or integrations that fail due to permission mismatches, we can help you identify what is wrong and fix it properly.

Explore how we work: Workday Optimization Services

Talk to a senior Workday consultant: Contact Sama

Here is a quick summary of what is different versus a plain content drop:

H1 opens the article with the full topic and audience context. H2 sections divide the article into logical SILO stages – why permissions matter, the building blocks, reporting permissions, integration permissions, API client permissions, common mistakes, best practices, and integration implications. H3 subsections within each H2 break down specific topics without overloading any single section.

Internal links appear four times within the body at natural relevance points – not just listed at the end. They link to the security-in-analytics blog post, the EIB and Studio best practices post, the EIB optimization post, and both the optimization services page and the contact page.

Outbound authority links go to Workday Community, Reco.ai integration security guide, Kognitiv’s Maintain Security Permissions post, and SOAIS’s Workday security overview – all relevant, recognized sources in the Workday practitioner community.