CRM systems usually have a lot more users logging into it, and these folks typically need to see different content once they are logged in. When designing the CRM implementation, a lot of care needs to be taken to ensure that the result caters to all business, technical and security concerns.
Depending on the size of the project, the number of users and the complexity of the organizational units – the complexity of the situation can be really high. Also, the strategies we can consider will differ depending on whether it is a new implementation on CRM2007, or if it is an upgrade from a previous version.
Obviously, we need to make a start somewhere. And a good place to start is getting a list of users that exist in your system – both internal and external. Once you have a list, make sure you segregate them into Internal (like employees) and external (like contact persons for your business partners).
In this blog, I plan to discuss strategies for internal users. We can consider external users in a following blog.
Depending on your existing implementation – you might have already mapped all internal users to business partners ( typically with with role employees ), and assigned them positions in the hierarchy. Go to transaction PPOMA_CRM and see if this is the case.
The simplest form of assignment is
Organization -> Position->User
A more reasonable way to do it is
Organization -> Position->business partner->User
Note that a business partner can be assigned to multiple positions.
An important consideration here, especially if you have an HR implementation that is feeding employee data into CRM is to check if your marketing organization is modeled correctly in HR. Most often, Marketing or sales might have a organization that is very different from how HR views its data. Now we have a choice to make – typically from the following choices.
- Should we use the HR hierarchy?
- Should we create a marketing organization from scratch (maybe using a replicated organization from ERP), and assign employees according to how marketing views data?
- Should we try to work around the issue by not assigning employees to an Organization?
Once we answer this – we can end up with one of two situations – Either we have an organization hierarchy with positions and business partners attached to it(if we pick 1 or 2 above), or we do not ( we picked 3). Remember that we still need one an organization either way – the only difference is whether we actually assign business partners and/or users to it.
Scenario 1 :
First let us discuss the scenario where we choose to assign positions to the organizations and business partners and/or users to these positions.
Why do we need an organization so badly in the first place?
Well, SAP uses organization for several different things, and assumes that all companies will have at least one organization that can be mapped to the system.
Typical uses of organization include
- Partner determination – A very useful partner function called ‘Employee Responsible” can be determined by who is assigned to the Organization.
- Organization has a lot of attributes – like language, country, sales org etc that can be used for defaulting values in transactions.
- Organization in CRM can be used for determining the company code via account determination etc, like in the billing engine.
- Organization can be used as a security mechanism to provide basis authorizations.
- Organization is very useful in Analytics as a filter.
In short – don’t try to avoid using an Organization!
Everybody needs a ROLE
So, your users now have a position in an organization – good start, but we are nowhere near done. But, how did you decide on the positions? The simplistic answer,in our current context, is that the position should dictate what the user can do. Example: A user attached to the position Channel Manager, should be able to see marketing campaigns.
SAP will let you assign one business role (technically an infotype) to a position. All users assigned to the position inherit that business role.
What does the business role contain? It contains several things, and we won’t go into great detail on everything it contains. The two important aspects we need to know for now are that each business role will contain exactly one each of
- A Navigation bar profile
- A PFCG role
The navigation bar profile
The navigation bar profile is the one that decides what content the user can see. Even if the user has SAP_ALL profile in basis level, if the navigation bar profile only has a work center for Campaign management, the user can only see Campaign management in the webclient – simple as that!
If a user has a business role, but does not have the corresponding authorizations in basis – what happens then? In this case, the user cannot use anything that the navigation profile. The reason for that is that authorization checks happen at the level of programs, and they will get triggered if the program runs. This is a very useful safeguard, and should allow the security guys in your company to sleep peacefully without worrying about unauthorized access. We will discuss the role of ACE (Access Control Engine) in a later blog, but I want to mention here that ACE also cannot over ride basis authorizations. Basis level authorizations reign supreme under all circumstances!
The PFCG Role
Now let us talk about the PFCG role. This is the same PFCG role that has been around from the beginning of time. In the SAPGUI world, PFCG – in addition to being used for profile generation, was also used to restrict the transactions that a user could execute. In the new webclient world, the business role (via the navigation profile) has taken over the role of what transactions a user can do on the webclient. However, the profile generator is still left in PFCG.
At this point – we need to consider some aspects of your existing implementation on the security side. You probably have a lot of PFCG roles that are already present in the system. You have to take a decision on what you want to do with them. Also, you might have invested in an external tool that creates users in SAP and assigns roles to them.
So let us discuss how best you can leverage what roles exist in your system already.
There are two ways that you can assign authorization profiles to a user. The commonly used approach is to put all required authorizations in a set of PFCG roles, and attach the PFCG role to the user master. This assignment can be done through PFCG itself for several users at a time, or you can edit a single user using transaction SU01 and add the role manually. The other way is to go to SU01 and directly assign profiles to the user master.
SAP provides a nice utility to generate all the required profiles for a given business role. This is done via the two reports CRMD_UI_ROLE_PREPARE and CRMD_UI_ROLE_ASSIGN. If you are starting from scratch, this is probably the best way to go forward. Create and assign a PFCG role for your business role through these two reports.
Now let us consider another scenario that might be useful when there are lots of existing roles in your current CRM implementation. First, we need to make sure that the existing roles contain all authorizations needed for webclient. Now, as long as the user is assigned to a position that has a business role – all is well and the user can do everything that his business role mandates.
Point to be noted is that – the PFCG role attached to the business role need not be the one that the user master has. As long as the user has authorization to do that, via any PFCG role or profile – things will work just fine. Just remember to put some role attached to the business role – even an empty role will do.
This latter approach of using existing roles might ease the pain of getting on to CRM2007, and probably will cut the time needed to cut over. However, I would like to state here that if you are headed down this path – make sure that you plan to move to a lesser number of PFCG roles (using the role attached to the business role) in the mid to long term. Lesser number of roles will make your security management more streamlined and efficient.
So, in summary – this is what is happening in scenario 1.
You have an organizational hierarchy in place, and it has positions (with business roles attached) and business partners and users attached to it. When a user logs on, system finds all the positions that he/she has been assigned to and figures out the business roles attached to these positions. Then, the system prompts the user on the webclient to choose one of the roles. Once he has chosen a role – he gets access to everything in his navigation profile. If the system determined a unique role, then user doesn’t have to choose a role (SAP is smart) and will directly go to the homepage in his navigation profile.
What if you can’t make the org hierarchy work in your project as described above?
You might be in a situation where there the whole organizational hierarchy and positions etc are not working out very well for you. This calls for some outside the box thinking. I would urge you to consider all options of making the organizational hierarchy work, before you head down the following path. You lose a lot of nice standard functionality, and might end up writing a good bit of ABAP code (like BAdIs), by not using the org assignment.
Any way – here is one approach that will technically satisfy the necessity of associating a user to a business role, when no organizational assignment exists.
- As usual, create a business role and attach a PFCG role to it.
- This PFCG role can be an empty role, as long as the user has other PFCG roles or profiles that will satisfy the authorization needs.
- Edit the user master ( using SU01 or directly through the PFCG role ) and attach the PFCG role ( which was assigned to the business role in step 1 above) to it.
- Repeat steps 1 to 3 for all business roles that the user needs.
Remember that in this situation, the user is not attached to a position and hence the system cannot figure out a business role (or roles) as it did in scenario 1.
So let us see what happens when the user logs on. The system finds out that the user has no org assignment. So it does a reverse search. System looks at all the PFCG roles attached to the user master. It then finds out if some of them have been attached to business roles. (remember that a business role always has a PFCG role, and a PFCG role cannot be used for more than one business role). If the system finds multiple business roles in this search, it asks the user to choose one from the list. This parties similar to scenario 1. Also, if the system found only one hit – the user doesn’t have to make any choice, and is directly presented with what the navigation profile mandates.
In parting, I would like to say that these are probably not your only options – and I would love to hear from the community members on what you think will or will not work in their project scenarios. Let us discuss this and learn from each other. I do hope that this blog is useful to those of you who are just getting into CRM2007.
In the next blog, we will talk about the other half of users – the external ones.