About CRM Access

The CRM Access control is designed to work on top of IFS Applications company and site access. It is limited to objects that is more relevant for a sales representative and the purpose is to give the ability to prevent users from seeing other user’s records, e.g. business opportunities, activities and leads. Note that it is not a completely comprehensive customer access filter.

CRM Access is set via a combination of filters and user groups. A filter controls the access for one or several objects in the application like Customers and Business Activities. A user is connected to one or several groups and groups are connected to one or several filters. What privileges a particular user receives depend on the privileges defined for the group for that filter. Read, Insert, Update, Delete, and Share are the privileges that can be allowed for per filter.

Privileges

The level of access to a record is decided by "privileges". A representative always has read access to his/her own records. For each filter the main representative and other representatives can be given other privileges. Users in the same access group as the record representative can have a different level of access than the representatives.

Available privileges (access levels for a group) are:
Read – View record
Insert – Create a new record
Update – Change information and save
Delete – Delete a record
Share – Give access to other users, see Share records section below

Child Insert – Insert a related child record, e.g. invoice
Child Update – Update a related child record
Child Delete – Delete a related child record

The privileges are set in combination of Access Filter and Access Group and then Representatives that belong to a group can, if configured, share access to filter records to other group members. E.g. a group of representatives can have read access to a customer and read and update access to a sales quotation.

The representative can be configured to share record access with his/her group members or not. In this way one user can share for example customers with the group while another has access to the group’s customers without sharing access to his/her own customers.

How and what privileges are shared and with whom is administrated in CRM Access Group.

Access basics

CRM Access is based on representatives. A user who is representative for a record has access to that record. Other users who are members of the same Access Group as the representative can also get access to the record. It only applies to users who are included in one or more Access Groups, users who do not belong to a group are not affected by restricted access.

There are several ways to get access to a record:

Example of a group member getting access from a customer representative:

Representative ALAIN has full access, all privileges, to customer 1000 by his connection as representative. ALAIN is member of the same access group as DAMON and has been configured to share records in the access filter Customer with Read privilege. As a consequence DAMON can see customer 1000 but is not allowed to for example update information.

Filter basics

An Access Filter defines a subset of records for an object. What records that are shown for a representative is related to the record representative. Within CRM Access there are filters for the following objects:

For objects that have representative information, the filter will show records where the user has been added as a representative or is member of a group together with a representative that shares his/her access.

For objects that do not have related representatives, like customer address, the access will be inherited from the parent object, in this case customer. E.g. if the user has access to a customer then he/she will have access to the customer’s addresses. If the user has Update access to the customer then he/she will be able to insert, update and delete customer addresses.

There is a difference between child objects that have been defined to “belong to” a parent and objects that “relates to”. In the above example customer address belongs to customer and the access level comes from Update privilege for the parent. Other examples of child objects that belong are order information for a customer and sales quotation lines for a sales quotation. Invoice on the other hand is defined as an object that relates to customer. If we use customer as an example the general rule is that information in the customer window belongs to customer while other information, like customer agreements, relate to customer. You can set access level for related child objects separately, the access is set for ALL child objects related to the parent. Privileges that affect child objects are Child Insert, Child Update and Child Delete.

Other examples of the difference between belong and relate:

An Access Filter is enabled to restrict users to subsets of data. To circumvent this for a user and at the same time give her/him specific privileges it is possible to designate admins per filter. Access Filter admins have access to all records in the filter but can have different levels of access. One admin user can have full access to all customers while others can have read privilege. Admins are defined per Access Filter.

Some records for objects with representatives, e.g. Customer Order, might not have any representatives connected that can qualify them to a subset and make them visible. It is possible to include those records in all subsets by configuring the Access Filter to include records without representatives.

Filter inherit

Instead of having separate access level for a filter it is possible to configure it to inherit access from the parent. As an example; a representative can have the same access to a business opportunity as he/she has for the parent customer. Parent filters are Customer, Business Lead, Business Mail and Marketing Campaign; they cannot inherit access since they are top level parent objects. Customer Contact, Sales Quotation, Customer Order, Business Opportunity and Business Activity can be set to inherit privileges in order to reduce administration.

Record share

In addition to access based on record representatives it is possible to manually share a specific record with other representatives. A representative that has Share privilege to a record can choose to give access to another representative and give him or her Read, Update, Delete and/or Share privileges to it.

It is also possible to share a record to whole access groups.

Note: When a record is shared to a representative/group, if that representative/group does not have access to the parent (Ex: Customer), a message will be prompted. This message will give user to grant ‘Read’ privilege for the parent record and continue with sharing.

Access tabs

Objects with representatives have a tab called Access where it’s possible to see all users that have access to the record.

In the sub tabs it is possible to see representatives and groups that have access to the record and also if the record has been shared to additional representatives. The sub tab All holds a complete list of representatives that have access and their privileges as well.