CRM Security and Access control - Total Enterprise CRM

• CRM Overview
  • Marketing
    • Email Auto Responder
    • Webforms and Lead tracking
  • CRM Accounts Link
    • MYOB / EXO Accounts Link
    • Quickbooks Accounts Link
  • Asterisk VoIP and CRM Integration
  • Document Management
  • Contact Management
    • Shared Calendar
    • Outlook Integration
    • Call Centre
  • eCommerce
    • Shopping Cart
    • Payment Gateway
  • Business Process Automation
  • Customisation
    • Custom Fields
    • Layout Control
    • Integration
    • Security
    • Workflow automation
  • CRM Security

 

Security / Access control in CRM

Security in CRM is extremely powerful to set up and gives a great deal of flexibility over who can see what data, and which screens.  Security Setup may look complicated, however any proficient “Power-User” will be able to easily understand the logical structure of the security system.

Key Concerts before you start

Before working with security, it is necessary to understand the key concept – roles. A “Role” is a group of permissions (access rights). Typically, you would create roles such as “Sales”, “Administration”, “System Administration”.   You would then add users to the Role, and the user will get all of the access rights of that role. You can access roles through the ADMIN menu. A “Group” is a group (or team) of users.   For example, you may have a role “Sales Team” which defines what sales people can see, but you may have several groups of salespeople (e.g. Australian Sales, NZ Sales, North American Sales) you want to collect together. Using Roles and groups lets you very flexibly change access permissions for lots of users quickly and centrally.

Setting up and testing roles

The simplest (and least disruptive) way of doing this is to first create your role name, in our example “Sales Team”). Then, create a group called “Test Sales Group”. In the “Security Roles Assigned” section, right click and add the security role “Sales Team”.

Note – it is possible to assign multiple roles to a team, however, this is not recommended as it makes it difficult to see which permissions have been withdrawn from a user.

Create a test user

Create a test user, and assign this user to the Test Sales Group.   This will make them a member of TEST SALES GROUP, giving them the access rights of the “Sales Team”.

• It is important to create this test user to avoid accidentally locking yourself out of the system.
• Do not change permissions on the “Admin” account
• Do not change permissions on the accounts used for CRM Services to log on.

Basic Permissions

Now we have our test user, we can change some of the permissions in the ROLE to see the effect.

Open the Role “Sales Team” and expand out “MetaData Sources” – you will see a list of every datasource in the system.  Since almost everything in TECRM is configured, rather than hardcoded, even the main menu can be found here.   Locate the contact form:

There are 4 sections that can be adjusted.  Not all of

Browser

View Rule

The view rule can be set to:

• All Records  (every record in CRM)
• My Records (Records that are assigned to me)
• My Team Records (records that are assigned to any user in your GROUP)
• My Company records  (This is used in advanced cases only).

New Rule

The “New Rule” controls whether or not the user is allowed to create a new contact.  If no value is selected, permission is assumed to be granted.

Edit

The “Edit Rule” controls whether or not the user is allowed to edit a contact.  If no value is selected, permission is assumed to be granted.

Delete

The “Delete Rule” controls whether or not the user is allowed to delete from the browser.  If no value is selected, permission is assumed to be granted.

Split

“Split” controls whether or not the user is allowed to access “Split View”.  If no value is selected, permission is assumed to be granted.

Copy

The “copy” controls whether or not the user is allowed to duplicate a contact.  If no value is selected, permission is assumed to be granted.

Popup Menu

This expands out to list many popup menus, and can adjust whether or not the user can see it (default is Allowed).

Editor

The editor menu controls what is accessible on the Editor screen (in this case, editing or creating a contact).  This exposes a list of all of the visual controls on the form, allowing two key properties to be set:

• Visible – the item is visible on the screen (default = yes)

• Enabled – the item is enabled for editing (not greyed out) – again, the default is yes.

You can use this section of the Role configuration to either hide fields for specific users, or make them inaccessible.  For example:

• Set the “enable” property on “Assigned To” to “Deny”.
• Restart CRM and log in as the testuser.
• Create a new contact, and you will see
• Re-open the role, and set the “Visible” property on “Assigned To” to “Deny.
• Restart CRM and log in as the testuser
• Open the contact you just created, and you will see:

Fields

The fields menu controls which of the fields are visible in the browser grid.  For example, if you do not wish your sales team to see account balance related information you can suppress the display of those fields here.

Ribbon Commands

The ribbon commands section grants you control over which ribbon commands (and tabs) are accessible to this user.  It is important to note that the commands are grouped by datasource and not by screen.  That is to say – the Contact datasource can add buttons onto many forms (for example, on the main form, on the company form), see the example below:

This relates to the “Company Activities” group on the Company form (“General Tab”).

Lastly – it is possible to hide individual tabs:

Controlling the main menu

The main menu is just another datasource.   To control the display of the main menu in CRM, simply navigate to the “Mainform” datasource:

If you wanted to hide the admin tab, it is as simple as clicking “Deny” on the MainForm-Admin node.