Users, Roles, and Teams
The User, Team, and Role Management section includes topics covering working with and troubleshooting users, teams, and roles in Sugar.
Topics
A user's default team designation enables Sugar® to automatically assign the specified team(s) to the user's newly created records. If the user's default team is set to their private team, then all new records will automatically be assigned to the private team and only viewable by the user, the administrator, and the manager to which the user reports (if applicable). This article will cover how to change a user's default team and how to remove existing default teams from your profile page.
Depending on the system's password configuration settings, and whether your instance is SugarIdentity-enabled, users may have the option to change or reset their Sugar password and system administrators may be able to update or reset the user's password as well. This article covers the various ways to change passwords in Sugar. Please reach out to your system administrator if you need assistance with changing your password.
You must be an administrator.
There may be times where you need to deactivate user accounts in your Sugar® instance such as when the user is no longer an employee of the company. Administrators should try to avoid deleting obsolete user accounts to ensure that any historical data remains intact. This article covers how to mark obsolete user accounts as "Inactive" and reassign the inactive user's records to another Sugar user. For more information on administering user accounts, refer to the User Management documentation.
Roles are used to control access to modules and the fields within those modules. Users belonging to a particular role will have the ability to access increased or reduced functionality depending on the module- and field-level changes made within the role. By default, users who are not assigned to a role can access and perform actions in any enabled module.
Role Management gives Sugar administrators the option to set module-level and/or field-level permissions and access for users. One such option is to make a particular field "read-only". Making a field "read-only" ensures that users assigned to the role can see the field in all views but are not able to modify it. This article covers how to create a role in order to restrict a user to have read-only access to a field.
Your Sugar subscription includes a set number of user seats who have access to the application. There are various types of users in Sugar: System Administrator User, Regular User, Group User, and Portal API User, but only active system administrators and regular users count towards the number of purchased seats. In Sugar versions 8.1.x and higher, there is a stock report that helps administrators track the number of active users counting against their Sugar license. For more information, refer to the Licensed User List report in the Stock Reports documentation. However, if using a version of Sugar lower than 8.1.x, or if the report is not available to you, this article covers how to create this report manually.
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.
Non-admin users are unable to access a module possibly after an upgrade or after the module has been deployed from Module Builder. The following error message is displayed when trying to access the module: You are not authorized to access this module. Administrators are able to access the module as expected.
Occasionally a user may report that they are unable to access Sugar records. This article covers some of the troubleshooting steps you can apply to pinpoint the reason why this is not working as anticipated.
System Administrators can configure roles with various access types for Sugar modules. The role's access type for a particular module determines how much control users in that role have over the module. The Access Type column may be set to Normal, Admin, Developer, Admin & Developer, or Not Set. The Not Set option is effectively the same as the Normal option except when a single user belongs to multiple roles. This article explains the difference between the capabilities of an Administrator user and regular users who have Admin, Developer, or Admin & Developer access type for roles.
Sugar contains a Users module accessible by administrators and an Employees module accessible by regular users and administrators. While they are similar, they are not the same. This article explains the difference between these modules.
This article walks through several role scenarios that illustrate what to expect when using team-based permissions.