Skip to Content
Technical Articles
Author's profile photo Colleen Hebbert

Getting back to Standard Proposals with SU24 Authorisation Variants

How you can leverage new functionality to improve your security role build in SAP S/4HANA.


Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.




For as long as I’ve been building application security roles via transaction PFCG, this is the mantra I’ve followed when maintaining authorisations. Transaction PFCG (Role Maintenance) is integrated with Transaction SU24 (Authorisations Proposals). This integration automatically imports and removes proposals from the role authorisation data based on the items in the role menu.


With the move to SAP S/4HANA and SAP Fiori, managing authorizations effectively becomes more important than ever.   Authorizations directly affect the User Experience of your users. Get it wrong and you risk actively degrading UX adoption and reduce the benefits that your users and your organization can derive from these innovations.  For example, manually adding transaction code to role will make it unavailable to users in Fiori Launchpad.


An overview of PFCG and SU24 integration

For the most part, transaction SU24 is a build accelerator and is a is considered a best practise for role build as it:

  • Reduces access creep: when transactions are removed from the role menu, the associated authorisations proposals are also removed (so long as another menu item doesn’t require them). This benefit only works for standard and maintained authorisation status items.
  • Reduces authorisations errors: the role will automatically receive the require authorisations for each application so long as the mappings are fully maintained in transaction SU24, and the application has been added to the role menu
  • Reduces build Effort and time: the security administrators can leverage existing mappings as part of role build and requires less time to map the values out for each role.
  • Simplifies and Improves Impact Analysis: it makes is easier for role authorisations experts to easily identify why an authorisation is part of a security role. This helps with segregation of duties impact assessment, role clean-up, and regression test prioritisation.


Going back to the mantra –

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.


Why Avoid CHANGED?

We avoid CHANGE as it is a deliberate breaking of mappings and deviates from consistency. A CHANGED status object is treated like a MANUAL object. Transaction PFCG cannot automatically remove a CHANGED authorisation from the role when the transaction is removed as there is not relationship between the data. Therefore, CHANGED objects can increase access creep and make it difficult to properly impact assess or remove the access.


Why MANUAL by Exception?

We accept MANUAL by exceptions. Some authorisations are required but are not mapped to applications items that can be added to a role menu (e.g. S_RFCACL for trusted RFC). Some may be clear design decisions for supplementing an existing role to provide additional authorisation (e.g. purchasing approval codes). These exceptions are clearly documented and less likely to change.


Why strive for STANDARD?

We aim for STANDARD as it meant we had a 100% alignment with authorisation proposals. Assuming SU24 data is accurate, it is unlikely the security administrator team needs to maintain values in PFCG.



We accept and settle for MAINTAINED as a balance between mapping what we can in SU24 and avoiding CHANGED status.


Wouldn’t it be great if we didn’t have to settle for maintained? Variants makes this possible.


Common Scenario for MAINTAINED status

Maintained status occurs because we only partially maintained authorisation proposal inside SU24. This is needed when a transaction code belongs to multiple roles with differently underlying authorisations values.


For example, if we had a transaction that provided table maintenance then we would provide authorisation object S_TABU_NAM. This object contains fields Activity and Table Name. We cannot maintain the Activity proposal in SU24 if we need to grant access to users in either display or maintenance mode. However, both roles would need the same Table Name. As a result, we would partially maintain the proposal: Activity field would remain blank, and Table Name would contain the entry.


For example, transaction OB52 provides access to posting periods. Many users may need display access and only a few need to make changes. Within transaction SU24, SAP provides the ACTVT Activity field as an empty proposal which is then maintained at role level.




Within transaction PFCG, we would receive a STANDARD proposal initially that is then set to MAINTAINED once we finish populating the Activity proposals (one role gets display only whilst the other role gets change and display).


Other Scenarios for MAINTAINED status… and where it can get messy

MAINTAINED Status can also be due to:

  • SAP Proposal and Upgrades remain unchanged – the customer chooses to leave the default proposals as is and make all necessary refines at role level.
  • Cockpit Style Transactions – the application has several use cases controlled through combinations of authorisations. The SU24 default proposals remain predominately empty to provide the flexibility to maintain values at role level.
  • HR Authorisations and transaction – most HR transaction access is controlled through two (2) main objects – P_ORGIN and PLOG. The objects contain fields for activity level, infotype, and enterprise data restrictions. To avoid CHANGE and MANUAL status, these objects are added with empty proposals and all changes are managed at role level.


SAP Proposals and Upgrades

SAP provides default proposals for SAP standard transactions. These values are shipped via transaction SU22 tables and copied across to transaction SU24 tables via transaction SU25 (for greenfield systems, Step 1 is run).

The customer is allowed to make changes to the SAP proposals. Within transaction SU24, you can compare the values in your system against SAP proposals to check if you have deviated from the original.



As part of upgrades, SAP ships new values (changes to existing mappings and mappings for new transactions). The customer uses transaction SU25 Steps 2a/2b to compare customer tables and SAP tables to import changes.




However, for many customers, it becomes a challenge to decide if they should adopt SAP updates on transactions that they have already maintained. Depending on build maturity, it can be difficult to change which proposals are a better fit: SAP’s latest proposals or updates the customer made as part of build refinement.

Some security administration teams avoid making changes to SAP standard proposals. In this situation, it leads to an increased level of CHANGED and MANUAL authorisations – what we’re trying to avoid. However, it makes upgrades a bit easier for the security team to process.


Cockpit style transactions

The transaction is a single-entry point for several functional scenarios and assigned to multiple roles. In this situation, SU24 proposals have a higher incomplete rate and requires individual maintained in each role. Each role requires a different combination of fields values. This level of localisations shifts the build effort to the security administrator as part of role build.


HR Authorisations and transactions

HR authorisation objects control personnel record and organisational structure for infotype access. If you attempt to use transaction SU24 proposals, in most cases you are forced to enter an empty proposal in SU24 as each role requires different values. For example, transaction code PA30 for Maintain Personnel Record requires P_ORGIN authorisations to control activity level, data access, and Infotypes. Several users may need access to the transactions but different functional access. Therefore, P_ORGIN would need to be empty in SU24 and fully maintained in PFCG. It can make it difficult in HR-centric roles to determine why the roles has field values as you cannot determine the context by the role menu items. Often, security administrators resort to manually adding objects instead of attempting SU24 maintenance.


A use case of needing variants in SU24

Using the “cockpit style: scenario, let’s imagine you want to provide users with access to F3163 Manage Business Partner Master Data. This application allows you to access Suppler, Customer, and Employee information and is included in several business role templates. Many users will have a requirement to access the application, but they will need to be restricted to specific data.




Fiori App F3163 authorisation is based on SAP Gateway Service “MD_BUSINESSPARTNER_SRV             0001”. Within SU24, default proposals are provided but they are for maintenance access with no specific limit to business part role. This means without changing the proposal within transaction SU24, all restrictions will need to be at role level. Making changes are role level will result in MAINTAINED, CHANGED, or MANUAL status. Alternately, SU24 can be updated to remove the field proposals and leave empty values to maintain entirely at role level (end up with MAINTAINED only) but that doesn’t a consider different maintenance level (e.g. deletion access may be restricted).



Each time the application is added to a role, the administrator then must make changes. However, SU24 variants can solve this problem and allow you to continue with STANDARD proposals. Within, transaction SU24, a variant is created with the required mapping.




Transaction code PFCG now contains an Application Tab which will list the available Variants for each application maintain. This tab is populated after the role menu is refreshed and SU24 definitions have been read in. In the example below, the options are greyed out as there are no variants to choose between.




Once the variants have been selected, the SU24 proposals are then imported via the Authorisation Tab. Again, in this example there are not variants sot the SAP standard values will be adopted.



The security role administrator will need to work through each authorisation proposal to either set the unrequired authorisations to inactive, complete field proposal, or return to transaction SU24 to make proposal changes at the master data and then return to the role to continue build. However, as this application is used by several process areas (procurement, sales, HR, etc), it is unlikely SU24 proposals will be changed as it impacts all roles. Instead, the proposals will end up in a MAINTAIN or CHANGED status to maintain the required authorisation for the role. Ultimately, you start to lose the benefits of SU24 proposals, or you must remove all proposals in SU24 and maintain everything inside of PFCG.


Finally what are these variants and how to use them

Originally this capability was delivered under a “new” transaction code SU24N but has seen been merged back into transaction SU24. Refer to SAP Note: 2798443 – SU24N: New dialog environment for authorization default value maintenance


Transaction SU24 now allows you to create variants of the maintenance proposals. This means you can create multiple proposal versions and control which ones you adopt within the roles.


Within SU24 transaction you can how choose to CREATE VARIANT instead of changed SAP standard proposals for an application. When creating the variant you must enter this in the customer namespace. You can implement a naming convention (such as including Fiori Application Id which can help for context later).



As this is  workbench object, you will need to assign it to a transport (no screen shot shown). Once you have created the VARIANT you can start making changes to the proposal data without updating the standard values.




In the case of this application and the context of managing Supplier, you can now switch off authorisation proposals that are not relevant as well as changing the existing proposals for values that are more relevant to supplier master data.

Once you have completed the updates you then save (just like you would have when you made updates to the standard proposal)




Return to transaction PFCG and look and go to the Application Tab. You will now. The SU24 variants are automatically identified based on applications in the role menu.




As a variant now exists, you can choose which on you select for the role authorisation proposals. If there are several variants, you can choose as many as required for the role.




Once you have selected the applicable variant, save the role before you maintain authorisation data again. On the authorisation tab you will need to select Expert Mode for Profile Generation > Read Old/Merge with new to re-read the SU24 values and pick up the VARIANT proposals


You will still be asked to enter the organisational values (or update them if you need to).



The authorisation data will show more STANDARD (green) proposals due to the VARIANT that you maintained



When reviewing the authorisation proposal you will now see which specific variant brought them in.



As mentioned, when creating a VARIANT in SU24, the variant name is quite useful to understand the context. As shown above, the application variant name of “ZF3163_SUP_M” is a basic naming convention for the Fiori App F3163 with variant of Supplier Maintenance. These conventions can make it easier to understand the access context compared to the application Odata service name.


Impacts of Using Variants

The primary benefit of using variants is to allow you to leverage authorisation default proposals from SU24 and minimise overall maintenance of individual permission within the role. The following are benefits I can see in using variant in SU24

  • Able to easily handle different access contexts for the same application.
  • Separate development/maintenance default mappings with security roles team
  • Reduce access creep and confusion in role build through less direct maintenance of value
  • Obtain better access context through variant names to better understand reason authorisation proposal within a role
  • Easily able to add a new variant to an application for another role without having to maintained the existing roles. This can occur when you add an application in design but need to change the SU24. If you update the SU24 data, then you would need to also maintained the existing role and regression test. This further add to your change request and effort. Instead, you can define a new variant just for those values.
  • Reduce SU25 Step 2a/2b upgrade effort as you avoid maintaining SAP standard proposals. However, you will need to manually assess your variants to decide if you need to add new value proposals that were added to the SAP original
  • Flexibility to differentiate access proposals for non-production and production access. This can allow security teams to leverage SU24 for project role build for sensitive transactions that would generally be granted in display mode only.
  • Small win – your can double-click on the variant tab line items of transaction PFCG to navigate to the related transaction SU24 configuration to confirm you have selected the required variant.


Give variants a go and share your thoughts below. I’d love to know if this is something you’d consider using as part of  your build accelerator and approach to consistently building security roles.






P.S. For those of you who are new to building security roles ABAP authorisations roles via transaction PFCG, the authorisations status is summarised in the table below:


Authorisation Status Summary of build sequence that causes the Status
  1. Authorisation proposal for the transaction is wholly maintained via transaction SU24 with proposal status set to Yes. Exception: organisational field proposals are not set via SU24
  2. Application is added to the role menu in PFCG
  3. Authorisation proposal is fully imported. At most, the security administrator maintains the organisational values
  4. The security administrator makes no further changes to the authorisation
  5. Authorisations Proposal remains in a STANDARD status
  1. Authorisation proposal for the transaction is partially maintained via transaction SU24 with proposal status set to Yes. Partially means at least one authorisations field has been left empty and it is not an organisational field.
  2. Application is added to the role menu in PFCG
  3. Authorisation proposal is imported showing a STANDARD status with traffic light of YELLOW as the build is incomplete
  4. The Security Administrator must maintain the blank values.
  5. Once maintained, the Authorisations changes to a MAINTAINED status.
  1. Authorisation proposals is either partially or completely maintained in SU24
  2. Application is added to the role menu in PFCG
  3. Authorisation proposal is imported as a STANDARD status
  4. The Security Administrator overwrites a proposed value (e.g. ACTVT 01, 02, 03, 06 is changes to 01, 02, 03 to remove 06 delete)
  5. The original proposal is automatically copied and deactivated. It remains in a STANDARD status (this happens in later releases)
  6. The authorisation proposal status is now set to CHANGED as the proposed values no longer align to the source mappings in SU24.
  7. CHANGED values are treated like MANUAL.

Usually you will receive a pop-up warning you that you overwriting proposal. Pay attention to breaking organisational value inheritance as this can cause headaches later.

  1. The security administrator manually adds the authorisation in to the role.
  2. The status is set as MANUAL
  3. There is no connection to role menu items and SU24 proposals.






Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Naveen Kumar
      Naveen Kumar

      Great feature! Is this already live from a particular release?

      followup query-

      1) during upgrades, Do we have option to update  variants automatically with new object/ fields? Or they need to be manually adjusted?

      2) Will these variants available in standard SAP table? Both from proposal point of view and role content .




      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      Hi Naveen


      Refer to the SAP notes for the releases. In earlier release transaction SU24N was originally created. However, it has been deprecated and the functionality merged in to SU24. Releases are the SAP Basis 754/755 and I think 756 is where it's part of SU24.

      SAP Note: 2798443 - SU24N: New dialog environment for authorization default value maintenance


      Item 1) during upgrades - you will need to manually reconcile and review changes to mappings. I am not seeing any standard reports and the SU24 screen for variant suppresses the SAP data button (I must admit it'd be cool to see the ability to compare the variant to the SAP original)

      I did reach out to product team to ask this question as I was curious as well.

      Item 2) SAP tables - the SU24 data including variants is still stored in the usobt_c and usobx_c tables but a new table of USOBCONTAINER is added to store the mapping between the lead application (the original) and the variant. I've mocked up a table relationship so you can see. When you first create a variant SU24 will copy the values from the original to get you started. SU24%20Variant%20MappingThanks for the question - it made me want to map it out


      Whilst there is not standard functionality to automatically compare you can complete impact assessment by

      1. Identify all leading applications in table USOBCONTAINER
      2. Compare against the new SU25 data (USOBT/USOBX tables or the *_C tables if you have done step 2a and 2b)
      3. Manually review the changes in SAP original proposals and decide if you want to add them to your variants
      4. Update your variants as required







      Author's profile photo Naveen Kumar
      Naveen Kumar

      Thanks a lot for the quick response.

      This is really helpful!




      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      and further update for those looking for the PFCG menu relationship and information (i.e. quickly check what variant is in the role) - your answer is table AGR_APPL_VARS




      PFCG Application Variant Tab


      SE16 associated table (the variant at the HT hashes and link back to the SU24 to get the underlying transaction code/executable


      SE16 Table AGR_APPL_VARS showing variant selected in role


      Hoping everyone is getting a chance to try this out and adopt it into their role build practices.




      Author's profile photo George Borghouts
      George Borghouts

      Hi Colleen,

      Thanks you so much for valuable examples. Much appreciated. Just a question from an SAP GRC ruleset building perspective: If i was to create/update a function (belonging to the area of ARA RISKIDs) having a tile/transaction for which a variant exists would GRC also offer me the option to pick the values belonging to the variant?
      Or are there plans to update SAP GRC accordingly?



      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      I am trying to follow up in the background for you as this is a product enhancement for SAP Access Control.

      Author's profile photo Vincent Willems
      Vincent Willems

      Hi Colleen,

      Thank you very much for this helpful blog.

      What naming convention do you use as a good practice for the authorization default variants for Fiori-Apps? I have some doubt about which elements of the Fiori-app should be incorporated in the naming convention. We use the Fiori-app ID but is it a good practice to also add an abbreviation for the target mapping in the naming convention ? Fiori-apps exist which contain more than one target mapping, but are those target mappings related to different authorization scenario's for the Fiori-app?

      With Kind regards,

      Vincent Willems



      Author's profile photo Colleen Hebbert
      Colleen Hebbert
      Blog Post Author

      HI Vincent

      I haven't thought through to level of detail for naming convention but I understand your point. I'd be included to keep the Id simple (e.g. APP Id + Activity level (Create, Read, Update, Delete - simply)  + incremental). Then use the description field for more meaningful information that can be changed

      Have a look at the field length available (as you might incorporate target mapping if there's enough space) and then have a look at how it appears in PFCG app tab and authorisation overview to see if it makes sense to the administrator