Best practice for HRSD governance

[Eric159753]

First time doing a full HRSD implementation for a client, and having a hard time understanding the best way to allow the HR Admins ability to create, administer, and maintain all the HR Services, templates, groups, record producers, flows, etc. for the application.

Should the creation of HR Services, record producers, etc. happen in a prod instance? If the user has the HR Admin role?

Or should the entire process be the standard dev > test > uat > prod pipeline?

What has your experience been in terms of best practice?

[Sandeep Rajput · Accepted solution]

@Eric159753 I have been working on the HR Service Delivery apps since last three and half years and based on my experience I can vouch for standard dev>test/UAT > Prod pipeline approach.

A lot can go wrong while creating the HR Services/Record producer/ user criteria/ Assignment rules in production directly and you do not want to end up frustrating your end users or end up having some unwanted HR Cases generated by your end users just because your Admin messed up with HR Criteria while configuring an HR Service in production.

I will explain this using an example here, imagine a user from Brazil creating an HR Benefits case with an HR Service only meant for German employees, your HR support will have a hard time explaining to your Brazilian user as to why that HR benefit is exclusive for the German employees, and this issue occurred because your HR Admin incorrectly chose HR Criteria meant for Brazil on an HR Service meant for Germany. Such issues can be caught early if you choose the standard dev>>Test>>UAT>>Prod approach.

Hope this helps.

[Eric159753]

Thank you for verifying that I was thinking along the same lines.