There are some seeded user groups and seeded user roles mapped to those user groups. If you are using the seeded user groups, the restriction on accessing objects based on user groups is explained in the OFSAA Seeded Security section.
For creating/editing/copying/removing an object in RRF framework, you should be mapped to the folder in case of public or shared folder, or you should be the owner of the folder in case of private folder. Additionally, the WRITE role should be mapped to your user group. For more information, see Object Security in OFSAAI section.
To access the link and the Summary window, your user group should have ACCESS role mapped. You can view all objects created in Public folders, Shared folders to which you are mapped and Private folders for which you are the owner.
In the Component Selector window, you can view the RRF objects like Rule and Process created in Public or Shared folders to which you are mapped and Private folders for which you are the owner.
The Folder selector window behavior is explained in User Scope section.
For each information domain, a default security mapper can be set. Based on this mapper definition, the Hierarchy Browser window will be displayed.
In the Hierarchy Browser window, the members which are mapped to your user group are enabled and can be used. Those which are not mapped can be viewed, but you cannot use it since they are in disabled state.
If a child hierarchy is mapped and the parent is not mapped to your user group, the parent will be displayed as a disabled node.
For all AMHM hierarchies, corresponding Business Hierarchy is created implicitly. Thus you can view and use AMHM hierarchies in RRF framework, provided they are mapped to your user group.
Hierarchy member security is applied only for Source hierarchies. No security is used for Target hierarchies, Rule Condition, Run
Condition, and Process Condition.