Notice of Maintenance on October 9th. Click here for further details.

Sage CRM and Row Level Security

3 minute read time.

Sage CRM has a very powerful set of security mechanisms to guard access to data.

  • Row Level Security using the idea of Territory and Security Profiles.
  • Field Level Security which guards Read, Write access to individual fields on screen and in reports.
  • Company Team security which guards access to tabs within the Company Context.

A combination of all three can implement the even the most demanding of security policies. And tweaking of the interface can be added using Create Scripts.

For background about Security please see these other articles

But using the Security mechanisms can seem complex at times. But the problem can be broken down into smaller parts. The only security rights that exist are Delete, Insert, View and Edit. And although it seems logical that some rights may assume others... for example Insert may assume View, this is not strictly the fact. It is possible to insert a record and assign it to another and then not be able to see it.

Fine Tuning Row Based Security

We can fine tune the Row Based Security by considering the following questions

  • Is the Entity in the same territory as the User? Or is the Entity in a territory that is 'under' the User's?
  • Is the Entity in a territory that the User has been given rights to through their Security Profile membership? (This can be explict, so the name of an absolute
  • Territory, or implicit through Sibling or Parental rights.)
  • Is the Entity assigned to the User?
  • Was the Entity created by the User?
  • Is the Entity assigned to the same Team (channel) as the User?

Consider the following scenario based on the default demo data.

Scenario

A customer has 2 sales users. Matthew Ebden and Peter Johnson. These two users in the demo system are in the UK territory and in the Direct Sales team (Channel). They also share the same User Security Profile 'Sales Rep'.

Using the demo data system logon as Matthew Ebden (EbdenM). Navigate to the Find screens and find all companies. You will see that the user EbdenM can see 732 companies. These are all in the UK territory. Next search for the Company "Accantia".

You can see from the image above that EbdenM is allowed to see this company because he is in the UK territory. The system is using the concept of Company Team membership to guard EbdenM's access to certain information behaind tab that have been marked 'sensitive'.

But what if we want to say that EbdenM should not be allowed to see this company at all.

This can be achieved by the System Administrator very easily.

Logon as 'Admin' and navigate to

Administration -> Users -> Security -> Security Profiles

Edit the 'Sales Rep Profile' and remove the 'View' right for the User's Home Territory for the Company entity. Save this. Then logon again as EbdenM.

Navigate again to the Find screens and find all companies. You will see that the user EbdenM can see only 262 companies now. These are all in the UK territory that either are assigned to EbdenM or EbdenM originally created. He now has no access to the Company "Accantia". Logon as 'JohnsonP' and you will see that this user has rights to view and edit the company 'Accantia'.

This illustrates very clearly that you can mixed the rights very precisely to obtain the access to rows that you need.

Developing the Scenario

What if the customer has two users who need to access 'Accantia'? Here we need to go back to the orginal questions that I asked above in the section 'Fine Tuning Row Based Security'. If there is a group of users who need to have rights over a record then we would need to consider the Team (Channel) membership and the Territory structure.

  • Could you use this method to hide the record entirely from all but select users?

  • One note on this very good article is that Company Team will prevent access to the data tabs marked sensitive, Communication, Opportunities etc. In other words a user must be on the company team to access the tab data which is controlled by the users security setting as Jeff said. But another method to control tab data is through the use of SQL in the Administration -> Customization -> Company | Tabs area. Its helpful if for example a specific need to control data release, example might be perhaps by Team User_primaryid = 4 then direct sales has the tab access or User_Userid = 1 for example would give only the Administrator. Sometimes its preferable to use instead of using the "sensitive" setting on Company team, because that setting is either on or off. Also, instead of deleting the tab its sometimes better to just "hide" it. I demonstrate SQL for report groups under menus as well, because SQL allows the idea of releasing a report to a specific user as well as viewing tabs.

    Bruce Holmes