COE Security Policy vs HR Criteria to lock down HR Services

[jcmings]

I have a requirement to limit HR Service visibility to certain user groups. New groups entering the system should only see a handful of HR Services, rather than all of the existing ones. What is the best way to approach this?

The issue with COE Security Policies is I would likely need to create an individual policy for each HR Service, since "Applies to all HR Services" is not a viable option. Different user groups need access to different HR Services with varying consistency. 

The issue with HR Criteria on the HR Service record is this looks at the subject person and not the logged-in user. Therefore, there can be issue if the subject person is not in the same group as the initiator. 

Would you recommend creating a COE Security Policy on each individual service? This is a pain, but I could do it by scripting. Thanks in advance.

(This is not an issue for record producers since they have a Can/Can't Access ruleset.)

[Rob Sestito]

Hey @jcmings - 

I think using COE Security Policy is the way to go. I think in the long run, even though you would need to create policies for multiple COEs based on different services and/ or Groups. I think it will be much easy to control and maintain over a period of time. That way, as groups change with who joins them, the security is added to them right away. Using the criteria, like you mentioned, it does not look at the user properly.

At least with the COE Security Policy, it looks at the table as a whole along with your conditions. I would use COE Security Policies between the two options.

And once you get into deselecting the Applies to all HR Services, allowing yourself to select which service, and adding the group(s) to that policy (and adding in a condition if needed), I just think that would be far better and easier to work with overall.

Hope this helps in your decision making!

Cheers,

-Rob