Skip to Content

Creating an SAP_ALL Display Only Role

Often, after the project is completed, there’s a need to display the system and configuration in Production server for data analysis.

To achieve this, we can adopt existing SAP_ALL profile and adjust it so that user access the system in display mode only.

Many SCN posts tell you to export the role to notepad, and then change the “ACTVT” field value to “03”.

Well, this is not entirely true. You may got decent working role, but since you are not dealing with only one activity code, you can’t ensure that your role will work flawlessly across departments in your company.

Common display activity codes are 03, 04, 08, 09.

Some modules uses 27, 28, 29, 53, 54, A5, etc.

You can check table TACT to list all display-related activity.

Having said that, you won’t know either whether an ACTVT field can have value 03, 04, both, or all values except to browse the field one by one and maintain it manually.

This is a very time consuming process, but in the end you can finally have a reusable role that work across your projects.

Good news is, I have gone through this and you can download the role below.

It has been validated using table AGR_1251 and contain only display values across tons of object.

System: ECC 6.0 EhP7

two pans of pizza were harmed during making process

<Downloadfile removed by moderator!>

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

    I downloaded and when trying to upload the role its giving me a error as The file does not contain any valid data   Message no. S#389,

    please can you check and provide me correct file to download.

    downloaded file size: 184 KB (188,416 bytes)

    after extract: 2.51 MB (2,633,728 bytes)

  • Hi,

    I was able to upload the role to our system.

    Few flaws which i have found out while looking into the role are, some of the critical HR objects like P_ORGIN, P_PCLX e.t.c are maintained with "*" in authorization level which is critical.

    Just change the authorization level to "R" for all HR objects.



    • Hi Bobby,

      Nice try, but......

      Sanketh already found some issues and so did I:

      In addition to the HR objects S_ADMI_FCD and S_CTS_ADMI are alsto 'starred out', as is S_SPO_ACT, S_BTCH_JOB, S_BTCH_NAM, S_BTCH_ADM, PLOG, PLOG_CON and there I stopped searching. I am afraid I cannot qualify this as display only.

      As far as the P_ORG* objects are concerned you may want to add "M" to "R" for matchcode authorizations. For PLOG you need both DISP and LISD. Here you also see that there's a lot more to consider than TACT alone.

      The final reason I will not try to import this role into any system (I had a close look into the download instead) is that it contains 98 Z* objects and one bespoke (Z*) org field.


  • Hi Bobby,

    I was in the same situation a few weeks ago - a very painful experience.

    You can have a look at my SAP_ALL_DISPLAY role based on EHP7 for SAP ERP 6.0 with SP level SAPKB74006 for component SAP_BASIS.

    I built the role completely from scratch by adding „full authorization“ to the role excluding authorization object class AAAA (Obsolete Authorization Objects).

    I analysed every single object one by one and restricted relevant candidates to display mode. All other objects that did not offer any display functionality or those with missing field descriptions are deactivated. Additionally I deactivated all authorization object classes of industry solutions (OCLSS=IS_*), because they were not used at all in my scenario. If you are using industry solutions, you will have to go through these classes by yourself.

    My idea was to add every availabe object to the role (except OCLSS=AAAA) in order to make further maintenance much easier by comparing table TOBJ before and after an upgrade to identify the delta that needs to be added. You can now use this role as a template and enhance it with your delta.

    Please consider the following highly security related authorization implementation, which is also defined in the german long text of the role.

    EHP7 for SAP ERP 6.0 based on SAPKB74006 (SAP_BASIS):


    OCLASS=AAAA (obsolete authorization objects) is not included

    OCLASS=IS_* (industry solutions) are included but deactivated





    S_TABU_DIS: ACTVT=03; DICBERCLS=* (should be restricted)

    S_TABU_NAM: ACTVT=03; TABLE=* (should be restricted)

    S_RFC: deactivated (should be restricted in case of activation)

    S_RFCACL: deactivated (should be restricted in case of activation)

    S_PROGRAM: deactivated (should be restricted in case of activation)

    Download from Google Drive:

    I am curious about any feedback.

    Best regards,


    • Such a role can never be save....
      I just performed a short check with it. Try SALE. You are able to perform customizing with that role! (SALE->autom. workflow customizing->maint. runtime environment for instance....



      S_TCODE    RC=0  tcode=OYEA;TCD=OYEA;type=TR;name=SALE;

      S_IDOCCTRL RC=0  tcode=OYEA;ACTVT=03;EDI_TCD=OYEA;type=TR;name=SALE;

      S_TCODE    RC=0  TCD=OYEA;type=TR;name=SALE;

      S_IDOCCTRL RC=0  tcode=OYEA;ACTVT=03;EDI_TCD=OYEA;type=TR;name=SALE;

      S_IDOCCTRL RC=0  tcode=OYEA;EDI_TCD=WE46;ACTVT=03;type=TR;name=OYEA;

      S_IDOCCTRL RC=0  tcode=OYEA;EDI_TCD=WE40;ACTVT=03;type=TR;name=OYEA;

      S_IDOCCTRL RC=0  tcode=OYEA;EDI_TCD=WE56;ACTVT=03;type=TR;name=OYEA;

      S_TCODE    RC=0  tcode=SWU3;TCD=SWU3;type=TR;name=SALE;

      S_TCODE    RC=0  tcode=SWFC;TCD=SWFC;type=TR;name=SALE;

      S_TCODE    RC=0  reason=C;TCD=SWU3;type=TR;name=SALE;









      S_BTCH_ADM RC=12 tcode=SWFC;BTCADMIN=Y;type=TR;name=SWU3;

      S_BTCH_ADM RC=12 tcode=SWFC;BTCADMIN=Y;type=TR;name=SWU3;

      S_BTCH_ADM RC=12 tcode=SWFC;BTCADMIN=Y;type=TR;name=SWU3;

      S_BTCH_ADM RC=12 tcode=SWFC;BTCADMIN=Y;type=TR;name=SWU3;

      S_BTCH_ADM RC=12 tcode=SWFC;BTCADMIN=Y;type=TR;name=SWU3;



      so if you sell that role as 'Display only', you are trapped. If you are liable therefore, prepare your bankaccount for the penalties 😉

      There could be many other places, for modifications possible with that role. Therefore a display only role is not provided anymore by SAP!
      The only workaround in my opinion is to create smaller roles for each component/module, where the responsible admins perfectly know, what they are granting (they know their t-codes and if there are changes possible with that t-codes) and taking responsibility for their t-codes contained in their role(s).

      But who should take the responsibility for all existing t-codes for such a SAP_ALL-display role??? By delivering it, you take it....
      b.rgds, Bernhard

      • Hi Bernhard,

        I checked SWU3 and I am able to CHANGE system administrator for workflows.

        I completely agree that there is still a potential risk using that role due to missing authority checks in the code. Even if a valid range is defined for object S_TCODE, nobody can assure that only display activities are possible.

        It is no option to deactivate object S_TCODE, so there is only one conclusion:

        The download link is deleted to prevent potential damage at any customer using that role.

        It is a pity, that there is no chance to provide any solution for SAP_ALL_DISPLAY.

        Thanks for your feedback and best regards,


      • HI Bernhard

        from a practicality point of view a lot of places define the "sap all display role" - particularly in non-production systems.

        why can't SAP secure transactions like SALE and SWU3 to force an authority check for "non display" so customers can have confidence in building a display role (or SAP deliver a template instead of every customer wasting time and effort in attempting to build such a role")?



        • Hello Colleen,
          still I am not convinced that any user needs a sap_all (display) role. Why should for instance a basis admin who is repsonsible for transports be able to see all employees wages?
          The concept still should be to grant only, what the user really needs. Even if its a system auditor who (because of his limited knowledge) thinks he needs sap_all(display).

          Unfortunately it seems to be a fact that for such cross application requests(check all existing t-codes and adapt if necessary) the pressure must come from customers side (DSAG/ASUG for instance)....


  • From a security point of view white listing (so explicitly stating what you want) is normally regarded better than blacklisting (allow everything and then denying what you do not want). Making a Display role starting with SAP_ALL is a form of blacklisting. Better would be to start with nothing and then add the access you want to give

    There are several loopholes in setting everything to display mode:

    • there are transactions that are update, but do not check any auth. objects. If these are part of the SAP_ALL_DISPLAY role, then the user would get update access
    • How do you handle SE37/SE38/SA38, with S_DEVELOP, do you grant only 03 or also 16? If the users are allowed to start ABAP's / Function modules then they can trigger part of the code that allows update
    • Some transaction (such as F110: payment run/proposal) use different field values for display (so not 03 and 04)
    • Confidential information / Privacy sensitive information should be excluded in a general display role. It is generally not advisable to grand access to security related tables. Having access to the fields containing password related data in SAP makes it easier to construct passwords.
    • maybe the role in itself may be display only, but what will happen if the user gets an (small) business update role besides this SAP_ALL_DISPLAY role: the combination of roles suddenly makes update possible for larger area's as originally intended.

    We started the other way around: we created a display all role based on the existing reporting / display transactions in SAP (so also no transaction code ranges in S_TCODE).

    • Hi Marc,

      I absolutely agree with you and building roles should normally be performed by following best practices and SAP standard rules. But you must also consider that best practices are not always the best choice when building roles for special scenarios.

      In my scenario I had to build a role for SAP Basis people, where everything regarding Basis is populated as * (except objects defined as highly critical in that company) and everything regarding business is restricted to display. They are allowed to have these authorizations, because the company established a high priveleged user concept for the Basis team.

      In the past it was often the case that key users or application managers could not solve a problem and the Basis team had to figure it out by doing a root cause analysis. When doing the analysis you will be sometimes in the situation to execute business transactions or having a look at business data, to find out what is going on there on a technical level. This is part of their daily business and they should not be tortured by missing authorization checks. When you start building a role for this scenario you cannot know what transactions they need for solving a problem in the future, because the problems are not always the same. In the beginning we tried to build a role for them based on statistics data, but this role did not work pretty well, because so much authorizations were missing. Due to the fact that the high privilege user concept is granting display authorizations in the entire system for the Basis people as part of their job role, I decided to do it upside down by restricting SAP_ALL. This is now working much better than the first role, but I have to admit that this role is a bomb and should not be used for normal scenarios.

      I forgot to add that S_DEVELOP was restricted to display too and of course S_TCODE with full authorization was not mentioned either in my first reply, which is definitely the biggest problem of that role. All other objects are restricted to display. If you are able to define a suitable range for S_TCODE, then this role is a real display role. My intention was to provide other consultants a template for SAP_ALL_DISPLAY where they can focus on important things like the restriction of critical objects like S_TABU_* or S_PROGRAM. Checking all other objects one by one and restrict them to display is just a matter of time and concentration, but it really hurts.

      Concerning your approach, how did you know which transcations are really limited to display? As far as I know the transaction description is not always very helpful. 🙂

      Best regards and thanks for joining the discussion,


      • We have a very similar requirement where the we are providing AMS support for a client. In order for the support team to analyse an issue, it needs access to the relevant transaction codes. In order to achieve this, one of the options was to create a display role with only display access and assign this role to the Support team users.

        However, looking at the responses, a display all role seems near impossible to achieve manually. Also, I downloaded the role and tested it in a sandbox server - it did stop me from accessing the create/change roles in some Functional Areas - SD/MM/PP/FI/LE However, I was able to create a serial number in IQ01, create a background job in SM36, use SALE, perform F110.

        Is there anything that can be done to achieve a display all role.

        The only solution seems to be to go into each module and identify which transactions need display access and then create a role for that module.

        • Hi Srinivas

          Is there anything to be done? First up, don't attempt a display all. Instead, attempt a "display what's needed"

          This means treating the Support User as they should be treated: an end user with a different job to perform.

          Go through the activity of identifying business requirements and what they need in the system. As a starting point, if it's for functional only you could look at all display transactions assigned to end users and build out from there.



        • I agree with Colleen. Don't attempt a "display all".

          The display - for example of a balance sheet (or worse: the download of one) can be as damaging to a company as Create/Change activity. Also, there's data protection laws to be considered (all the more so, if you run HCM).

          Build your display-only roles along business processes (not modules). To get an idea how to go about it, take a look at the SAP* standard display roles.

  • /
    • There is a lot more than that you will have to figure out. Also customizing dependencies and even a few SU24 changes you will have to make to prepare a system for such a role where users can use all transactions in the system, even those they do not need.

      Better approach -> download from the statistics data all transactions (and other application types if needed...) and import the whole lot into a role. Then remove on mass all Tcodes which have TSTCA entries which are not display. Then maintain SU24 accurately for all the tcodes. Then remove all tcodes from the menu which have references to SU24 proposals which are not only display.

      Then you have an actually used "all" role in display mode.

      Little tip: maintain S_TABU_DIS for display and S_TABU_NAM for change access, and in this role set S_TABU_NAM to inactive. You can do this for a few other objects as well once you understand what they are controlling the access to.

      You will still have some work to do, but all the "dark horses" should be out.

      You will then still need to decide about at least 2 things:

      1) S_DEVELOP and other quasi basis display access which is actually more than display - included or not? (here best is only if they are basis or knowledgable support)

      2) What about users which should have the option to start all display capable tcodes (eg. in the Information System folders of the SAP menu) even although no one ever started the tcode before. (here best is to give them access in the QAS system)



    • If you read many of the comments above you should realise that a "display only" SAP_ALL is neither possible in general, nor a good idea. If you've found this blog and thought is is something you'd like to use in your production systems, please think again. Even in non-development systems it doesn't make much sense.


  • I have created a role and inserted SAP_ALL profile directly into the authorization screen.

    After generating the role I have downloaded it to a notepad.

    Replaced ACTVT  * with ACTVT 03 and saved.

    Uploaded the role with changes and tested successful.

    I found this as simple and an easy method. Try it !