Customers who are using business roles provisioning via access request sometimes run into data consistency issues due to incorrect data in repository table GRACUSERROLE. There are many possible reasons which can be avoided by using information provided below:
Following recommendations/information should be followed to avoid any inconsistency in repository if business role provisioning is being used.
1.) Never remove/assign roles directly in target system:Roles should be provisioned via access request only . Business role definition is available in GRC only and target system does not know about it. So if some role assignment/removal is done directly in target system then the information saved in GRC repository becomes inconsistent
2.) Never delete user account directly from backend system: User account should be deleted via access request only and if possible, delete user from all the systems together which are part of your business role rather than deleting user from individual systems. While creating access request you can select all the systems present in existing assignment and create a request to delete user from all of them. If user is deleted from individual systems then when you run repository sync job then the business role assignment of user is deleted from repository and all the roles that were assigned via business role will show as they are assigned as single roles
3.) 'Retain' provisioning action is not supported in business roles: Currently retain provisioning action is not supported for business role due to complexity involved in different scenarios
4.) Never run PFCG compression report (like PRGN_COMPRESS_TIMES) in target system:As explained in first point, if this report is executed it compresses the user assignment in backend system but repository still has old assignment data
5.) Use configuration parameter 4019 to ensure consistency in repository: This parameter has been created specifically for customers who are using business role provisioning. If this parameter is useful in maintaining consistency of repository
6.) Don't execute portal sync if portal roles are part of business role: The roles/groups which are assigned in portal don't have a validity date assigned to it. So when sync job for portal is executed, it wipes off the validity dates that are maintained in the repository corresponding to portal roles. This causes problem only if portal roles are part of business roles
SAP note 1981001 also provides information stated above and will be updated in case of any changes to above scenarios are done