Thursday, April 9, 2015

SugarCRM 101: Security

The topic of data visibility and security is an important one, especially within the context of systems such as SugarCRM (Sugar) which are used to store information about our customers/clients.

Within Sugar itself you will find a set of sophisticated security features that permit administrators to control which users can access or see certain records, and secondly, given the ability to see a record, which actions can be performed on said record. These rules apply across all modules within Sugar, including custom modules, and effectively represent the two primary levels of security found in the application.

Often times, the features used to control visibility are confused with those used to control the actions the user can take on a record they can see. It is important to note that each security level is handled separately. Below we will look at each level and the related features within Sugar that allow us to define our security policy.


As data is entered into Sugar, two assumptions are made about an entry. These assumptions in turn help us control who will be able to see the record.

The first assumption is that there is a record owner, applied via the Assigned To field found on all entries. The second assumption is that there is one or more team assigned to the record, defined via the Teams field.

By default, Sugar will set the Assigned To value to match the name of the currently logged in user at the time a record is entered. This in turn translates to the point that the user that creates a record will, by default, be able to see the record. Of course, that assumes the user does not change the Assigned To value, which they are free to do.

The second assumption relates to teams. Out-of-box behavior in Sugar is such that when a record is created, it is automatically assigned to at least one team. That team is called Global and includes all of the users in the system. Thus, if we assume the team assignment is not changed, all users would effectively have access to all new records.

Much like with the Assigned To value, a user is free to remove the Global team or assign additional teams to a record. This allows us to extend or restrict visibility of a record. For example, removing the Global team from a record would reduce visibility to only those users that are members of the team(s) that do remain assigned to the record.

Should you wish to change the default teams that are assigned to a record at creation time, you may do so by way of a user profile setting. More information on User Management can be found here:

Information on the creation and general management of Teams is found here:

IMPORTANT: Do not delete the Global team as it may cause unexpected behavior.


Now that we understand the manner in which we can control which users can see a given record, let us discuss the manner in which we control the actions they can perform on a record.

The actions a user can take upon a record they can see are defined via Security Roles. Security Roles are rules that can be used to restrict actions on a record or on a field. Once defined, an administrator applies said rules to a user by assigning one or more Security Roles to the user. 

IMPORTANT: Sugar does not automatically assign any Security Roles to any of the users. In other words, user actions on a record are not restricted in any way by default. As an administrator, you should take immediate action to define the appropriate Security Roles and Teams in order to enforce your data security policy before allowing users to access the system.

Through the use of Security Roles, an administrator can control which users can perform a variety of actions, including deleting or editing records. If you wish to apply more granular restrictions, Security Roles further permit field-level restrictions. Lastly, administrators can also use Security Roles to control which modules can be accessed by the users.

Detailed information on Role Management can be found here:

Hopefully this helps clarify questions you may have had about the security model in Sugar.


  1. Hi Angel, I was wondering if you have or considering to post about the new Team-based Permissions features?

    Was particularly wondering in regards to when Account/Contact and related records visibility was setup so only assigned user (sales person) and their manager could view.
    As you probably know, once the need to assigning any of these accounts to a different user/sales person is required, it can get tricky.

    Although bulk assigning most records works fine, I can't see how that is done for emails and retaining history of actual user that sent these emails?

    Hoping you've come across this use case?

    1. I'll add it to my list of topics. Thanks for the suggestion.


Your comments, feedback and suggestions are welcome, but please refrain from using offensive language and/or berating others. Thank you in advance.