Moving from PeopleSoft to Workday - security topics

Someone was asking me about moving from a PS environment, and how easily the current set up of users and security translates into Workday.  In our case, it didn't really, it was like starting over from scratch to define the security pieces.  I guess it depends though...if you're replicating your PS structures into WD and your users have the same powers as they did in PS, it might be a better fit for you.  As we are doing an HR transformation, redefining and improving our HR structures and core data is making our future system quite different than our current one.  A few things to consider:

1. You have the ability to assign HR roles to the org structure.  We have nothing like this in PS.  So in WD, if you have an org (similar to a dept in PSoft), you're able to identify who is assigned from the HR side to whatever roles that you'd like.  So person A is the HR Business Partner, person B is the HR Admin, etc.  The workflow then uses this data.  As PS doesn't have such fields, we're having to define this for conversion through outside excel spreadsheets.  Note:  this is different/additional to 'normal' security where user X is assigned the role of HR BP.

2. WD comes with defined roles.  Whether or not you use them is up to you, however, as they are pre-built, it might save you some time.  However, these roles may or may not mirror the ones in your company, or your current system.

3. WD works on the concept of domains, PS does not.  WD bundles like items into domains and 'it is what it is'.  In PS you're either working on the dept tree (pre 8.9) or with the more configurable security options, such as defining your own security sets.  We heavily utilize this feature in our PS 9.0, in particular with the location and grade fields.  When comparing to WD, however, it's an entirely different kettle of fish.  We found it to be an exercise of A) What roles do we see in the future?  Shared Service Centre rep, HR BP, etc.  Then B) What shall those roles see.  In PS you have the flexibility to add/remove pages, that doesn't exist with WD.  You either find a different domain without the item you want, or you show that item.

We were not able to map over anything from PS, but instead are doing manual mapping on spreadsheets, of users to the new roles.

How is WD security similar to PS?

• Reporting security works the same; if you can see the online pages, then you can report on the data too.
• Overall, it's a similar concept--set up roles, then assign people to them (either manual or automatic).
• Users can be view only or can modify ('put' in WD terminology) data, just like in PS.
• You can have access to create reports or only to run them, just like in PS.
• Users can have multiple roles assigned.

Tips to prepare for a PS to WD implementation?  What to ask/bring during the sales cycle:

• Query your users to get an overall picture.  How many active users are in PSOPRDEFN?  How many roles?  How many permission lists as far as population visibility goes?  In particular, if you have strict requirements, e.g. this role sees all Personal Data except for personal data tab 2 due to xyz, you'll want to have those documented.  That is where WD will struggle to fit your needs. 
• WD is pretty good as isolating certain key data elements, such as birthdate or national ID, into their own domain.  But if your company keeps certain items hidden (for us, grade is highly sensitive, even though it's a core HR data element rather than being personal data), then you'll want to highlight those in the sales cycle to get a read out from WD.
• If you've locked down your query tree, you'll want to bring that to the table, as to why it's locked down and users can only access certain tables.
• If you use security other than the dept tree, you'll want to have that documented as well.  For example, we use PS security based on grade--so certain HR people have access to employees with high grades.  We set this up in PS based on 'if emp z is in grade q, then HR role 1 has access'.  This scenario seemed to be more difficult in WD, which seems so much more focused around the org.  So I'd suggest to know your non-dept tree security, to bring that to the table too.