Applicable plans Sprout Blossom Garden* Estate Forest
Freshsales allows Admins to control permissions given to a user on the roles provided and create new roles based on the roles present in the organization.
How does this work?
Let us consider an example.
As a company grows and onboards more users, there is always a need to regulate access for the team members. While a regional sales manager may need to view and edit records such as leads, contacts, accounts, and deals or reports, but may not need access to delete the records.
Similarly, a Sales Development Representative (SDR) may need access to view and edit leads, but may not need access to delete a lead or export a lead report. In such cases, Admins can create roles that give the right permissions to users in the CRM.
Freshsales provides 5 roles - Restricted user, User, Manager, Admin and Account Admin. Admins can use these 5 roles as a basis to modify permissions and create customized roles that suit the nature of their organizational hierarchy.
How to create customized roles in Freshsales?
To create custom roles,
Go to Admin Settings > Roles
Click Create Role
Enter the role name and choose the permissions you want to clone.
Choose the default scope:
All Records: Allows agents to access data across the organization.
Territory Only/Group Only: Allows agents to access data by territories. This is ideal for sales teams that are defined by regions, sources, etc.
Group-only access is ideal for support agents. For example, they can add private notes on conversations only if they are part of the group to which the conversation is assigned.
Owned Only: Allows agents to access their owned records only while restricting their access to other users’ data.
Click Next to proceed.
Choose the relevant permissions for the role. Administrators now have the ability to define distinct scopes within each Action Permission
The different categories of permissions are:
Admins can set up granular scope for every action mentioned below:
View - Select the scope for View permissions
Edit - Select the scope for Edit permissions
Delete - Select the scope for Delete permissions
This is applicable to Leads, Contacts, Accounts, and Deals. It will also contain scopes for the permissions of any custom modules that may be created. If the admin wants to remove edit/delete access, they can select the "Can’t Edit"/”Can’t Delete” option.
Note: Global, Territory and Restricted scopes are supported for custom modules and are available in the Enterprise plan.
CPQ Modules: Control access to Products and Quotes modules with Global/Restricted Scope. This scope is applicable across all permissions(View, Edit, Edit all, Delete owned)
Sales Activities: All Sales Activities, such as Tasks, Meetings, Call Logs, and Custom sales activities, fall under this category. The access to all these activities will be ‘Related Access.’ This means users can access and edit tasks and appointments of only those records that fall under their scope.
Note: The permissions selected for custom sales activities will apply to all configured sales activity types.
For example, your Sales Development Representative can access Tasks and Appointments while still being revoked access to custom sales activities.
Actions: This includes all record-related actions such as Create, Import, Assign, and Share. You can restrict users from searching for records under specific modules using Search records permissions.
For example, a vendor with access only to the Contacts module in your web application can be restricted to searching for records under the Contacts module alone.
In the case of our example, for a Sales Development Representative, you can choose to allow access to all actions except importing and merging deal records.
With the Access Views permission, you can restrict users only to view specific modules on the Left Navigation Bar and List Views.
For example, if the Deals module is turned off under 'Access View', the Deals module will not be accessible for Users in the List View. Users can navigate the Account details page and create or view related deals.
For instance, in our scenario, a Sales Development Representative could be permitted to solely view the team’s quotas without the ability to make edits.
In the case of our example, for a Sales Development Representative, you can grant the user access to view all team goals but enable access to create goals only for himself. Similarly, you can also disable access to 'Recalculate a goal.'
Emails: All permissions related to email functionality, such as access to Sharing Email Templates, Setting limits for Individual emails, and bulk emails, fall under this category.
All shared templates are read-only for all users other than the template's creator. Admin can restrict the sharing scope. The following options are available under sharing scope.
Everyone - Public templates are shared with all users/teams/territories in the account.
My teams - Users can select specific Team names to share with all users in that team.
My Territory - Users can select specific territory names to share with users under those territories.
Connect your mailbox permission will be enabled by default for all roles. Admins can refrain their users from syncing their mailboxes with the web application by unchecking this option. If this permission is disabled, all the users associated with this role will not have permission to connect their mailbox to the web application. Suppose the permission is disabled for a user with their mailbox connected to the web application. In that case, they will retain their already synced conversations, but their mailbox will be disconnected, and the connect your email tab will display a message that the user cannot connect their mailbox.
Admins can define email limits for the following:
Individual emails or transactional emails sent out per day
Bulk emails sent per day
In the case of our example, for a Sales Development Representative, you can allow access to all actions except sharing email templates. This setting will hide the share option on the email template for the user. You can also set bulk and individual email limits for the user. This places a cap on the number of emails that the user can send from the web application.
Note: Admin can also restrain the user from sending Emails by unchecking the checkbox under Email custom roles.
Sales Sequences: All permissions related to Sales sequences, such as access to the Sales sequence page, the ability to create and share sequences, and setting limits for the maximum number of emails sent via sales sequences, fall under this category.
In the case of our example, we can allow the Sales Development Representative to view all Sales sequences while restricting permission to create sales sequences only for contacts. Similarly, we can also set the limit as 4000 emails per day as part of the Sales sequences.
Note: A user needs ‘View’ access to access the Sales Sequences page. Users who do not have Sales sequences ‘View’ access will still be able to add contacts to existing sequences by choosing the ‘Add to sequence’ option from the list view and the landing page of the record.
In the case of our example, we can allow the Sales Development Representative to send a maximum of 500 Individual SMSes and 300 Bulk SMSes per day.
User Settings Permissions: All permissions related to User Settings fall under this category. Admins can configure access to a user's access to various user-specific features, such as requesting a demo, creating a support ticket, downloading the mobile app, accessing the knowledge base, etc., by checking/unchecking the options.
Admin Settings Permissions: All permissions related to Admin settings falls under this category. Admins can configure access to Admin settings by checking/unchecking the options.
In the case of our example, for a Sales Development Representative, you can disable access to manage users or export data and restrict their role to access only workflows and territories.
Note: All permissions under reports are dependent on the ‘Access Admin Settings’ permission. Unchecking this option would disable the Admin Settings functionality for the user and hide the buttons from the user’s application.
To modify permissions for individual fields, refer to this article