CRM/SFA Application Security

This is a technical document which describes how security in the opentaps CRM/SFA application
works.
Change Log

May 12, 2006 More details about how security actually works
May 4 2006

Updated for opentaps 0.9

2006 Open Source Strategies, Inc. All Rights Reserved.

Page 1 of 3

CRM/SFA Application Security

How Security works for CRM/SFA Application
The security model for the CRM/SFA application is slightly more complex than that for other
applications. As with all the other applications, each screen and each operation is associated
with a security permission. These security permissions are grouped together into security
groups, which are then associated with a user login. When a user tries to perform an operation,
the system will check if his/her user login has the requisite permission. (For more details, see
http://www.opensourcestrategies.com/ofbiz/security.php)
In addition to this standard security scheme, the CRM/SFA application uses a security group
which is associated with the relationship between two parties, such as between an account and a
team member. (TECHNICAL NOTE: This is stored in the PartyRelationship.securityGroupId
field.) Thus, if the user does not have a permission associated with his/her user login, the
CRM/SFA application will then check if that permission is part of the group associated with
relationship.
In the CRM/SFA application, when you set the role for team members at the bottom of the
Account screen, you are actually setting the security group. An entity called
SalesTeamRoleSecurity masks these security groups into role descriptions, and the CRM/SFA
application will only presents the security groups defined in this entity. When you create teams in
Party Manager with the [Relationships] tab though, this entity is not used, so you will see all the
security groups in the system, including those for accounting, content, ordermgr, and so forth.
Customizing Security Permissions
By default, the CRM application has several SecurityPermissionGroups defined (see
data/CRMSFASecurityData.xml). Each SecurityPermissionGroup points to a list of
SecurityPermissions which control specific operations. To customize security permissions, you
can change them in the Party Manager by going to [Party] > [Security] >> [Security Groups] tab
and add or remove specific permissions from a group.
We recommend that you use the permission groups in the following way:
1. Use SALES_MANAGER as a manager permission
2. Use SALES_REP as a full account team member permission
3. Use SALES_REP_LIMITED, SALES_REP_TRAINEE, and CSR as permissions for team
members when they are not assigned to any particular account.
Only remove permissions which start with CRMSFA_. The PARTYMGR_ and ORDERMGR_
permissions are required to allow the users access to general OFBiz services. As long as the
user does not have PARTYMGR_VIEW or ORDERMGR_VIEW, however, he/she would not be
able to get into the OFBiz applications and perform those operations outside the bounds of the
CRM/SFA application. (The other possibility is if you expose some of those services as web
services, the CRM/SFA users passwords could be used to activate them.) Removing them could
cause unexpected effects.
OFBiz Security
If you would like to give your users access to the back end OFBiz applications, you would need to
give them OFBiz permissions. By default, users have permissions in the Order and Accounting
applications. You can edit them in the CRMSFADemoOFBizSecurity.xml file.
Users who wish to work with quotes would also need permission to access the OFBiz Order
Manager.
The system user
2006 Open Source Strategies, Inc. All Rights Reserved.
Page 2 of 3

CRM/SFA Application Security

The OFBiz system user is associated with some permissions for tasks that are automatically
performed in the background by the system. This user cannot be used to log into any application.
In the CRM/SFA application, the system user is given the permission for updating all forecasts
when opportunities are updated.
Activities: Tasks and Events
To create tasks and events requires CRMSFA_ACT_CREATE permission. However, if the task or
event is to be associated with a party, then CRMSFA_ACCOUNT/CONTACT/LEAD_UPDATE
permission for that party must also be present. This can be assigned generally to the user, such
as a sales manager, or specifically through a particular relationship (team or owner.) Similarly, if
the task or event is to be associated with a case or opportuniity,
CRMSFA_CASE/_OPP_UPDATE permission must be there for that case or opportunity.
Cases
To create/update cases, user must have CRMSFA_CASE_CREATE/_UPDATE permission
through one of the parties involved in the case (account or contact.) We require that each case
must be associated with at least one party.

2006 Open Source Strategies, Inc. All Rights Reserved.

Page 3 of 3