Roles vs Teams

Overview

A role defines a set of permissions to perform actions such as viewing, editing, and deleting information. You can control user actions by restricting access to modules and module fields to users who are assigned to certain roles. Teams provide data security because users can access a record only if they are members of a team that is designated to manage the record. Teams apply to every record in Sugar. All records are assigned to at least one team and can even be assigned to more than one team.

Roles control what users can do by restricting a user's access to entire modules or changing their access rules for entire modules. Roles are commonly configured to correspond with the types of users that will be accessing Sugar (e.g. Support Agent, Support Manager, Sales Rep, Sales Management). For example, you could create and configure a "No Opportunities" role for the users in your Support department to prevent those individuals from being able to access the Opportunities module. A second role, "Owner Opportunities", could be created for the Sales users to allow them to only see their own opportunities. It is even possible to create a granular role that allows users to access only some of the details on the opportunity records owned by others, such as hiding the account names while exposing the dollar amounts. For more information on the nuances supported by roles, refer to the Introduction to Roles article.

Teams control what users can see by regulating record visibility in the modules that their role can access. A user and a record must share a team in common in order for the user to be able to see and interact with the record. For example, records assigned to the default Global team can be accessed by any user (as long as every user belongs to the Global team, which is the case by default). If a record belongs only to teams East and West, then a user belonging only to team North would not be able to access it. Users can belong to many teams. Teams can be organized according to departments, geographic regions, or whatever else works best in a given organization. Commonly, customers will create teams that correspond with their existing territory structure or business center model.

Please note that this is a general overview of teams and roles and there may be exceptions to the rules as you learn more advanced methods of configuring teams and roles. For more information, please refer to the Team Management and Role Management documentation.