Skip to Content

Life (profile SAP_NEW), the Universe (role SAP_NEW) and Everything (SAP_ALL)

I know, there are tons of discussions here on SCN about SAP_NEW but it still seems to be widely unknown how to use SAP_NEW correctly. Therefore I try to give a summary in this blog.

First of all let’s separate SAP_NEW from SAP_ALL

Authorization profile SAP_ALL is a composite profile containing generated authorizations for nearly everything.

SAP_ALL get’s generated automatically whenever you transport authorization objects.

You can generate SAP_ALL using report RSUSR406 or transaction SU21. This generates SAP_ALL only in the client where this report is executed. You can generate SAP_ALL using report AGR_REGENERATE_SAP_ALL. This report generates SAP_ALL in all clients.

The customizing table PRGN_CUST contain some switches to control the generation of SAP_ALL – however, the default values are quite reasonable:

ADD_ALL_CUST_OBJECTS YES (default), NO Give full authorization for customer authorization objects (namespace Y, Z) in the profile SAP_ALL
ADD_OLD_AUTH_OBJECTS NO (default), YES Give full authorization for obsolete authorization objects (class AAAA) in the profile SAP_ALL
ADD_S_RFCACL NO (default), YES Give full authorization S_RFCACL in the profile SAP_ALL (Do not activate this switch!)
SAP_ALL_GENERATION ON (default), OFF Generate SAP_ALL profile in after-import method for authorization objects (Note 439753)

Principal rule: No user – except maybe for highly secured emergency users – should be assigned to authorization profile SAP_ALL. This rule applies for all clients.


The rules of the game:

  • Forget profile SAP_NEW as it is critical and outdated
  • Inspect role SAP_NEW to optimize your active roles during upgrade preparation
  • Do not assign the profile or the role to users

The authorizations in SAP_NEW exist to bridge the differences in authorization checks between releases while you are preparing the upgrade. SAP_NEW enables your business processes to continue functioning until you have incorporated new authority checks in your old authorization concept. The authorizations within SAP_NEW are bound to software component SAP_BASIS. Only if you upgrade SAP_BASIS you need to bother with SAP_NEW.

SAP_NEW  should never be required in productive systems.

There is no need to give somebody SAP_NEW if this user already has SAP_ALL. Well, you still see this combination quite often in real system, but this is simply an indicator that the administrators didn’t got the rules of the game yet.

How to use SAP_NEW correctly

Prerequisite: The technical release upgrade was executed in an upgrade-preparation system.

  1. Using transaction SU02 remove all old single profiles from composite profile SAP_NEW up to and including the profile which matches to the upgrade-start-from release of software component SAP_BASIS.
  2. If SAP_NEW is now empty you’re already finished
  3. Assign the reduced authorization profile SAP_NEW to all users in the upgrade preparation system. Now all users can continue working as before the upgrade. (This step can be omitted if you manage missing authorizations while testing the upgrade using some other methods.)
  4. Inspect the authorizations in all remaining single profiles from composite profile SAP_NEW which have a higher release than the upgrade-start-from release of software component SAP_BASIS and identify the productively used roles which should get these authorizations.
  5. Adjust the authorizations in your productively used roles using transaction PFCG and remove the corresponding authorizations from the single profile of SAP_NEW using transaction SU02.
  6. Continue step 4. and 5. until authorization profile SAP_NEW is empty, than remove SAP_NEW from all users.
  7. Proceed with the preparation of the release upgrade using transaction SU25 and your own roles but without SAP_NEW.

Of course you can skip step 1. to 3. and start with step 4. directly!

Update since basis release 700:

Authorization profile SAP_NEW has been replaced with a generated role called SAP_NEW, too. You generate role SAP_NEW using report REGENERATE_SAP_NEW. This way, old authorization data as described in step 1. above are omitted automatically. See Note 1711620 for details.

Basically, the old authorization profile SAP_NEW and the new role SAP_NEW serve the same purpose and are based on similar data.

Authorization profile SAP_NEW is based on a list of authorization objects stored in table TOBJVOR and authorization values stored in table TOBJVORDAT.

Role SAP_NEW gets generated by report REGENERATE_SAP_NEW only using the list of authorization objects stored in table TOBJVOR but ignores the values given in TOBJVORDAT. Instead of this, full authorizations “*” are added for all authorization fields.


You must be Logged on to comment or reply to a post.
  • Hello,

      sorry but I don't understand the first step:

    1. Using transaction SU02 remove all old single profiles from composite profile SAP_NEW up to and including the profile which matches to the upgrade-start-from release of software component SAP_BASIS.

    Looking the content of profile SAP_NEW I see it's made up of folders named with the different releases. When you say "remove all old single profiles", do you mean removing the folders referred to the releases not involved in the upgrade?


    Best regards,


    • Yes, within composite profile SAP_NEW remove the items which refer to old releases (in fact these are references to single profiles), e.g. if you have upgraded from SAP_BASIS 700 to 740 than remove all old items up to and including S_NEW_7000 keeping profiles starting with S_NEW_7020.

      Kind regards


  • Two years later it's still a good blog. 🙂 Very helpful and simple explanation.

    When I was asked a while ago by a consultant to assign them SAP_NEW on top of SAP_ALL I wondered why it's needed. Didn't say anything because I'm not a security expert, so what do I know. It's more clear to me now. Thank you!

    • It used to be standard practice during a new implementation to create a "project role" by assigning SAP_NEW and SAP_ALL to it (which as we know, is redundant practice) and then removing the Basis authorizations. In fact, I think this suggestion may have been enshrined in early editions of "Authorizations Made Easy." This was probably always a bad idea, but it was pretty standard. Thus, it has been burned into many a consultant's brain that SAP_ALL + SAP_NEW = ultimate authorizations (which, in fact, is not strictly true, as S_RFCACL isn't included in SAP_ALL).