Whether you’ve been using Workday for a month or a year, there’s always a lot to learn when it comes to making the most of any kind of software. One area of Workday functionality that will require your particular attention? Security permissions.

To better explain how security works in Workday, here’s a library analogy.

How Does Workday Security Work?

For this example, think of employees as having a login that lets them borrow a book from any library branch in the network so long as Workday security grants the employee access to that book. The library network is set up to have different kinds of data (or “books”) in each region, as demonstrated in the map below.

US Library Network EPA gov

Here’s how some of your data may be stored and separated. (Note: This is a simplified example. Workday has hundreds of data domains.)

  • Region 1 – Payroll Data
  • Region 3 – Personal Contact Information and Demographics
  • Region 4 – Compensation
  • Region 9 – Job history records
  • Region 10 – Benefits data and history

If we’re talking about the average employee, one with no additional designated HR or payroll security access, they can access books about themselves but wouldn’t be able to “sign out a book” about a coworker. Some data on other workers in the company, on the other hand (such as name, job title, department, location, work phone, work email, and photo), are treated as “generally available” and don’t require special security. 

Now let’s consider a manager. A manager could access Job and Compensation (Regions 9 and 4) information on their direct or indirect reports, but NOT Payroll Data in Region 1. Why? Because this data includes information on benefits (the deductions, which are indicative of benefit elections) and payroll-specific information (such as wage garnishments). It’s not the manager’s business to know how much employees are contributing to retirement or whether they have a child-support order garnishing their wages. A manager may have access to more data than non-managerial employees, but they don’t have unlimited access.

Making Changes to Workday Security

Let’s move away from the library analogy and think about the security implications of when you need to change data in your Workday org. That’s when you need to pay special attention to the intersection of Workday Security and Business Processes. In addition to defining what actually happens in your Workday org, (such as validation, approvals, and notifications), your business processes also define who can initiate a transaction, see a change in-flight (before it’s fully approved and committed to the database), undo the changes and restore values to their previous state, and do approvals.  

However, certain kinds of data must be changed through a Task instead of a Business Process. Tasks—such as adding a new cost center—are administrative, so if someone is a member of a security group that can perform that task, the user can take that action. For example, imagine a “Cost Center Administrator.” A Cost Center Admin is usually someone in Finance who coordinates these kinds of changes with the General Ledger reference tables. As such, it’s appropriate for them to be able to securely add or edit or deactivate a cost center.

NOTE: Approvals and notifications are not configurable for tasks.

Remember that redefining how Workday-delivered security operates in your org is fine, so long as A) Management signs off on those changes, and B) your audit team can find a trail of the request, management approval of said request, testing, approval/acceptance of testing, release to production, and verification of release to production.  

Creating Segment-based Security

Another way to optimize your Workday security features is to create layers of security that work in tandem. For example, let’s say you have an employee working in Sales Ops who has no direct reports, but you’d like that person to be able to see compensation, including commissions, but only for salespeople.

One way to set that up would be to create a new custom security group, add the Sales Ops people to that group, and apply to that group a set of security rules that allows access to compensation data for employees who have a compensation plan assigned to them that allows payments of commissions. That way, you’re defining security not by domain or by management hierarchy, but by compensation plan assignment. Why is that useful?

Let’s pretend that our example employee moved from Sales to Marketing. Their former Sales coworkers no longer need access to their compensation information, and as soon as they leave the Sales Ops group in Workday—boom! That data is no longer accessible to their former peers, just like in our library analogy.

Workday Security Best Practices to Keep in Mind

Now that you have a better understanding of Workday security basics, here are a few best practices to keep in mind to help you use it effectively. Below are a few of our recommended Workday security best practices:

  • Periodically review user-based security groups to ensure folks don’t have access to sectors that they shouldn’t.
  • With the growing importance of GDPR legislation, keep an eye on your baseline security and make sure to routinely track any changes you notice.
  • There are more critical times to test your security environment than just your standard monthly tests. During implementation and testing, after adding new functionality, whenever a worker gets assigned to multiple groups (and thus, has access to multiple different security areas) or you make changes to security groups, you should always test to make sure those changes haven’t granted anyone inappropriate security access.

Properly optimizing your Workday Security configuration is critical when it comes to ensuring your data isn’t compromised or misused. If you need help with security permissions, optimization, or testing, our team of Workday experts can help. Contact us today to get started. Interested in other ways to make the most of your Workday investment? We’ve got you covered.