Users, Roles, and Teams
The User, Team, and Role Management section includes topics covering working with and troubleshooting users, teams, and roles in Sugar.
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.
This article will cover the various ways to change passwords in Sugar.
You must be an administrator.
Administrators can create employee records. Users who are not administrators can view employee information, contact employees, and export employee information to their local machine. However, they cannot create or manage employee information. While
In scenarios where the ongoing security of your Sugar® instance must be ensured, an administrator may deem it necessary force a rotation of all user passwords simultaneously and outside of normal password expiration policies. This article will review the recommended procedure to carry out a system-wide rotation of all user passwords.
There may be times that 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 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.
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 accounts 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 Sugar licenses. This article covers how to create a basic report which helps system administrators track user accounts which count towards their purchased user total.
Roles control user actions on records, whereas teams control access to a record. 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 assigned to manage the record. Teams apply to every record in Sugar. All records are assigned to at least one team, and can be assigned to more than one team. For more information on teams and roles, please refer to the Team Management and Role Management documentation.
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.
This article walks through several role scenarios that illustrate what to expect when using team-based permissions.
Last modified: 08/31/2016 05:57pm