When I started in the Workday Eco-system back in 2011 as a data conversion consultant at Meteorix, we would often talk about how to handle the security responsibilities on our go-lives. 99% of the time the security configuration gets assigned to the HCM lead, but many times this person is not what one would call a “Security Guru”, and often not even close. We talked about how it would be smart to one day have a “Security Lead” for our projects so that more complicated security groups could be leveraged for our clients, solving problems the default security groups do not: Intersection, Segment, and Unconstrained Roles for example.
As luck would have it (if you can call it that!), this security lead ended up being me, going on to become a Workday Product Lead for Security, and working on hundreds of Workday clients’ security configurations.
The beginning of my security journey started when turnover and resource juggling landed me as the HCM and Comp lead for a project already underway out of Toronto. This client was going to require Intersection Security to ensure HR workers could not see other HR workers’ sensitive data. No one at Meteorix at the time had set this up before. It was time to learn, test, play, and figure out how to make this work, and more importantly, how to make this scalable over time.
Where do I start? Who do I ask? How do I test?
These questions swirled around in my head for days. Yes, we had some very good consultants at Meteorix, and they were all willing to help, but as many reading this know, back in 2012 the Eco-System wasn’t what it is today. Most of the new or advanced concepts were foreign to everyone, and we were all learning. There was no concept of Product Leads, Field Readiness, and Community was still ramping up its content.
One day, however, I stumbled upon what would become the most important report I ever ran in Workday, and that holds true to this day: “View Security for Securable Item”.
The concept of this report is simple, you have one prompt, and enter any data source, report, task, worklet, (really anything), and the report will produce the domain(s), or BP Policy(s) which secure it. The simplicity of it can make it very anti-climactic, but the fact is, it works. I have taught myself many things just using this one report. Not only can it help you troubleshoot security issues, it can teach you about anything in Workday.
What do I mean by that?
Let’s use an example that I just saw 2 weeks ago: A client of mine was configuring the I-9 and E-verify portions of the Onboarding Business Process. As part of this process, the HR team must go into Workday to complete Section 2, confirming they reviewed Section 1 previously completed by the worker. In this step the HR member must check a box to confirm or “Agree” that the I-9 has been filled out correctly, and their personal name, title, company, and address information must all be filed out before moving to the next step. Workday has the ability to default, and pre-fill these sections based on the worker who is filling in Section 2 from their inbox. However, the address information will only default if the company has an address assigned in Workday. If not, the employee must fill this out on their own.
Needless to say, when we tested this for the first time the address was not defaulting. Ok, no big deal, let’s just add the address and move on. Well, there is a problem: the task to edit, or add contact information to the company isn’t there. Why? Where is it, and how do I get it added?
Let’s use our favorite Workday report to find out!
Search for “Sec Sec Item” and find the “View Security for Securable Item” report. When using this report the great part is you can search very broad, or narrow depending on if you really know what you are looking for. For this, let’s just say we know the task is “Edit Company Contact Information” because we have seen that task before, but it’s just not showing in this client’s tenant.
It’s important to know we have ALL User Based Security, maybe even impl access, and thus we know it’s not because we can’t see it via access, because if I don’t see it, no one does.
Once you have searched for this, and you find that task, run the report. What do we see? We see that this task is actually secured in the Domain “Set Up: Company General” which happens to be in the “Common Financial Management” Functional Area. This explains why the domain is not enabled yet, seeing as this client is not using Workday Finance. Enable the domain, add whatever security group you want to have access to this task, let’s say Organization Admin, view and modify, save, activate. Now you will see the task you need, add your address information to the company, and BOOM, your I-9 starts to default the address information how you want it to.
We see this overlap with HCM, FIN, and PAY sometimes, and since the client isn’t using the FIN feature, more importantly, they aren’t yet paying for it, you will want to make sure to run this by Workday before turning it on. It will not be an issue, and they aren’t going to make you buy FIN to use this feature in Onboarding, but better to notify them than getting an email asking why you turned on FIN : )
Another great example of seeing this report in action, which you may have already seen without knowing it, is when troubleshooting report access. We have all made a report, run it, seen what we need to see, then share it with a user, and they don’t see what we see. Happens all the time. Often this is a calculated field issue. What do we do to see where to fix this?
If you go to the report in question, in view mode, not edit, navigate to the field in question. Related action off the field (Calculated or Workday Delivered) > Security > View Security. This task runs the “Security for Securable Item” report for the field you just actioned off. This will show the domain, or domains, the field is secured in, and you can see where you would need to add the security group for the shared user, let’s say Manager. You would want to make sure its ok for that group to now have access to that domain since we all know there is an all or nothing approach to security domains, meaning there will often be other things secured in that domain which will now be visible if you give view or modify access to managers.
Lastly, one little thing about this report which is interesting. If you try to find a task that you know is there, but it’s not showing in the report, this means it’s an implementer only task. “Configure iLoad”, a task that only implementers have access to, you will not see, even if you are an implementer. However if you are an impl, you can find those tasks by searching for the instance ID. Toggle for example, immediate security activation, which is an impl task only, would be 2998%244882.
Workday, like all things, is all about how much you use and practice it. If you harness tools like the “Security for Securable Item” report to test, play, and learn where things lie and sit in the Workday system, you will start to learn how the entire tenant is connected, and thus become a very powerful Workday user.