Maintain Security Permissions – The Best Task in Workday You Never Knew Existed

One of the areas in Workday that can really take time and patience is security configuration. As someone who has done more than my fair share of Workday security over the past 6 years, I have seen time and again clients and consultants alike struggle to configure, test, and migrate security configuration to production properly. There are tons of domains, most of which contain tens if not hundreds of other tasks, reports, and data sources. People struggle with where to start, how to know what domain does what, as well as what else giving them “X” also grants them access to.

As an implementer there are several tasks which can assist you in your security struggle. Unfortunately, these wonderful tasks happen not to be available if you are a client. As I mentioned in my previous post “Security for Securable Item: The Best Report in Workday” the task to “toggle”, which automatically activates security changes, is one of these tasks, iLoad’s are another, and up until Workday 28, the “Maintain Security Permissions” task was also a hidden gem, only for those fortunate souls lucky enough to have impl access.

Why is this such a big deal? Why did Workday hide this task from clients?

Let’s review what this task is and why we would use it to get some of those answers.

I learned quickly that it can be incredibly time consuming to go to each domain, one after another, to configure a security group the way you need it. Add a domain, activate, test…take away that domain, add the new domain, activate, test. Rinse and repeat this process about 100 times before you get what you want. Then you try and move this new configuration to production after testing in implementation or Sandbox and come to find out, you can’t really “move” or “solution” this. (Word on the street is OX “Object Transporter” will do this one day, but not yet!).

For that matter you can’t even iLoad this, or I should say, you don’t want to iLoad this. (You don’t want to do this because to load this data, you must load the BP policies as well as Domain Policies, and NOT the actual security groups themselves. The iLoad for security groups creates them, but does NOT add them to the domains/BP policies. That is done with the actual domain/BP policy load files. This means if you do load, you will need to reload ALL the security groups back to the domain/BP policy the way they are in the source tenant where you tested, and you might override changes made since that tenant was refreshed. Oh NO!!!)

This is where our lovely “Maintain Security Permissions” task comes in clutch!

Go to your source tenant, and then to the security group you wish to move, related action > Security Group > Maintain Security Permissions. You will be taken to a page in Workday with 4 drop-down windows. The first 2 windows represent both the Modify, and then View options respectively for the domains. The second 2 represent the Put and Get actions needed for Integration/Web Service permissions. If you navigate to this page in your source, and then your target tenant (Preferably in another monitor), you can copy the domains over, all in one page, rather than going domain after domain. What is quite a simple page and task, has just saved what in some cases can amount to hours of time.

Another great use case for the “Maintain Security Permissions” task would be the need for a “view all” type of security group. I have seen numerous times over the years the need to give a certain security group view access to all, or at least most of Workday. These might be reporting and analytic employees or maybe auditors who simply need to report on all things in Workday, but shouldn’t be able to change or configure anything. The task “Maintain Security Permissions” can be used very quickly to do this. Go to the related action of the security group > Security Group > Maintain Security Permissions, and in the View section for Report/Task Permissions segment go into the All folder, click the first domain, then on your keyboard hit Control + A, then Enter. This will select all domains and add to the view sections of that domain policy.

If there are certain areas of Workday you know you don’t want this group to have access to, that’s fine, you have your starting point now. Maybe they shouldn’t see compensation? Search for the word “compensation” in the View section you just added everything to. Start un-selecting those items, you can do this one at a time, or the same select all option. I would recommend scrolling through, at least at first. One of the other benefits of this task is the fact once you scroll through all the domains in one place, and if you use this task enough, you start to learn and remember what domains do what, and slowly and surely the guessing stops, and you start knowing what to add or remove when security changes are needed.

Maybe there is a domain you know exists but is not there when you search for it? This is due to the fact the domain is inheriting from the parent domain. Workday wants you to add this group the parent domain, and not the child which is inheriting the permissions from above. If you need to break this inheritance, you must go to the domain itself. You WILL see disabled domains, and domains in inactive functional areas.

Another thing you might notice that is interesting. If you use this task, and then look at the domain itself, you will see that Workday has added a new row to the policy, and has not added your security group to an existing row. This is due to the fact it would be hard for Workday to know what is what since over time domains can get messy, and rather than fiddle with your configuration it is safer to simply add a new row. You might have seen some domains in your tenants that have row after row with only one security group listed. There is a better than average chance those got added when an implementer was doing security configuration using this task.

Some of you out there might be asking the obvious question at this point. Where do I add, or remove the Business Process Policy permissions? Well…unfortunately you don’t add them anywhere. This still needs to be done one policy at a time. Something tells me Workday is working on solving this issue and adding this task to Workday eventually as people like me have been asking for it for some time! (In all fairness to Workday, this is a much harder thing to solve for since BP policies are not consistent like domains, and don’t have the same sections and actions across all policies.)

My last point will be about why Workday didn’t allow clients to see this for so long. It’s dangerous. You can literally remove all access from a security group in a few clicks. Likewise, you can add access to everything in Workday with some simple key strokes. Be careful, and never, ever, do things in Production without testing them in Sandbox or an Implementation tenant first, preferably with another set of eyes testing and double checking along the way as well. No matter how good you are, mistakes can still happen!

Like everything in Workday, it’s not going to come overnight, but the more you use these tools the better you will get. Take your time, test, test again, and enjoy!