Access Control Engine in CRM

Print Friendly

Introduction to ACE

A lot of big clients having big or complex CRM installations face the same problem: how can we restrict the users only to particular data that they need to see?

We don’t mean authorizations related to functionality, but related to business content (Real time data). Imagine you run a big business and have millions of customers worldwide. Then a sales representative responsible for a group of customers in Region AAA should not see any customers from Region XXX in his search results. Or a sales representative with responsibility for a certain branch should not be bothered with customers of other branches. Most important here is if the structure of the sales organization changes, you don’t want to end up changing all kind of authorization profiles/Roles.

To solve these issues, SAP came up in CRM with a pretty nice solution: CRM-ACE. This stands for Access Control Engine and is a framework to dynamically calculate user dependent access rights on object level. It originates from Channel Management but works in all PCUI (People Centric User Interface) functionalities. One Limitation here is, it doesn’t work in other environments like IC Web client or via the SAP GUI.
Now ACE works in the SAP CRM Web UI as well.
The access control engine (ACE) in SAP Customer Relationship Management (SAP CRM) is an additional authorization concept that exists in parallel to the SAP authorization concept. You can implement ACE independent from the SAP authorization concept, but to save time and effort when you create ACE user groups, you can reuse the authorization roles (PFCG roles) that were defined in the SAP authorization concept.
While you can use the SAP authorization concept to limit user access to transactions (such as creating an order) and activities for an object type (such as creating or deleting an order), ACE provides a framework that you can use to control user access to individual business objects and the usage of those business objects. This means that you can define which users see which business objects, and whether those users have the authorization to read, edit, or delete those business objects.
The access control is based on a combination of rules and rights that you can adjust individually for your internal organizational structures.
Users only see the business objects to which ACE grants them access. However, users do not see the ACE functions on the screen and do not consciously notice ACE.
ACE is of interest to large organizations because it uses organizational units that mirror territory management very effectively. In other areas, the advantage lies in the versatility of the business hierarchies in including external partners in internal business.
You can use ACE to define that a Business Partner has read authorization and write authorization for his opportunity, read authorization for the opportunity of her colleagues, and read authorization and write authorization for all new opportunity of the company.

Difference between Normal CRM authorizations and ACE

  • The SAP authorization concept is registry-based. If there are new users or objects, we need to make adjustments to the SAP Roles.
  • In the traditional concept, we have to specify all values in the roles, that is we need to specify the sales organization from which the user is allowed to fetch data. Now, If we have 30 sales organizations you need 30 roles which will segregate all 30 sales org and will be assigned to 30 different user group in those organization. This is also known as Static authorizations.










  • Access Control Engine is based on rules, rights, relationships, and hierarchies. Once the ACE rules and rights are set up, it is not necessary to adjust these rules and rights if there are new or changed users or objects.
  • In Access control engine, we can specify in one role that all users who have this role will be able to see specific customers for the sales area to which they are linked to. So with 30 different sales organizations we only need one PFGC role. If a sales representative moves from one organization to another you don’t even need to change his Role/profile. This is known as Dynamic authorizations.


Features available in ACE

Below functions are available in ACE:

  • ACE provides an administrative tool for all rights and rules that influence access control. The administrator can assign these rights and rules to users and roles.
  • ACE supports changing user integration in business operations, such as changing the role or organizational unit. The new access control for users is calculated in day-to-day operation or asynchronously (time-shifted). If reorganization affects a large number of participants, an administration tool supports the changes to access control.
  • ACE first gives users temporary full access to new objects that they create. When users save, the system starts a process in the background to calculate the rules-based access control for these objects. The resulting user access rights replace the temporary full access.
  • The system changes the access control for changed objects during runtime. This is done by a process in the background. The new access control is effective after a delay.
  • ACE has a buffer for previously calculated access control information. You can use the buffer to check and monitor the access control during runtime.
  • You can define the relationship between objects and users, for example, for organizational units, partner companies, areas, or product lines. You can define access rights, for example, so that employees of a partner company can access business objects that were created in that partner company, but cannot access business objects that were created in other partner companies.
  • ACE has been designed as an add-on. It can be used in many different ways to take advantage of the business knowledge available in SAP CRM. The ACE framework serves all add-ons centrally. You can develop new add-ons for special enterprise requirements as necessary.

ACE Concept

The basic element in the concept of ACE is the actor. To explain this in the easiest way you can say this is the linking and filtering element between the user and the object. The actor determines if the user should see the object or not. As an example look at the following picture which explains the scenario that a user is only allowed to see business partners where he is in the sales team. The user is linked to an employee and these employees are stored in the sales teams of the business partners.


From the user’s perspective you can determine the employee id which is in the sales team. Also from the business partners perspective you can see who are in his sales team. If both of them match, the user can see the object.

How the actor from both perspectives is determined is stored in a rule. Here are three methods defined:
  1. How to determine the actors from the user.
  2. How to determine the actors for an object.
  3. Method to specify which objects to take into account.

This is shown in the following pic:


An ACE rule is a combination of a role and an action (read, write, delete). These rules you can assign to ACE user groups which you can link to individual users or in most cases to dummy ‘normal’ authorization roles which you can assign in the user master.

The good thing about the concept of ACE is that when you activate it, it fills the ACE tables with data so it can determine who is allowed to see what data object in a fast manner during runtime. Basically it determines before hands for all users and for all objects what its actors are and stores this in tables. During runtime it knows your user, so can quickly read your actors and then read all objects which have the same actor. If a new object is created after the activation it automatically in the background determines the actors and updates the corresponding tables.

Standard Technical Flow


ACE customizing

Business Scenario:  Any particular account and its Contacts can be displayed / edited / deleted by the employee who has created that account and the other employees who are related to that Account with the relationship type “Is the Responsible Colleague Of”.

General parameters:
We need to maintain few of the Parameters as below

1. DISPATCHER_DESTINATION parameter should have the name of RFC destination     through which ACE update job is scheduled. The default entry is      “ACE_ACCESS”. 2. Then to     deactivate/activate ACE you need to include the parameter “ACE_IS_INACTIVE” which     when set to “X” makes ACE inactive and if blank then ACE is active.


Rule Customizing

Rule Customizing consists of defining the AFU, OBF and AFU class. AFU stands for Actor For User. This is used to determine actor_id the user is assigned to. This create  entries in the UCT table.OBF stands for Objects By Filter. This is used to determine which objects are relevant for the group.

AFO stands for Actors for Objects. This is used to determine the actors that are to be applied for the found objects.

IMG Path : IMG --> CRM --> Basic Functions --> Access Control Engine
ACE Customizing
Step 1: Add Super Object Type
You see default entries already maintained for our object ACCOUNTCRM. If the need arises one can add a new super object type too. We fill in the ACL table name, then GRP table name and UCT table name.
These are the runtime tables where in the authorization data is stored. You can have a look at the data of these tables from SE16. Because an individual set of runtime tables is created for each super object type, authorizations are spread across several tables. This enhances the performance.
Step 2: Add Object Type

For each CRM object type used in ACE, a default BOR object type is assigned in table CRMC_PRT_OTYPE. Say for example object type “ACCOUNTCRM” the corresponding BOR object type is “BUS1006”. To define an object type, refer to the screen shot below.
Then you have the concept of Action and Action group. Actions are summarized in action groups, and used in connection with rights, they grant users specific authorizations such as READ, CHANGE, or DELETE.
Step 3: Create Actor Type
An actor type describes the relationship type between the user and an object, for example, contact person, responsible employee. Whereas actor is an attribute of Actor Type. Refer to the screen shot below to create an Actor Type. Here we have created an Actor type “ZACC_EMP_RESP” for Employee Responsible as per our scenario explained in the start.
  • Create a new Actor Type.
  • Or use existing standard actor.

IMG Path: CRM > Basic Function > ACE à Rules > Create Rules > Create Actor Type


Step 4: Add AFO Class
AFO stands for 'Actors for objects'. Here we define AFO class ID for our Actor type created in the previous step. The class “ZCL_CRM_ACERULE_ACCOUNT” implements the interface “IF_CRM_ACE_ACTORS_FROM_OBJECT”.Create a custom class or use standard one to assign as AFO Class.
  • Find the object Type of your interest (Eg.: Opportunity)
  • Assign the Actor Type ID (Eg.: ZIRACTOR)

IMG Path: CRM > Basic Function > ACE > Rules > Create Rules > Add AFO Class

ACE 10

Step 5: Add OBF Class

OBF stands for ‘Objects by filter’. Here also we define the same ABAP class we defined in the previous step. We need to implement the interface “IF_CRM_ACE_OBJECTS_BY_FILTER“in that class.
  • Find the object Type of your interest (Eg.: Opportunity)
  • Create a custom class or use standard one to assign as OBF Class

IMG Path: CRM > Basic Function > ACE > Rules > Create Rules > Add OBF Class

ACE 11

Step 6: Add AFU Class

AFU stands for ‘Actors for User’. We need to implement the interface IF_CRM_ACE_ACTORS_FROM_USER in the class “ZCL_CRM_ACERULE_ACCOUNT”.
  • Assign the Actor Type ID (Eg.: ZIRACTOR )
  • Create a custom class or use standard one to assign as AFU Class

IMG Path: CRM > Basic Function > ACE > Rules > Create Rules > Add AFU Class

ACE 12

Step 7: Create Rule

This is the final step in creation of ACE Rule. This rule would be used in the Right definition step.
  • Bind the actor type id, AFU class ID, AFO Class ID, and OBF Class ID  with a rule id for object type.

IMG Path: CRM > Basic Function > ACE > Rules > Create Rules > Create Rule

ACE 13


Rights Customizing

Right Customizing consists of defining the user group, and combining the user group, the allowed action (read, write, delete) and the rule into a “Right”.

Step 1: Work Package Definition
A work package is an organizational unit of the ACE, which combines user groups and enables them for one or several object types. We define a work package for all our Account Related ACE Rules. The super object type assignment ensures that users of the user group(s) are only active ACE users of the respective super object types and their sub objects.
  • A work package combines user groups and enables them for one or several object types.

IMG Path: CRM > Basic Function > ACE > Create Rights > Work Package Definitions

ACE 14

Step 2: Object Type Assignment for Work Packages

  • Assign the super object type to a work package.

ACE 15

Step 3: User Group Definition

A user group contains users who should get authorizations for objects. User groups can contain single users, as well as roles. Furthermore, they can be nested. User groups are assigned to work packages.
A user group can be assigned to one work package only, nesting of user groups may result in non-unique assignments. For example, Group G1 is assigned to Package P1. Additionally, Group G1 is nested in Group G2, which in turn is assigned to Package P2. The user group in Package P1 is therefore not valid, because assignment to a package of Group G1 via nesting in Group G2 is not unique.

IMG Path: CRM > Basic Function > ACE > Create Rights > User Group Definitions

ACE 16

Step 4: User Group Entries

The entries in the User group can be defined as a User, Role and a User group. Normally it makes sense if you create a role for which ACE authorization is applied and add that here. For demo purposes I have added a set of user IDs here.

ACE 17

Step5: Right Definition

Right definition makes the connection between a rule, which provides the objects as well as the actors, and the users, who are stored in the right via the user group. The right also defines the possible actions that the user can execute with the objects of the rule. Furthermore, you can specify a validity period for the rights and hence control them chronologically. Refer to the below screen shot which shows the Right we had created.
IMG Path: CRM > Basic Function > ACE > Create Rights > Right Definition
ACE 18

Technical View in ACE

If you create a new ACE right you have to implement a new class (copy from an existing class in the range CL_CRM_ACERULE*). The class contains 5 methods:

  1. GET_ACTORS_FROM_USER: This method receives the user id in the field im_usr_name and determines the actors for this user which should be put in table ex_actor_id_table.
  2. GET_OBJECTS_BY_FILTER: This method determines which objects to take into account and puts their GUIDs in table ex_object_guid_table.
  3. CHECK_OBJECTS_BY_FILTER: This method receives the table from the GET_OBJECTS_BY_FILTER method and here you can add additional filtering.
  4. GET_ACTORS_FROM_OBJECTS: This method receives the internal table of method CHECK_OBJECTS_BY_FILTER and for all these object GUIDS it determines the actors at once. It puts these in the table et_actor_ids.
  5. GET_ACTORS_FROM_OBJECT: This method is called when there is a new object created after the activation; e.g. when you create a new prospect this method calculates its actors. It gets as input the object GUID in field im_object_guid and gives its actors in table ex_actor_id_table.

ACE 19

Note: Methods 1-4 are used during the activation of ACE and the last one is used when new objects are created.

Sample Code for the above methods:

In this example implementation of class ZCL_CRM_ACERULE_RELATION is done, which allows users only to see business partners for which they have a relation with. For example, they are defined as employee responsible, or as account manager.


Important tables in ACE

The relevant tables involved are the following (where XX can be BP for business partners, OO for ‘one order’ objects which can be activities, orders, opportunities and leads, and PR for products; these are the three objects for which SAP delivers tables)
1. CRM_ACE_XX_GRP: In this table all possible actors are stored (e.g. all employee numbers or all sales areas) with their ACE_GROUP_ID, which is the GUID linked to this actor. Here, rights are mapped to actor_id’s and ACE-groups. This table will generally not contain many entries.
2. CRM_ACE_XX_UCT: In this table all users with all their ACE_GROUP_Ids (=all their actors) are stored. Or in other words we can say it contains the mapping between actual USERID’s and the ACEGROUP.
3. CRM_ACE_XX_ACL: Here all object Ids with their actors (in the form of the ACE_GROUP_Ids) are stored. This is the actual Access Control List. All relevant business partners are linked to an ACE-group. One business partner can be assigned to several ace-groups. This table will generally contain many entries (at least one for every BP).
From these tables you can easily see how ACE internally works:  It knows your users, then reads in the user context table (*UCT) your ACE group Ids, and then in the access control list table (*ACL) it reads directly all objects you are allowed to see. It works as easy as that.

Activate Work Package and Rights

Once we are done with Configuration and technical coding (Which I have explained after this topic), we need to activate Work Package and Rights.

First activate you User Group from the User Groups tab and then activate your right from the Rights tab.
  • Activate Work Package
  • Activate Rights
  • This activity will fill the runtime tables for ACE

IMG Path: CRM > Basic Function > ACE > Activate/Deactivate Work Package and Rights

ACE 20

Once the right has been activated you can check out a job runs which can be checked in your SM37 TA and the runtime tables are filled in with the authorization data. After the job finishes, you can check out one of the runtime tables CRM_ACE2_BP_ACL filled in with authorization data.

ACE 21

ACE Design Report 

Finally once the entire configuration is done, then our design can be verified using the transaction “ACE_DESIGN” by giving the Right Name as input.

Now, check out the TA ACE_RUNTIME which will show the runtime data. One can check out the accounts a particular user can access. One can also check out whoever is allowed to access a particular account.  
Filter Selection To call the report, select at least one super object type. If you have selected a super object type, you can refine your search by additional criteria and display the list.
IMG Path: CRM > Basic Function > ACE > Create and Analyze Runtime Data
ACE 22
Performance considerations
When applying ACE, you should consider performance, as ACE will generally create big ACL tables and call these tables often. You can influence the size of these tables from a functional perspective by focusing on the object groups rather than user groups when implementing ACE. I will explain this based on an example:

Let’s say you have 10.000.000 business partners in your system to which you want to apply ACE. You are implementing ACE for 5 user groups. All of these user groups have display rights for all business partners.
Each of these user groups has a specific group of 2 million BP’s they will get change-authorization for. You now have two ways to implement this:
Option 1

Create 5 work packages, one for each user group and contain the definition for the user group in the work package. The work package could consist of the following rules:
• Display rights for all business partners.
• Display rights for all contacts of the assigned business partners.
• Change rights for the 2 million business partners based on an attribute.
• Change rights for the contacts of the 2 million business partners.
Option 2

Create 6 work packages, one for each user group and one for the display all. The display work package would contain the display rights for all business partners; the change work package would contain the change rights for the specified group.
In the above example, even though from a customizing point of view, it doesn’t seem to matter, in practice, the second option would be the best, because in the first option, the access control lists of all 5 work packages would contain 12 million entries (10.000.000 + 2.000.000). These sums up to 12 * 5 = 60 million records to check when trying to display a business partner. Not to mention the fact that contact persons should also be counted in.
In the second example, there are 10 million entries in the display work package, and 5*2 million = 10 million in the other work packages, summing up to 20 million records to check when trying to display a business partner.
The conclusion is that when implementing ACE, think from an object perspective, and not from a user perspective. Rather assign more than one ace PFCG role to a user than assign more than one ‘right’ to a work package, unless they obviously belong together (such as accounts and their contacts).

Priya Ranjan Singh has been working as an SAP Security Consultant since 2010. He have worked with Wipro Technologies ,Accenture in past and currently working with Ernst & Young.
More about

7 thoughts on “Access Control Engine in CRM

Comment author said

By Ranjit on 11 March 2014 at 13:05

Great doc !! Thanks for sharing !!


Comment author said

By Kiran Vemula on 8 August 2014 at 04:59

Hi Ranjan,

Excellent article about CRM ACE. I have been searching for information about ACE and I landed up here. Excellent consolidated information about the topic.
Can you please tell what would be SAP Security specific activities in CRM ACE security. Do we need to perform all the steps explained above ??


Comment author said

By Priya Ranjan singh on 2 September 2014 at 10:51

Hi Kiran,

Thanks for your valuable comments. Yes as a Security consultant you will have to perform all these activity, and yes your abap team will definetly help you with coding part.
In many of the projects, I have seen CRM Functional team doing these activity as well.

PriyaRanjan Singh


Comment author said

By Swati Singh on 16 February 2015 at 09:22

Hi PriyaRanjan,

Thats a very informative article.
I was a little curious to know can you give me an idea as to typically how much effort would be required for an ACE Implementation for a medium sized cutomer base say 1000 users.

Any hint would be good.



Comment author said

By Priya Ranjan singh on 16 February 2015 at 09:44

HI Swati,

Thanks that you liked the article.
Regarding your question, I will tell that Effort mostly depends upon how many Sales organisation or sub resign your company is having.
But still I can say going for ACE is good if your company do business in multiple country having multiple sub region. Otherwise I will advise to go with normal CRM Security concept.

PriyaRanjan Singh
SAP Security


Comment author said

By Esser on 1 September 2015 at 18:32

Hi PriyaRanjan,

Thanks for the article, it's so helpful. But i think i made a mistake because after activating the rights; i could not see any job about ACE in sm37. Do u have any idea about this issue?



Comment author said

By Sumoy Sen on 12 April 2017 at 20:57

Hi Priyaranjan,

Great article indeed;

I have come across of a situation where in our customer SAP CRM production system whenever the ACE_DISPATCHER job is running it is completing successfully but at the same time throwing dumps in ST22; the dump details says that the corresponding CRM_ACE_DISPATCHER program is encountering an error in executing a step where it is not finding a class "Z***""; when i analyzed the ACE configuration then I found that a particular user X was moved from one user group to another; going back from here I see that when the user X was moved from an old user group to a new user group then the functional consultant (from the previous IT vendor) had deleted all relevant right, work package and user group as the relationship is "multiple users to 1-user-group to 1 ace-group to 1-actor to 1-work package...everything is currently designed as 1x1x1x1 manner...since the user X moved from previous user group to a new one so there was no other user in the previous user group...so the previous functional consultant deleted user group, right, ace group, actor and work package everything which were there for the user X when that user was not moved. Now I see in system there are multiple objects created with user X when the user was associated with previous ACE rights-ace-groups-work-packages...this I am finding from ACE_RUNTIME report when I am executing the same with the dumping/missing class name (actually the naming convention is our ACE design is same for class, rights, work-packages etc. etc.)

So now what I am guessing is that the ACE_DISPACTHER program is finding old ACL entries with the deleted ACE objects (rights, work-packages, ace-groups etc.) but in ACE configuration those entries are missing (deleted by previous functional consultant) and hence encountering an exception when trying to create a class with the missing details.

Can you please confirm that once one or more objects are created with existing ACE design then no-one should delete any ACE configuration entries and if needed to move a user from one group to another just we can move and leave the previous ones as they are...

Confirming the above will help me to conclude the root cause analysis that I had done for my case;



Leave a Reply