Who is an external user?
These are the people who work for your business partners. Let us consider an example. Joe works for ABC Advertising Company. You work for XYZ Widgets Inc. You use ABC company to manage some of your campaign advertisements. Hence, Joe needs to logon to your CRM system periodically to create advertisements, claim for expenses etc. You also use company DEF for managing some other advertisements. Jane works for DEF and also needs to logon to your CRM system to do the things that Joe does.
Joe and Jane are external users. We need to figure out a way for Joe and Jane to login to the system and do what they want to do. You also want to make sure Joe and Jane do not get access to each other’s data – that is for example, you don’t want Joe to find out that you give more business to Jane’s company.
John and Jane needs to do exactly the same transactions in the system – same screens, same navigation etc. What differentiates them is the data made available to these transactions. How do we solve this?
Option 1
One way is to create a new business role, which has the necessary navigation profile attached to it, and assign it to a PFCG role. Now you assign the PFCG role to Joe’s user master. Then we copy the business role and PFCG role, and do the same for Jane. This will work well, as long as you work with only ABC company and DEF company. Whenever you hire a new company to do your advertising, you have to do this exercise again. Any time you want to change a role, you have to do it for all companies. Bottom line – with a large number of users and business partners, this strategy doesn’t give us any economies of scale.
Option 2
So what other option can we go for? Fortunately, CRM gives us the utility called ACE – which stands for Access Control Engine. Let us take a brief look at how ACE works. There are a lot of blogs out there in SDN which will discuss the nuts and bolts of ACE, so I will stay at a relatively high level.
ACE works as follows.
The user who logs on to CRM is attached to a business partner with role “Internet user”. Joe and Jane both get created in your system as Internet users. Remember Joe and Jane are also SU01 users. ABC company and DEF are also business partners in your system, say with role “Channel partner”. The next step is to create a relationship between the two persons and the two companies. We can use the relationship “is contact person of” to tie them together. So Joe’s business partner id becomes a contact person for ABC company’s business partner Id. We then do the same for Jane and DEF company.
Each transaction typically has a list of partner functions that are applicable to it. This is where we tie a business partner in a particular role, to that transaction. Let us consider marketing campaign as an example. Both Joe and Jane needs to see the campaigns for which they are managing the advertisements.
There is an assignment block in Campaign screen in the webclient called “Parties involved”. This is where the system keeps a record of the business partners who have a role to play in the campaign. This is configurable using partner determination in CRM. Typical partners for a campaign include channel partners, employee responsible etc. Let us consider the campaign called “The Big Widget Campaign”, that has ABC and DEF companies listed as channel partners.
How does system check to see if Joe (or Jane) needs to see this campaign? When Joe logs in, system can find out that Joe is a contact person for the channel partner ABC. Joe has a PFCG role attached to his user master, that has a business role attached to it. This business role has a navigation bar profile that lets the user view campaigns. So Joe gets to search for campaigns.
At this point, the system checks to see if any of the campaigns have the same channel partners as the one that Joe is attached to, which is ABC company. System finds that ‘Big Widget Campaign” has ABC company as a channel partner. Since Joe is attached to ABC company, and since ABC company is a channel partner attached to “Big Widget Campaign” – Joe gets to see it.
I guess I don’t have to over emphasize that this is a more scalable approach. For starters, you can use the same business role, navigation profile and PFCG role for Joe and Jane, and any one else who needs to do the same things as these two people do. All you need to do is to make sure that you have a consistent master data set up.
So let us dig a little deeper into the ACE functionality
ACE is very flexible in nature – you can choose any characteristic to do the matching process in our example. Technically, ACE compares an “Actor From user” or AFU with an “Actor from Object”. If they match, the user gets access – if they don’t the user does not get access.
Now, ACE also can tell the system what kind of action can be performed – like create, read etc. However, these actions can be performed only if the user has the relevant basis authorizations to do this. In other words, ACE cannot over ride the basis level authorization.
SAP delivers several ACE rules as examples in standard delivery. You can copy and change them to suit yourself. Remember that the AFU and AFO we discussed above are nothing but ABAP classes. So you need to know ABAP to manipulate the logic of this determination.
What if one user needs to perform two roles?
Often times, one user might need to perform multiple roles in the system. Internal users get assigned to multiple positions in the hierarchy, and hence could choose from several roles. What about external users?
External users are not assigned to your organization hierarchy, since they don’t directly work for you. So in this case, the following strategy can be put to use, if they need multiple roles.
Let us consider the case where Joe needs to view a campaign, and create an advertisement, where as Jane needs to view the campaign, create an advertisement and also create a claim if she needs to.
The lowest common denominator here is that both Joe and Jane needs to view campaigns and create advertisements. We create a business role called BROLE1 that lets them do that, and attach a PFCG role called BASIS1 to it. Now, we assign BASIS1 to both Joe’s and Jane’s user masters. Now we create a business role that can create claims and call it BROLE2, and attach PFCG role BASIS2 to it. We assign BASIS2 to Jane’s user master alone.
When Joe logs on, system sees that he has PFCG role BASIS1, and hence gives him the BROLE1 business role. He gets to create advertisements and view campaigns. He cannot do anything else.
When Jane logs in, system sees that she has 2 PFCG roles – BASIS1 and BASIS2. System prompts her to choose between business roles BROLE1 and BROLE2. If she chooses BROLE1, she gets to create advertisements and view campaigns. If she chooses BROLE2, she gets to create claims, but cannot do anything else.
Performance aspects
Contrary to what one might think - ACE is not a big performance killer. ACE does not go through all the logic at run time. Once you activate the ACE rights, it prefills a set of tables with the information on what each user can do. All the system does is that – it looks up this table to see if a user has permission to do a particular action on a given object. If the look up is successful, and if the user has basis authorization to go with it, he or she can do the action (like view or create a campaign for example). If the lookup fails, the user cannot do the action.
A few parting comments
The way ACE works, you have to make sure that the user has ACE rights for all objects used in a context. For example, in a claim – a user has to choose a fund. User cannot create a claim unless he has ACE rights for both claims and funds. So be prepared to spend some quality time designing the rules and rights.
One last thing before I sign off – ACE is a CRM specific utility. It does not work, say in BI. So we need some strategies to make it work well with BI and other systems that an external system needs access to. Hey, that is another blog !
