Skip to Content
Author's profile photo Anil Kumar Suryavansi

SAP-BW/BI Reporting Authorization

SAP-BW/BI Reporting Authorization

The purpose of the document is to provide BI Authorizations details that can help in understanding what security setup are required for SAP BI/BW reporting needs.

The Authorization Concepts are segregated to a number of different categories of users as end users, developers, production support etc… :

High level different Categories:

     – Functional Authorizations

             – Report Authorizations

             – Data Authorizations

To have further explanation to these categories:

Functional Authorization

        – Restrict a user to execute a particular tool or feature within the BW toolset. Different functional authorization will allow different levels of access to display or change data models, queries/reports, monitoring tools & administration activities. Functional roles include. Below are different examples of users who can perform different activities, so will be provided different functional roles.

· Data consumer

· Super User

· Configuration – Display

· Developer – Basic

· Developer – Advanced

· Production Support

· Production Scheduler

· Production Emergency User

        – Functional Authorizations are maintained by Roles hence maintained using PFCG

Example for Data Consumer role, a PFCG role can be created with having access to execute BW queries:

        Pic 1.jpg

Complete objects for RFC_NAME can be maintained as:


Note: If user experience any access issue for accessing any hierarchy data or any other object; the error can be checked just after the auth issue in transaction SU53.

Similar to Query consumer role, other roles are created for having different accesses for different groups as stated above.

Report Authorizations

        – The reporting authorization primarily controls Provider level of security.

        – The report authorization is generally organized by functional areas and applicable for end users or power users who are needed to restricted on specific area:

        – Different Reporting Roles can be created based on areas like

· Profitability Analysis – COPA

· Account Receivables

· Inventory

· Sales and Distribution

· Account Payable

· Purchasing

· Cost Centre Reporting

· Asset Accounting

        – Report Authorizations are maintained by Roles hence maintained using PFCG

Example of a reporting role that is created in PFCG which provide access to run BW queries that are created top on GCOPA* providers:

Pic 2.jpg

Note: In above example, info providers are created as GCOPA* naming convention and similar will require change / updates as per followed naming conventions. Here reporting components provide access to query components available with these name like 0*, G*, L*, R*, T*. If any query is created with Z* name, user will not be able to access without adding access of Z*.

Data Authorizations

        – The data authorization allows access to the actual data content held within the BW data warehouse. This is called Analysis Authorization.

        – The data authorizations allow access based of specific data selections within a specified area of reporting.

        – The data authorization includes different objects some as:

· Company Code

· Sales Organization

· Plant

· Cost Center

        – A same analysis profile can provide access for different area or different analysis profiles can be created for each area as one profile for COPA, one for AR and so on.

        – Data Authorizations profiles are generated / manually maintained by transaction RSECADMIN

        – Profiles can directly be assigned to Users or added in a Role and then Role can be assigned to Users

        – Analysis Authorization works on “All-or-Nothing” Rule with exception to display hierarchies and key figure

                        Scenario: Sufficient Authorizations

                                        Complete selection is subset of authorizations

                                        Query results will be shown

                             Pic 3.jpg

                        Scenario: Insufficient Authorizations

                                        Complete or part of selection is outside of authorizations

                                        Query results will not be shown at all

                                    Pic 4.jpg

  – Data access can be restricted by following Authorizations:

· On InfoCube Level

· On Characteristic Level

· On Characteristic Value Level

· On Key Figure Level

· On Hierarchy Node Level

        – Prerequisite to apply Data Authorization

· To apply data authorizations restrictions – Authorization Relevant check at Info Object is needed to be marked

· An authorization dimension is a characteristic or navigation attribute

· Authorization of characteristics and navigation attributes can be defined independently of one another

· Authorization Relevant query variable must be included in queries (optional for all * access)

Pic 5.JPG

        – Manual creation of data authorization is possible from Central maintenance authorizations / transaction RSECADMIN.

· In transaction RSECADMIN, under Authorization – Maintenance

· Provide Authorization name and Create

· Authorization Relevant Objects can be added with Insert option (as in right panel)

Pic 6.jpg

· Special Authorization Characteristics can be included with option as below

Pic 7.jpg

        – Special Authorization Characteristics

· In addition to generic dimensions, an authorization includes special dimensions.

o InfoProvider – 0TCAIPROV

o Validity – 0TCAVALID

o Activity – 0TCAACTVT

· These special characteristics must be included in at least one authorization for a user; otherwise the user is not authorized to execute a query.

· It’s recommended as best practice to include these special characteristics in every authorization for reasons of clarity and analysis security.

· They must not be included in queries.

        – Authorizing Characteristic Values

· To provide authorizations to users only to specific sales organizations (e.g., 1101 and 2101) can be maintained as below. Ranges and patterns are also supported in characteristics restrictions.

Pic 8.JPG

· Navigational Attributes can be assigned individually. The referencing characteristic (here: 0CUST_SALES) does not need to be authorization-relevant

Pic 9.jpg

        – Authorizing Hierarchies

· In the same way as with value authorization, authorizations are also granted on hierarchy levels

· Assume hierarchy of sales organization as (these are cities and states in India)

Pic 10.jpg

· Hierarchy level authorizations can be granted by ‘Hierarchy Authorizations’ tab under Details

Pic 11.jpg

· Access can be granted on different nodes (like here access is required for a node and its sub-nodes and on a leaf of another node). Access will be granted to Two different nodes in this case

Pic 12.jpg

· Authorizations can be provided at different levels with maintaining different values as below:

o 0 (Only the selected nodes),

o 1 (Subtree below nodes – Generally Used),

o 2 (Subtree below nodes to level (incl.)),

o 3 (Complete hierarchy),

o 4 (Subtree below nodes to (and including) level (relative))

Pic 13.jpg

· As hierarchies can be created as time dependant or version dependant, in such cases Validity Period can also be defined for hierarchies.

o 0 (Name, Version Identical, and Key Date Less Than or Equal to -Recommended)

o 1 (Name and Version Identical)

o 2 (Name Identical)

o 3 (All Hierarchies)

Pic 14.jpg

        – Assigning Individual Authorizations to users

· In RSECADMIN – Users – Individual Assignment

· Select a user ID and change the assignment

· Then insert individual authorizations to the assigned list

Pic 15.JPG

        – Assigning Authorizations to Roles

· Authorizations can be assigned to roles, which can then be assigned to users

· Authorization object S_RS_AUTH are used for the assignment of authorizations to roles

· Maintain the authorizations as values for field BIAUTH

Pic 16.JPG

There is automatic authorization generation approach available with generating authorizations via maintaining details in different DSO:

     Pic 17.JPG

Detailed level information for authorization generation is available at

Assigned Tags

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

      I feel some screen shots with proper illustration on the same would have given better understanding on the concept.

      Personal space is better place for this document.



      Author's profile photo Matthew Billingham
      Matthew Billingham

      It could do with screen shots and examples. As it stands it says nothing that's really not already been said. If it was reworked with screen shots etc. I'd be glad to approve it.

      Author's profile photo AnilKumar Suryavansi
      AnilKumar Suryavansi
      Blog Post Author

      Hi Mathew, ok thanks. I will rework on this with more illustration. Thanks.

      Author's profile photo Phani KV
      Phani KV

      Hi anil,

      fix with clear screen shots and thanks for sharing.



      Author's profile photo AnilKumar Suryavansi
      AnilKumar Suryavansi
      Blog Post Author

      Hi Phani, as I am increasing the size of screen shots, image is getting blurred 🙁 . If you click on the image, its pretty clear. Thanks.

      Author's profile photo adwait badnikar
      adwait badnikar

      Very helpful document!!!!!

      Author's profile photo Former Member
      Former Member

      Authorization is necessary in many situations. The court reporting west palm beach specialists need many authorizations for doing their job correctly. But it is normal to ask for them because a trial shouldn't have any flaws.