At the customer we use Oracle Incentive Compensation (OIC). OIC is used to compensate external partners. These partners are maintained in CRM foundation. The partners are set up as salesperson. Salespersons can be used inside OIC.
The customer has two operating units. In CRM for each operating unit, the salesperson must be set up. So if you had setup the salesperson in operating unit A, then there’s not yet a salesperson in operating unit B.
The problem in CRM foundation is that it is possible to change information of operating unit B, while you’re using a responsibility that is assigned to operating unit A. If you change information of operating unit B, using the responsibility for operating unit A, the relation in the database will be made with operating unit A. So for example you changed a role that is used in operating unit B this will be related to the salesperson of operating unit A. This causes inexplicable errors. On screen everything seems ok, but somewhere hidden in the database there is a wrong relation.
We have been looking a long time for a solution within the setup of the responsibilities or setting profile options. Nothing of this worked out, so we decided to use personalizations. Fortunately for me a colleague is experienced with personalizations.
We had to decide which information is operating unit specific. Each operating unit can have multiple roles, but a role is always assigned to only one operating unit. So we could use the roles to prevent the problem. To give the role information to make it operating unit specific we had to setup a descriptive flexfield, which will be filled with the organization code of the specific operating unit.
Now was the question where to setup the descriptive flexfield. We could choose for the roles tab in the resource menu, but then it must also be setup at the tab groups. And it should be filled for every partner. So we have chosen to set it up in the roles menu. The information only has to be filled once, only during creation.
Now we only had to make a personalization to make sure that the role only can be changed when you’re using the right responsibility.
Before you can create personalizations a profile option must be set at user level. Query for the profile option: Utilities:diagnostics. Set the option to Yes at user level.
Now you can go to the CRM foundation and open the resource menu. Via the path Help → diagnostics → Custom Code → Personalize, you enter the personalizations menu.
Here you can create the personalization(s).
We created six different personalizations to prevent the problem. First three for the roles tab, then three for groups tab. For the roles tab we created a personalization to prevent updating or deleting information if you’re using the wrong responsibility. The second personalize is to allow updating and deleting information if you’re using the right responsibility. This one was needed because after the first it wasn’t possible at all to update any information. The last personalization is to prevent that the user add a role using the wrong responsibility.
These personalizations are the same for roles tab and groups tab. They are only differentiated by the block that triggers them.
Now I’m giving you one example of a personalization we made. This personalization will show an error message.
The trigger event for this personalization is ‘when-validate-record’ and the trigger object is roles. So as soon as you try to save something in the roles block, this personalization will be checked. What it will check is defined in the condition:
(:RESOURCE.SALESREP_ORG_ID not like (select attribute1 from jtf_rs_roles_b where role_id = :ROLES.ROLE_ID) or (select attribute1 from jtf_rs_roles_b where role_id = :ROLES.ROLE_ID) is null) and :ROLES.ROLE_RELATE_ID is NULL and :RESOURCE.CATEGORY not like 'EMPLOYEE'
The notation :RESOURCE.SALESREP_ORG (where the information after ‘:’ can change) indicates that it is information on the screen and not information in the database. You can find out the naming of the fields using the examine functionality (Help → Diagnostics → Examine).
The condition simply says: if the salesrep_org_id on the screen (not visible) is not the same as the org_id of the role (declared in attribute1) and it is a new record (role_relate_id is null) and the employee_category is everything else then Employee, this condition will give as result true. True is meaning do something.
This ‘do something’ is defined on the actions tab. The type is message. The message type for this personalization is Error. Error means that there will be shown a message and there will no insert or update in the database. One of the other possibilities is Show. Show means show a message and save the information in the database. But for now, thus an Error.
The error message says: you’re using the wrong responsibility, please change to the proper responsibility to setup this information.
Because of the personalizations all information in the database is related to the right salespersons. In OIC we don’t have any inexplicable errors anymore.
Beside the six personalizations to make sure that the information is changed or added using the right responsibilities we created more personalizations. Just to make sure that the users use the CRM foundation like we wanted them to.
Further we made some personalizations to make the life of the users easier. We fill some information automatically for them and some tab pages we don’t use are not visible anymore.
Off course it is very important to write good documentation about the personalizations that you made.
Creating these personalizations was for me very instructive. When creating a personalization succeeds, this gave me a proud feeling. So try it out yourself. If you have a question about personalizing, feel free and react on this post.