Quantcast
Channel: SCN: Message List
Viewing all articles
Browse latest Browse all 8501

Permission Role Build - RBP - Performance for SuccessFactors

$
0
0

Hi HCM Community

 

I’m hoping this space (and is the right space) are able to provide any other tips or experience for security role build for SuccessFactors.

 

I’ve come over to the cloud side and am looking at SuccessFactors Security role design having come from SAP background. I have gone through the online training (finally got my head around foundation objects, picklists, etc). I have also read on the available information for Security Role Design (configuration guide available in SF as well as Luke Marson’s fantastic summary blog)

 

Both readings have made comment that permission roles will have adverse impact on system performance if designed poorly. The main recommendation provided is to not build and provision roles that grant the same permissions. That is, don’t have a user inherit the same permissions from multiple roles (unless I misunderstood?).


Quote: "SuccessFactors can slow down with bad RBP design (e.g. getting the same permission from different roles)" (extract from Luke’s document linked above)

 

In particular I often try to build “display only” roles vs “modify roles” to make the mix and match of access easier (some of this due to SAP security build). If you have an object that has different access levels, would splitting the access levels into different roles and assigning them to the same employee/user impact performance? For example, Employee Central Effective Dated Entities > Personal Information sub category objects permissions have access levels for view change, view history, edit/insert, correct, delete). Furthering the example, you had a permission role that granted Personal Information objects with view current and view history and then you had a second permission role with the modify object? Or is it better to have one permission role with all objects?

 

 

In general, do you have any other lessons learned for permission role to ensure a robust security solution (other than the build guidelines already mentioned in the configuration documents)? These might include:

  • Number of permission roles assigned to the a user (without duplicate permissions)
  • Number of Granted User/Target Populations to a permission role
  • Complexity of Permission Group (multiple attributes)
  • Impact of using exclusion on permission group access
  • Types of objects used to define Permission Groups – are some easily evaluated before others?

 

 

In a way, it’s understanding how the “user buffer” or equivalent for SuccessFactors is build and evaluated for the user session. Knowing this might make it maintain a robust design. Regardless, I get that SuccessFactors solutions are different to SAP so am trying not to design it the way I would design SAP authorisations and roles.

 

 

 

Looking forward to hearing the different points of view based on experience

 

Regards

Colleen (an experienced beginner)


Viewing all articles
Browse latest Browse all 8501

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>