A typical application arises when a new SAP user is requested. The data owner now checks whether the person making the request and the person to be authorized are at all authorized to do so, what data would be affected, whether an SAP user already exists to whom new roles can be assigned and old ones revoked, whether data access can be limited in time, and so on.
Once a permission concept has been created, the implementation in the system begins. On the market, there are solutions that create PFCG rolls based on Microsoft Excel in the blink of an eye. You should, however, take a few things into account. Have you defined your roles in the form of role matrices and your organisational levels (orgés) in the form of organisational sets (orgsets)? All of this is stored in Excel documents and now you want a way to simply pour this information into PFCG rolls at the push of a button, without having to create lengthy role menus or then derive large amounts of roles, depending on how many organisational sets you have defined?
Maintain table permission groups
Single sign-on (SSO): This solution is useful if you have not yet used SSO for your SAPS systems or if not all SAP systems are integrated into the SSO solution. In such cases, you must implement the Web application in a system that supports SSO logins, such as Central User Management (ZBV), SAP Identity Management (ID Management), or Active Directory (AD).
Permissions in the Permission Tree with status are only deleted if the last transaction associated with the permission has been deleted from the Role menu. Delete and recreate the profile and permissions All permissions are created anew. Previously maintained, changed or manual values will be lost and deleted. The exception here is the values that are filled by the organisation levels.
During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.
Permissions are often not restricted because there is often no information about how the object should be shaped.
In the program, the appropriate syntax is used to determine whether the user has sufficient authorization for a particular activity by comparing the field values specified in the program for the authorization object with the values contained in the authorizations of the user master record.