A staple role for a Sugar Administrator is the user management within the system. The Admin is responsible for adding and deleting users, managing passwords and login capabilities, and assigning roles and teams appropriately. So, what are the best practices for user management in Sugar? Our SugarCRM experts laid out their recommendations in an online user group. This is a summary of what they discussed.
Best Practices for Managing Passwords
When it comes to managing passwords in Sugar, an Admin has some flexibility. The system comes equipped with several built-in functions that can help with password generation, resetting passwords, and single sign on functions. Depending on your Admin preferences, you can allow users to generate their own passwords in the system or force them to use system generated passwords. System generated passwords tend to be more secure. However, Sugar does offer the option to set requirements for specific characters/numbers/capitalization preferences that the Admin can take advantage of to help users create more secure passwords.
Regex codes, which specify words or strings that are not allowed in the password, can also be set by the Admin. For example, you may want to restrict your teams from using the word “Sugar” anywhere in their passwords. The Regex capabilities enable this type of restriction.
Regardless of which type of password administration you use (system generated vs. User generated), password expirations can be set to expire. This is particularly useful for short term project management. If all users begin the project with same password, the Admin can set a password expiration for when the project concludes. A word of caution: be careful with password expirations if you have integrations that rely on a Sugar user account password. Be sure to check with your management and team members before implementing the forced password changes. If a user forgets his password, he can bypass requesting a new one from the Admin if the “Forgot Password” tool is enabled.
Single Sign On
Sugar supports single sign on (SSO) through LDAP or SAML, which allow the system to talk to Google, Microsoft Active Directory, and even third-party software like Okta to retrieve the information. If you use Microsoft Outlook for email, be aware that the plug-in does not currently support SSO. However, Sugar is beta-testing solutions for this, so we hope to hear news of new capabilities soon.
Best Practices for Adding & Removing Users
Employees come and go. Contractors and freelancers may need temporary access to a system. An Admin must know how to add and remove users and have a plan for getting new users up to speed. Best practices tips for adding users include:
- Keeping a consistent user name format: Stick to one style of user name to avoid confusion and data discrepancies. For example, maybe the format you use is first name.last name. When a user comes to you asking about her user name, you’ll know immediately without having to look it up because it’s consistent and easy to remember.
- Limiting System Administrators: Too many Admins is a recipe for disaster. Think about the size of your organization and the number of users. Is the number of Admins justified?
- Specifying “Reports to” in Sugar: Sugar user profiles contain a field called “Reports to” where the Admin can specify who that user’s manager is by linking to the manager’s profile in Sugar. This is helpful for the manager if they’d like to easily create Reports of team member actions, or to trigger workflow notifications when a team member performs a certain task.
- Setting appropriate Teams/Roles: When you add a new user, remember to assign the new user to the appropriate Team/Role and assign the user’s Default Team after updating Team memberships.
- Having a training plan: Who will be responsible for training new users? Do you have recordings from old training sessions? How-to documents? What do you want that process to look like?
- Updating Assignments of Existing Data: Is this new employee fulfilling a vacancy for someone who has recently left the company? Their valuable data is left behind and should be transferred over to the new user to help them get started.
There are a few key best practices to remember when removing users. The most important? NEVER DELETE A USER! There’s no reason to delete users. When you remove a user you risk breaking links related to that user (notes, emails, cases, etc.) that can affect other data and other users. Change the user’s status to inactive instead and Sugar will prompt you to reassign the user’s records if you choose. An alternative way to reassign the data involves creating filters in a list view, selecting all relevant results, and performing a mass update. Reassignments too complex? Use a third-party tool (we recommend StarfishETL) to query the data and make determinations about where to move the data that way.
Best Practices for Managing Teams & Roles
Two of the most important best practices to keep in mind here are things you should NOT do:
- Do NOT delete private teams
- Do NOT delete users from private teams
As mentioned in the removing users section above, any time you delete information from the system, you are potentially jeopardizing data related to those records. Sugar automatically creates private teams for users and deleting them can cause buggy and bizarre issues in the system. Adding users to a private team is OK.
If you need to assign multiple roles to a user, be aware of what the outcomes of that could be. If one role says the user can do something and another says they cannot, Sugar will default to follow the most restrictive role permission (aka not allowing the user to do said thing). Only set permissions that are necessary for the role. If the permission is unnecessary, simply leave it in a “not set” status to avoid over complication.
When adding users to a new role, keep in mind the roles they are already in. Should they be removed from any of these roles now that you’re adding the new role? Does the old role still apply? It’s best to avoid layering roles when possible because you may not be enabling the permissions you think you are.