Thursday 6 June 2013

Configuring Workday HCM application security

We've been spending some time recently on our implementation, on defining Workday security.  I mentioned attending security class a few months back, here is an introduction to the key concepts.

If you are used to a PeopleSoft security model, just forget everything you know, this is a totally different world.  :) 

Functional Areas - Workday security comes pre-delivered with defined functional areas such as 'Benefits', 'Staffing', 'Jobs & Positions' or 'Compensation'.  Each of these areas is further divided into 'domains' and 'business processes'.

Business Processes - Each HR process in WD is set up as a 'business process'.  So the steps and the roles that can perform each step, as well as any approvals or notifications are defined.  Examples of a business process can be large like 'Hire' or smaller like 'Passport and Visa change'.  There's more to say about buisness processes, but we'll save that for another day. 

For today, imagine a swim lane flow chart in Visio with roles assigned to certain tasks.

Domain - This one can be difficult to grasp as it's quite foreign from anything I've seen in other HR Systems.  Basically, a domain is a collection of related securable items, such as tasks and reports.  WD delivers similar items together within domains, and you cannot change which items are assigned to which domains.  There are also sub-domains in some cases, but that's for a later day too.

To give you some ideas, a Domain would be 'Set Up: Jobs & Positions' and examples of sub-Domains under that would then be:
  • Set Up Job
  • Set Up Position
Other examples of Domains would be 'Job Profile: View' or 'Job Information'.

Domain Security Policy - This is where we can do some configuration.  While we cannot change what comes delivered in a Domain, with the domain security policy we control access to it.  So we control who can 'View and Modify' or 'View Only' or 'Get and Put'.

Within this security policy we address 'Securable Actions' and 'Securable Reporting Items'.  So for the Task 'Create Job Profile' or 'Delete Job Family', we say that it is a 'Modify' task rather than 'View' task. 

For individual fields that fall under this area, we can then define if those are viewable or not too.

So let's work with an example so far:
  • In the Functional area of 'Jobs & Positions' we have a Domain called 'Set Up: Jobs & Positions'.
  • We have Business Processes such as 'Edit Position' or 'Create Position'.
  • We apply a Domain Security Policy to 'Set Up: Jobs & Positions' so that various tasks are given either view or modify rights.
We then attach the above to a 'Security Group' via configuration tasks, and this is how a user is able to view tasks, perform function, etc.

I realize the above is quite a complex topic--you can see why this can be a full training course from Workday!  Let's talk some more about the User piece on a different day...

4 comments:

  1. Hello

    I know you updated on 2013 but when i faced some problems related to Domain Security Policy,i found your blog. It helps me a lot.After read this document,i clear my all doubts.

    Thanks to help us..

    ReplyDelete
  2. very good info and packaged nicely

    ReplyDelete
  3. Thank you, thank YOU for speaking in Peoplesoft language to help me understand domains

    ReplyDelete
  4. Great Explanations , thank you

    ReplyDelete