SAP CRM Authorizations: Process flow of the Authorization Check in Business Transactions

Print Friendly

In this article I will show you where you can find more information about the "authorization check" that takes place in business transactions in SAP CRM. At the same time I will try to elaborate all checks in a specific blog post in the next coming weeks, so you"ll learn all relevant customizing checks/steps that are relevant to setup such a concept. I'll also explain in details the authorization objects that are relevant for each particular check using 1 or more examples.


1. Finding the relevant information about SAP CRM Authorization check in Business Transactions

Information about the authorization check can be found in HELP.SAP.COM

But, as this check is dependant on the release you are working in, I will guide you through the steps in order to find the relevant info relevant for your specific release.

Step 1: Launch Help.sap.com


Choose the link "SAP Business Suite" as this is where SAP CRM is categorized under.

Step 2:  Choose Customer Relationship Management

customer relationship management

Step 3: Choose you relevant Release  (in this example I am choosing CRM 7.0)

Step 4: click on Application Help


Step 5: Choose your language

Step 6: search for "Authorization check in business transactions" within the application help of your Release

You will normally see an entry as below:

If you open the above link you will get to the point where you will be able to read and learn the process flow that is being used in SAP CRM to perform an authorization check in business transactions. What you should understand is the below image (which is fairly simple once you are familiar with it).

For your convenience here is the direct link to the above screenshot in HELP.SAP.COM for SAP CRM Release 7.0.

Basically, in this release  SAP does perform a check on 4 levels so to speak ,and starts with the 1st check..if positive you"ve got access to the document ..if negative it will continue with the other 3 checks untill it finds a positive authorization check. If at check 4; the authorization check was still negative your access is denied or at least the allowed activity (e.g. change) for that document might not be allowed.

What are these 4 authorization check levels in SAP CRM 7.0?

1. Access to "Your Own" Documents (CRM_ORD_OP)

What does this mean?

The system checks whether the user in the relevant transaction takes on a specific partner function for the activity executed, for example, whether he or she is the employee responsible. Furthermore, the system checks whether the user has the authorization to change, display, or delete a transaction. If the result of this check is positive, no further checks take place at transaction level.

This check is purely based on the authorization object CRM_ORD_OP . No other authorization object is being checked during this check level.

 2. Visibility in the organizational model (authorization object CRM_ORD_LP)

If the user is not authorized in the first step of the check, the second check is carried out. This check makes it possible to control the access to transactions, depending on the employee's assignment to certain organizational units via his or her position. This authorization object defines which transactions can be processed by the user in the individual organizational levels, and which activities he or she can carry out here. If the user is authorized for the chosen activity (create, change, display, delete) and the relevant organizational level, no further checks are carried out.

Once again, during this check only the authorization object CRM_ORD_LP is being checked.

3. Territory check in claims management (authorization object CRM_ORD_TE)

If the business transaction for which the system performs the authorization check belongs to a business transaction type for which the territory check has been activated, the system determines the territory of the business transaction in question. For more information about the territory of a business transaction, see Territory Determination in the Business Transaction. You activate the territory check in SAP CRM Customizing for Customer Relationship Management under >  Transactions >Basic Settings >Define Transaction Types .

The system then determines in which territories the user (for whom the authorization check is being performed) is authorized to perform the selected activity, by the CRM_ORD_TE authorization object (authorization object CRM Order - Visibility in Territory). CRM_ORD_TE can authorize a user in his or her own territories only, or both in his or her own territories and in any territories below this. If this includes the territory of the business transaction, the user is authorized for this business transaction, and the authorization check ends here. However, if the user's CRM_ORD_TE entries do not include the territory of the business transaction, or if CRM_ORD_TE does not grant the user any authorization for the selected activity, the system moves on to the next step in the authorization check

4. Combination of several authorization objects

If the preceding checks were not successful, this combination of different authorization objects is checked. All the checks must be successful before the user is authorized to process the required transaction. This means that the user receives the authorization to process only if he or she is authorized to:

  • Process the leading business transaction category in the corresponding transaction type
  • Process the corresponding transaction type
  • Process in the corresponding sales area
    1. Authorization objects CRM_ACT, CRM_OPP, CRM_SAO, CRM_SEO, CRM_CO_SE, CRM_CON_SE, CRM_LEAD, CRM_CMP, CRM_CO_SA, CRM_CO_SC, CRM_FM_FND, CRM_FM_FNP, CRM_FM_BPOUsing these authorization objects, the system checks which business transactions the user is allowed to process, and whether he or she is allowed to carry out the functions create, display, or delete in these transactions. The system checks the relevant authorization object, depending on the activity executed:
      • Activities: CRM_ACT
      • Opportunities: CRM_OPP
      • Sales transactions: CRM_SAO
      • Service transactions: CRM_SEO
      • Service contract: CRM_CO_SE
      • Service confirmation: CRM_CON_SE
      • Lead: CRM_LEAD
      • Complaints: CRM_CMP
      • Financing contract: CRM_CO_SA
      • Sales contract: CRM_CO_SC
      • Fund: CRM_FM_FND
      • Funds plan: CRM_FM_FNP
      • Budget posting: CRM_FM_BPO
    2. Authorization object CRM_ORD_PR Using this authorization object, the system defines which action the user is allowed to execute for each business transaction type.
    3. Authorization object CRM_ORD_OE Using this authorization object, the system defines in which sales area or in which service organization the user is allowed to process CRM business transactions, and which activities he or she can carry out there.

If the user is not authorized in this step of the check, he or she is not able to process the transaction in the required way. The user receives a system message that contains the corresponding authorization object, and refers to the lacking authorization.

As said, in the next weeks  I will try to elaborate if possible for each check a concrete example in separate blog posts, and point you to the customizing steps where you will find back relevant information to understand what information you need to setup a working concept.







Davy has been working as an SAP Consultant since 2000 and started working in the SAP IS-U Module , but as of 2002 he has mainly worked as functional SAP CRM consultant and SAP Authorizations consultant.
More about

28 thoughts on “SAP CRM Authorizations: Process flow of the Authorization Check in Business Transactions

Comment author said

By Janantik on 13 April 2013 at 23:17

Hi Davy, I'm looking for some advise. We have a requirement wherein we need to restrict access of Users based on their position in the CRM Org. Model. A user should be able to perform a business transaction based on the Org. Unit (Sales Org., Sales Office, Sales group) he/she is assigned to. The user should not be able to modify (Create/Change) a business transaction that is assigned to an Org. Unit to which he/she is not assigned to. Moreover, we don't have any specific restrictions based on transaction type (campaign type, lead type, opportunity type) etc. To achieve this I plan to utilize authorization object CRM_ORD_LP (Visibility in the Organizational Model). This way we won't need to create separate roles corresponding to each Org. Unit - singles roles with access to specific Org. Unit by way of auth. object CRM_ORD_OE.
Just wanted to get your thoughts and make sure if there are any drawbacks of doing so. Are you able to share your experience with regards to this.

Thank you very much. Janantik.


Comment author said

By Davy Pelssers on 6 May 2013 at 18:21

Hi Janantik,sorry for my late reply..have been quite busy with complete regression testing due to upgrade of our CRM system into EHP2.

Gaurav already gave you the reply and is correct in saying you can use object CRM_ORD_LP in order to dynamically determine the access based on the user's assignment in the org model..and based on the level you are using you can do this on level of sales organisation, sales office/group and even higher level org units.

It makes sense to also restrict access based on transaction type..I assume not everyone should be allowed to use all "active " transaction types that have been defined at your customer. Basically this approach uses the second level check... in such a way you would not need to build your authorization roles using the 'combination' of <> authorization objects amongst which are CRM_ORD_OE and CRM_ORD_PR...


Comment author said

By Arunkumar on 27 February 2015 at 16:24

Hello Davy,

Nice Article Davy. Really useful...

Need your suggestion on the below requirement .

User should able to change/display Service requests belonging to his team (his Org unit in the organization structure) ,I was trying to use auth object CRM_ORD_LP (Activity – 02,03 , Tr type – ZXXX and CHECK_LEV – A,B,C,D,E) but It doesn’t give any result.

But if I maintain CHECK_LEV as *, it display all the service requests.

Any prerequisites needs to be done for using restriction in CHECK_LEV ?



Comment author said

By Gaurav on 6 May 2013 at 16:40

Hello Davy,
Nice article explaining CRM standard auth flow for transaction types.Your site is really the one site showing CRM security concepts,which are rare to find even on SAP SCN.


Yes you are right,use CRM_ORD_LP with options A,B,C,D,E in check_lev field.So by that user can only create/change transaction type for his own sales org/sales office etc.


Comment author said

By Davy Pelssers on 6 May 2013 at 18:23

Hi Gaurav, thanks for your answer and helping out Janantik :)


Comment author said

By Janantik on 16 May 2013 at 21:57

Thanks a lot for your responses and confirmation Davy and Gaurav.

I have one more question that has been bothering me and I 'm still struggling to find an answer. I want to know if there is any standard SAP authorization object using which we can restrict a User from changing statuses of CAMPAIGNS. I thought B_USERSTAT and B_USERST_T would be helpful but I realized that they are not when it comes to CAMPAIGNS. Basically, we have requirement wherein not all Users should be able to change the Status of a CAMPAIGN to "Released". But I have not been able to successfully find a way of doing so using the standard CRM authorization. Is it mandatory to have Approval Workflow in place to achieve this requirements.

Would appreciate any advise/suggestions. Thanks a lot again for your help :).


Comment author said

By Janantik on 19 June 2013 at 01:17

Hi Davy, are you able to advise on the question described in my above comment ? Appreciate your help with this.

Thanks, Janantik.


Comment author said

By Davy Pelssers on 25 June 2013 at 11:24

Hi Janantik
as far as I can tell you define your own status profile in customizing for marketing campaigns and marketing plans. In statusprofile maintanence (custo) you can add an Authorization code. Now on authorization level you do control what status can be set based on authoriation objects B_USERSTAT and B_USERST_T as you mentioned. You just must assure that you add the right statusprofile in this object and have ' ' (dummy value) set in the field BERSL (Authorization key). This would mean that people can set all status of this status profile, except those that have an authorization key maintained in customizing.



Comment author said

By Janantik on 29 June 2013 at 04:47

Thanks for your response Davy. I'll try this and let you know how it works.


Comment author said

By Mali on 3 July 2013 at 07:16

Hi Davi,

The articles are really useful. Thanks for sharing with us.

I have created a role with transaction code CRMD_BUS2000115 and it brings many authorization into the role, but those are inactive in SU24. Why it is happening? How can I avoid this?




Comment author said

By Davy Pelssers on 1 September 2013 at 11:24

not sure why you would still add the "transaction code" , at least not if you are using the CRM WEBUI, where external services of the type UIU_COMP are used.

this tcode is related to "sales related" transaction types..
check my other blogposts if you are unfamiliar with external services & UIU_COMP


Comment author said

By Janantik on 6 September 2013 at 05:38

Hi Davy, do you know if we can perform Mass assignment of Business Partners (BPs) to Position in the CRM Org. Model using an eCATT script or by any other means (BAPi) etc. Any insights into this would be very helpful. Thanks a lot !


Comment author said

By Vinita on 12 November 2013 at 17:55

Hey Davy,

I have query on restrictions of master data/BP roles based on sales org/

Scenario below

They basically want master data, business transactions etc restricted as below

1) Display for other sales org
2) Maintain for own sales org

I have successfully implemented business transactions (sales orders, acitivities, opportunities, leads, service orders etc) by CRM_ORD* objects and CRM_SAO, CRM_OPP, CRM_Lead etc and some specific auth objects for business transactions.

But for Master data, I guess, it can be restricted through B_BUPA_RLT, CRM_BP_SAO, CRM_BP_ROLE

But even after doing that, accounts for example are gettign edited of other sales org. CRM_BP_SAO doesn't seems to be restricting master data(accounts, contacts etc) based on sales org

Can you please assist how should I restrict Master data (Account Hierarchies, Accounts, Competitor Prodcuts, Contacts, Employees, Installed bases, Objects/equipments, Partner, Product ranges, Prices, Products, Products Heirarchies,) based on restriction of Sales org

1) Display for other sales org
2) Maintain for own sales org




Comment author said

By Davy Pelssers on 13 November 2013 at 09:18

concerning the usage of CRM_BPROLE vs B_BUPA_RLT please check the post http://sapuniversity.eu/sap-crm-business-partner-authorizations-crm_bprole-versus-b_bupa_rlt/ I made earlier.

Concerning the object CRM_BP_SA ; using this object you can merely restrict the maintenance of SALES AREA related data on a business partner and not secure the general business partner data itself based on sales area.

Now, suppose a customer can only have 1 sales area maintained , than you could solve this requirement by enhancing the system where you would populate the business partner with a specific BP authorization group which you"ll need to maintain in customizing (1 by sales organization).
On maintaining the sales area data, you should enhance the systme so that automatically the correct business partner authorization group is set (relevant auth. object is B_BUPA_GRP in that case).

If a BP can have multiple sales organisations than you can not really use this approach and will probably need to implement ACE , for which you"ll also find a blogpost http://sapuniversity.eu/sap-crm-authorizations-ace-access-control-engine/

hope this helps


Comment author said

By Vinita Jagwani on 9 December 2013 at 20:56


CRM_ORD_LP (Check_LEV) for some reason is not getting invoked, all traces result in a blank field value.

Please let me know if any badi needs to be activated or should a user be assigned as an employee and inturn BP assigned to Org Model or any other check needs to be done ?




Comment author said

By Davy Pelssers on 10 December 2013 at 20:51

as the Object CRM_ORD_LP basically will check a user's assignment in the org model , than I presume the assignment either as a user or indirectly via the Employee mapped to a user would be mandatory in order for the check to be applicable in the first place..

But you can work without this check if you want,...as you could also choose to work with the last check performed based on check 4 in the flow..



Comment author said

By sunil on 7 August 2014 at 08:02

Hello Davy,
Nice article explaining CRM standard auth flow for transaction types.Your site is really the one site showing CRM security concepts,which are rare to find even on SAP SCN.

here, i have small query , i want to assign Business role to position in mass?

whether it possible with some transaction.

With Best Regards,


Comment author said

By Davy Pelssers on 27 February 2015 at 17:57

are you sure that the user is assigned with an employee master record linked to his user in the org model?

secondly, can you check if the organizational determination takes place correct on your service request, meaning that in the organisational data, these parameters are filled out correct in the business transactions?



Comment author said

By Arunkumar on 11 March 2015 at 06:53

Hi Davy,

If my understanding is correct, Check_LEV field does not control organizational unit (only it controls sales organization , Service Organization, Dist Chnanel, Sales Group, Sales office). Do we have any auth object to check organization unit dynamically ?

Please correct me if im wrong



Comment author said

By Josh on 1 June 2015 at 22:13

Hi Davy -

We have a requirement for external users (in this case, our distributor's users) to only see data related to the distributor they are part of. We have 1,000+ distributors and only 1 Sales Org was created for all of them. What are our options for limiting users to only see data for the distributor they are associated with?

Thanks in advance for your help.


Comment author said

By Davy Pelssers on 5 June 2015 at 11:32

Hi Josh
when you mention data, are you referring to business transactions such as sales orders, leads, ..?

how do they access the data in the first place? through a webshop, portal, CRM WEB UI?

Hard to give any answers or solutions without having all information..
if you need consulting advice, you can always contact me


Comment author said

By dinesh on 11 June 2015 at 10:24

Dear Sir,

I have been working on CRM Authorization part. My requirement is :

A user should only able to create a transaction e.g. Quotation for his sales organization and distribution channel only. He should not be able to search those Quotation which belongs to another sales org.

I have been trying multiple combination. One example is below:

Activity: 1,2,3
Transaction type: ZAG

Activity: 1,2,3
Dist. channel: 10,40,50,60
Sales org: 0 5000001

Activity: 3
Object: A (Own sales org)
Transaction: ZAG

System is not determining the sales organization. even at the time of entring the value manually, system is giving one error (Sales organization does not exist).

When i provide the SAP_ALL. there is no error as such.

I need your help on this part.


Comment author said

By Davy Pelssers on 11 June 2015 at 14:08

You do not need to grant authorisations through multiple check-levels for your requirement.
Authorisation for CRM_ORD_LP should be fine.

But in that case you should put Activity 01/02/03 for the object CRM_ORD_LP and not just 03 (display).



Comment author said

By Sreelatha on 1 August 2015 at 05:20

Hi Davy,

Im struggling with one issue in CRM .Can you please help me out.

Requirement : User need access to ZXXX value in Interaction assignment block , but ZXXX value should not be populated when user click on New in case and complaint assignment block.

ZXXX- is a trasaction type for Interaction

When iam trying to testing for individual assignment blocks( Interactions(ZXXX), Case and Complaints(ZYYY,ZZZZ), they are working fine using Authorization object (CRM_ORD_LP, CRM_ORD_PR).

When iam combined the both roles together, iam facing the issue. Can you please help me how to restrict the values for transaction types

1. When Im adding ZXXX value in Interaction role for Authorization object (CRM_ORD_LP, CRM_ORD_PR), user is able to click on create button in Interaction assignment block, but whereas ZXXX value is also populated in the Case and Complaint when clicking on New in Case and complaint assignment block along with these values ZYYY,ZZZZ

2. When im adding ZXXX value in Interaction role for Authorization object (CRM_ORD_LP), user is able to click on create button in Interaction assignment block, but whereas ZXXX value is also populated in the Case and Complaint when clicking on New in Case and complaint assignment block.

3. When i remove ZXXX value in Interaction role, user is unable to click on create button in Interaction assignment block, but whereas s ZXXX value is not populated in Case and Complaint when clicking on New in Case and complaint assignment block.


Comment author said

By Davy Pelssers on 7 August 2015 at 10:15

Hi Sreelatha
your requirement is very unclear, but from what I seem to understand I can tell you the following:

with objects CRM_ORD_LP, CRM_ORD_PR you can control access to specific transaction types, meaning e.g. you give a person acess to a LEAD of type ZLEAD, and only in display mode for exmple (Activity 03).

The issue you have , as I understand is that when on e.g. the assignment block complaints,you create a new one, you see multiple transaction types which are not wanted in that particular assignment block but you expect only transaction type ZZZZ .
In that case you can not control this via authorisation objects, as you merely control e.g. create acces to document types, but not WHERE they can be used. So if you have this requirement I suggest you have your developer debug HOW this list of allowed transaction types are build up for that assignment block, and manipulate the gettter I presume by an enhancement.



Comment author said

By Amal Aravind on 29 October 2015 at 11:53

Hi Davy,

Its is a very nice document. Thanks.

I have requirement to restrict all WebUI transaction search based on the sales area and territories.
For eg : Lets say in Lead I am using transaction types YLD1 and YLD2, now if I am searching Leads then the result page should be only having the records with the sales area and territories assigned to my role for both YLD1 and YLD2 transaction types.

Currently If i have authorization for Lead transaction type the the system is not checking for Sales Area authorization( as the process flow explained by you above).

Is is possible via roles or ACE(i have very little knowledge in ACE) can fulfill my requirement.



Comment author said

By erica smith on 3 March 2016 at 19:35

Hi There,

I was wondering is the ability for a user to create customer move-ins and move-outs contained in one of the authorizations in CRM. If so which authorization object would this be? Currently users create customer move-ins/outs and it is replicated to the ISU backend. The issue is that the ISU backend has be restricted and users are still able to perform this activity through the web_ui.


Comment author said

By Davy Pelssers on 4 March 2016 at 09:29

sorry, but I would not be able to tell you without looking into the system. If the move in and out are also transaction types in the SAP CRM system then you could use the authorisation check explained in this blog..
otherwise - you could remove the logical link from those users by UIU_COMP I presume?


Leave a Reply