Restrict User for specific organizational unit

[Former Member]

Hi Experts,

I am having a scenarion where I need to restrict the user logging in to see the data(service orders) pertaining to his sales org only, Moreover I need to restrict it to the service team(organizational unit) only.

In another scenario If a user is creating a service order I want to dispaly the service order type pertaning only to his specific sales area, i.e he should not be allowed to create service order of other order types.

Please give your inputs for solving this.

Thanks and Regards,

Mayank

[laercio_azevedo · Accepted solution]

Hi Mayank,

I had similar issue and then after working long weeks on it, I could solve it as follow.

Using standard authority object you can restrict access based on Organizational Unit, despite of Org. Unit have been master data.

Using PFCG tx, create a profile with this authority:

CRM_ORD_PR: PR_TYPE 'Z021',ACTVT '01, 02, 03'

CRM_ORD_LP: CHECK_LEV 'B',PR_TYPE 'Z021',ACTVT '01, 02, 03'

CRM_ORD_OE: ACTVT u2018u2019, DIS_CHANNE u2018u2019, SALES_GROU u2018u2019, SALES_OFFI u2018u2019, SALES_OFFI u2018*u2019, SERVICE_OR u2018O 50066793u2019

Some explanations about parameters:

PR_TYPE is the document type that you want to allow.

ACTVT are the activities (show, create, modify, delete) you want to allow for the documents (PR_TYPE)

CHECK_LEV means what level of your Organization Unit you want to check, in order to define if user has or not access to the document. This parameter has lot of possibilities; you can test and find out what is the best value for you.

CRM_ORD_OE is the key object for you, it set the Org. Units. ID that you want to allow for users. In my example, I defined that users can access and do anything for documents created for Service Org. ID u2018O 50066793u2019. This ID you get via tx PPOMA_CRM. However, you can restrict access based on Sales Office, Distribution Channel and so on. This parameters has direct relation with the value set for CHECK_LEV, depend on the value you set to CHECK_LEV will mean how deep CRM will test you Org. Unit.

Donu2019t forget, you must use and set all objects CRM_ORD_PR, CRM_ORD_LP, CRM_ORD_OE, because they work together. If you set only CRM_ORD_OE your profile probably wonu2019t work.

The last thing, Service Org. ID u2018O 50066793u2019 is master data, so it can change in different system or client, so be aware of it.

On this link you can find some examples about authority object.

http://help.sap.com/saphelp_crm50/helpdata/en/4a/b9f63a8ab2c745e10000000a114084/frameset.htm

Good luck,

Lalas

Edited by: Laercio P. Azevedo on Jan 18, 2010 7:29 PM

[Former Member · Accepted solution]

Hi Lalas,

Thanks for the elobrated explanation...... it did exactly solved my requirement.

Thanks again,

Mayank

[nelson_raj2]

Hi,

This is not a straightforward thing to do if the users share the same transaction type and you would like to differentiate based on the Organization Unit.

This is because Transaction Type, etc., are technical "Configurable" data, and Organization Unit is "Master" Data.

Simple PFCG based access can help you build checks based on configurable data, but not on master data.

Hence, you would need to implement something called - Access Control Engine for SAP CRM.

The links are available for the same as follows:

CRM 7.0 - http://help.sap.com/saphelp_crm70/helpdata/en/47/6019a4eb946831e10000000a421937/frameset.htm

CRM 5.0 - http://help.sap.com/saphelp_crm50/helpdata/en/04/0177f9bb67ac4cafb84bb4d4c1d8fc/frameset.htm

Regards,

Nelson S. Raj

[nicolas_busson]

Hello Nelson,

Sorry but I'm not sure to understand you correctly. In his first message, Mayank was talking about two requirements:

1) First one:

I need to restrict the user logging in to see the data(service orders) pertaining to his sales org only, Moreover I need to restrict it to the service team(organizational unit) only.

What is it exactly that standard authorization object CRM_ORD_LP cannot provide compared to custom ACE programming?

2) Second one:

If a user is creating a service order I want to display the service order type pertaning only to his specific sales area

Correct me if I'm wrong but as far as I remember, ACE is not relevant for creation mode. It can only control read/modify/delete access.

Thanks for your help and clarifications.

Regards,

Nicolas Busson.

[Former Member]

Hi Nicolas,

Thanks for the explanation. Here is what i have digged abt these two scenarios:-

I think the authorization object CRM_ORD_LP can be used to restrict the user based on the sales org unit , This is also given in the link : http://help.sap.com/saphelp_crm60/helpdata/en/d8/af9a39b4aa3a2be10000000a11402f/content.htm

But what about restricting the user for certain transaction types ? for this also the authorization object CRM_ORD_PR is mentioned in the link

http://help.sap.com/saphelp_crm60/helpdata/en/26/99973915e69238e10000000a11402f/content.htm

But i am not sure about it.

Is there any other option available for acheiving the same?

Thanks and Regards,

Mayank Choudhary

[nicolas_busson]

Indeed according to me using authorization object CRM_ORD_PR is the easiest way to restrict the business transactions a user can create. BUT: this authorization object is not "sales area dependent", meaning that you won't find any standard SAP table where you could say:

1) Users from sales organization 1 can create business transaction xx and yy

2) Users from sales organization 2 can create business transaction rr, jj and mm

3) Etc.

So here is what you can do:

1) Double check the link I sent you in my first post. They are talking about CRM_ORD_OE : I never used it, but you could try and check if this authorization object is suitable for you.

2) Or use object CRM_ORD_PR and create as many PFCG roles as needed to cover your sales areas.

3) Or you still have the option to do some simple development (depending on your CRM version it might be more or less complex). For example if you are running a CRM6.0 system, enhance component BTFOLLOWUP and redefine method ON_NEW_FOCUS_BTADMINH from node PROCTYPE of the component controller... to implement any logic you want...

Kind regards

Nicolas Busson.

[nicolas_busson]

Hello,

I would suggest to take a look at the following online help, because this is probably something you can implement using standard authorization objects:

http://help.sap.com/saphelp_crm70/helpdata/EN/e9/b29a39e7aee372e10000000a11402f/frameset.htm

http://help.sap.com/saphelp_crm70/helpdata/EN/d8/af9a39b4aa3a2be10000000a11402f/frameset.htm

Kind regards,

Nicolas Busson.