How to identify the relevant UI_COMP SAP CRM authorization values to protect workcenter Access

Print Friendly


Somewhat 3 years ago I investigated an efficient and easy way to find out the relevant authorization values needed for the authorization object UIU_COMP related to SAP CRM Work Center Access.

You are welcome to download this short tutorial I made!

Relevant Tables Used for my SQVI Query:

  • CRMC_UI_PROFILE : profile
  • CRMC_UI_NB_A_WC : navigation bar
  • CRMC_UI_WC_T : Work Center Definition (texts)
  • CRMC_UI_WC: Work Center Definition
  • CRMC_UI_LLINK : logical link Definition
  • CRMC_UI_COMP_IP : Component Inbound Plug Definition
Using this query allows you to create an output list of all Work Centers defined for a specific Business Role, based on the assigned Navigation Bar. For each Work Center you will then know what specific UIU_COMP Authorization values are needed to have access to that particular Work Center, or alternavitely, which values you should remove from your SAP CRM PFCG authorization role in order to remove access to 1 or multiple work Centers.
In the document I also explain the Business Role Customizing approach, where you simply can deactivate a Work Center.



I think you'll see this query is very useful if you are a SAP CRM Authorization administrator.


Davy Pelssers

Sap University Team


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

13 thoughts on “How to identify the relevant UI_COMP SAP CRM authorization values to protect workcenter Access

Comment author said

By Lakshmi on 5 January 2013 at 20:23

Hi Davy - Thx for the document. I have doubt. When we consider the Scenario B where the same ZSECURITY role needs to be assigned to both Sales manager and Sales rep and when we control the UIU_COMP auth object in ZSECURITY role by removing few WC still even the Sales manager will not be able to see those WC right? Did you mean that we need to create 2 indicidual roles ZSECURITY and ZSECURITY1 with restricting UIU_COMP in one of them which needs to be assigned to Sales Rep? If that is what you meant then which PFCG role will be tied to the Business role? Can you please clarify this for me?


Comment author said

By Davy Pelssers on 6 January 2013 at 18:00

Hi Lakshmi,
in scenario B you would only have 1 business role (in this case I called it ZSECURITY) but you might have called it ZSALESPRO as it was a copy of the SALESPRO business role.
On authorization level, you woul create separate authorization PFCG role with different access. I usually create 1 single pfcg Role PER work center and then assign this single role to composite roles based on who should be getting access to these workcenters or not.


Comment author said

By srinivas on 15 February 2013 at 13:06

Hi Davy,

For our client need to design sales and marketing Business roles. sales and marketing business roles are created by crm technical peoples. I need to develop PFCG roles for business roles . but i am new to crm security.Please tell me best process to build the PFCG Roles.

questions: 1 . i need to create pfcg roles separately and link to Business roles.


2 . run the report CRMD_UI_PREPARE to generate the Pfcg role menu.

Pls suggest me , wich method is better for Building PFCG Role Design....... IF 1st method is best one then how to create PFCG Role without Business Role.

Pleasehelp me to Design Pfcg roles.

If any thing wrong, Please correct me......




Comment author said

By Davy Pelssers on 11 March 2013 at 23:14

Hi Srini,
you could do both options, but personally I think the easiest option would definitely be option 2; using the report CRMD_UI_PREPARE. Normally you would run this report once the functional CRM consultants are kind of finished in customizing the business role & it's navigation bar. Entries (e.g. workcenters/nav links) that are added later on to the business role can be identified using ST01 authorization tracing in a later stage.


Comment author said

By Tammuz on 22 October 2014 at 22:04

Just wanting to know which I've not seen you cover just yet or maybe I'm wrong.
All I want to do is make read only or non editable my assignment blocks so users don't click.?
I think it's object UIU_COMP


Comment author said

By Davy Pelssers on 23 October 2014 at 11:59

You can NOT control this via UIU_COMP.
this only works for 'navigation links'.

Some buttons will also be influenced, such as buttons to create 'corporate account', and so on. but for buttons on assignment block there are NOT standard authorization objects which enable/disable them.

You will probably need to encode your own logic in the methods DO_PREPARE_OUTPUT and/or IF_BSP_WD_TOOLBAR_CALLBACK~GET_BUTTONS

But if you just want to achieve that the COMPLETE partner can not be edited (so the header data and all other assignmnet blocks) than there are other ways to achieve this.


Comment author said

By Tammuz on 23 October 2014 at 23:07

Hi Davy
This is a shame, will I be able to control authorisations for the assignment blocks? So let's say the edit or new button on my relationship assignment block is not greyed out. What if I want to be able to control so when users click on edit or new button on the assignment block than a authorisations message occurs? Can this be done Davy?
Which auth objects control that behaviour? I can't find auth objects on web UI which controls assignment block?

I will purchase your book as your doing some good w


Comment author said

By Tammuz on 23 October 2014 at 23:12

Hi Davy
Didn't finish my last word I meant to say " great work your doing"
Finally can I create custom auth objects for assignment block so that edit and create buttons are greyed out?


Comment author said

By Davy Pelssers on 24 October 2014 at 09:56

If you describe your requirement in complete detail then I can think about it.

for example:
- do you want ALL assignment blocks not to be editable?
- do you want the complete customer not to be editable?
- do you want e.g. the account details assignment block to be editable and some other assignmnet blocks, but e.g. bankrelation data not to be editable.

Depending on which requirement you have, there are different solutions.



Comment author said

By Tammuz on 24 October 2014 at 21:21

Hi Davy,
Many thanks for this and yes my requirements are as follows

I will need to make all my assignment blocks non editable or greyed out and these buttons are either the EDIT button and or the New button as some of the assignment blocks have a New button.

I was wondering if the buttons are not controlled or made greyed out than which auth objects can I use to restrict authorisations and what I mean is if someone clicks on the NEW or EDIT button than a message appear " you are not authorised "?

I'm not sure whether or know of any auth objects and that's why I'm thinking I rather grey out the buttons so they can't be editable.

It's simple the business doesn't want anyone editing just showing the assignment block.

If you know the best way of doing this that be perfect else it's development for us and that's not nice.
Please advice on any BADIs to be used or anything like this.

Thanks very much


Comment author said

By Tammuz on 24 October 2014 at 21:58

Hi Davy,
I should have stated also -
Is it possible at all that I can for a particular BP or all BPs I can be able to only change the delivery address type on the address type building block? we have several address types and correspondence must never be changed but only the delivery address? Again can AUTHS do this?



Comment author said

By Davy Pelssers on 25 October 2014 at 12:22

hi, please read:
here most (or all) of the business partner 'authorization' objects are mentioned.

Additionally read the info on the OSS notes about relevant Badi's that you also might be able to use.

To answer your last question: there is no standard authorization object to maintain only certain adress types - at least not that I know of.

For the rest: anything can be achieved via custom development /badi's / enhancements/.. but the only thing you should keep in mind is that there should Always be a good balance to what the customer wants,and wether or not this is really necessary, makes maintenance and support transparant and maintainable, the cost of implementing additional non standard authorization requirements, and potential upgrade issues that might arise due to custom developments.


Comment author said

By Tammuz on 25 October 2014 at 14:18

Hi Davy,
Many thanks for the advice and the listing of auth objects I have suggested the use the BADI as below

B_BUPA_RLT Roles: With this authorization object you define which Business Partner roles can be edited. SAP GUI only (unless you implement OSS note 1259940)

But..... I saw this auth object too

B_BUPA_GRP Authorization Groups: With this authorization object you define which business partners can be edited on the basis of the authorization group. (SAP GUI & WEBUI)

....why can't I use this ? There is no need for implementing a BADI here.

My aim was to make some BP's editable on WEBUI and make some display only.

So my final point is making the assignment blocks all display only and non editable as per previous blog, I'm not sure which BADI or OSS note I can use for this?

I'm aware of the BP 's BADI BUT NOT THE ONE FIR ASSIGNMENT BLOCKS? and finally are you saying I can use the above BADI OR OSS note to control the Address types?

The key for me is to be 100% certain auth objects can't be used
If the OSS 1259940 is implemented do I need to create a Z auth object?

Apologies for the detailed issues here.
Thanks again Davy


Leave a Reply