---
schema_version: "1"
id: f5edbf270f610e459c2e3227afdee8d6088a29a132d1e96a5de838d4b49b4927
title: Create a User Role
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/admin_roles.md
canonical_url: https://help.salesforce.com/s/articleView?id=platform.admin_roles.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: 7c6e69eb0d68d2da8ecbb9764f42d512faed574b316371221a57b08d2cdb273b
description: In the role hierarchy, users have access to records owned by or shared with users in roles below them. Roles within the hierarchy affect access on components such as records and reports.
products:
  - Security
  - Salesforce Platform
release: "264"
---
# Create a User Role

In the role hierarchy, users have access to records owned by or shared with users in roles below them. Roles within the hierarchy affect access on components such as records and reports.

### Required Editions

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Professional</strong>, <strong>Enterprise</strong>, <strong>Performance</strong>, <strong>Unlimited</strong>, and <strong>Developer</strong> Editions</td></tr></tbody></table>

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small permission">
        <colgroup>
          <col style="width:50%">
          <col style="width:50%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="colgroup" class="slds-cell-wrap" colspan="2" style="text-align:center;vertical-align:top;" id="d46845e75">User Permissions Needed</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">To view roles and role hierarchy:</td>

            <td class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">View Roles and Role Hierarchy</td>

          </tr>
          <tr class="">
            <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">To create, edit, and delete roles:</td>

            <td class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">Manage Roles</td>

          </tr>
          <tr class="">
            <td data-label="User Permissions Needed" class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">To assign users to roles:</td>

            <td class="slds-cell-wrap" style="vertical-align:top;" headers="d46845e75 ">Manage Internal Users</td>

          </tr>
        </tbody>
      </table>

For information on designing your sharing setup to improve performance and speed up sharing changes, see the [Designing Record Access for Enterprise Scale](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_preface.htm) guide.

Users at any role level can view, edit, and report on all data that’s owned by or shared with users below them in their role hierarchy, except in these two scenarios:

- For custom objects, you can disable the **Grant Access Using Hierarchies** setting on the Sharing Settings page. When disabled, only the record owner and users who are granted access have access to the custom object’s records.
- After you share a folder with a role, it’s visible only to users in that role, not to superior roles in the hierarchy.

1. From Setup, in the Quick Find box, enter Roles, and then select **Roles**.
2. If the “Understanding Roles” page is displayed, click **Set Up Roles**.
3. Find the role under which you want to add the new role. Click **Add Role**.
4. Add a Label for the role. The Role Name field autopopulates.
5. Specify who the role reports to. The field is already populated with the role name under which you added the new role, but you can also edit the value here.
6. Optionally, specify how the role name is displayed in reports. If the role name is long, consider using an abbreviation for reports.
7. Specify the role’s access to the child contacts, opportunities, and cases associated with accounts that users in the role own.
    
    For example, you can set the contact access so that users in the role can edit all contacts associated with accounts that they own. This access applies regardless of who owns the contacts. And you can set the opportunity access so that users in a role can view, but not edit, all opportunities associated with accounts that they own. This access also applies regardless of who owns the opportunities.
    
    ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-access-264-0-0-production-enus/a92be132-3cbc-412a-9262-130636120c14/images/icon_note.png)
    
    Note If a child object’s organization-wide default is Public Read/Write, you can’t specify access, because you can’t use the role hierarchy to restrict access further than your organization-wide defaults. If the organization-wide default for contacts is Controlled by Parent, you also can’t specify access.
8. Click **Save**.

![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-platform-access-264-0-0-production-enus/a92be132-3cbc-412a-9262-130636120c14/images/icon_note.png)

Note Roles for customer and partner users aren’t included on the role hierarchy setup page. For more information, see [Configure an External Account Hierarchy](https://help.salesforce.com/s/articleView?id=platform.networks_external_account_hierarchies.htm&release=264.0.0&type=5 "Set up an external account hierarchy to share data seamlessly with other external users.").

When you edit groups, roles, and territories, sharing rules are recalculated to add or remove access as needed. Depending on the nature of your updates and your org’s setup, these sharing calculations can take a while to complete. If you experience sharing evaluations or timeouts, consider deferring sharing calculations before making large-scale updates, and then restart and recalculate sharing at a later time. For more information, see [Defer Sharing Calculations](https://help.salesforce.com/s/articleView?id=platform.security_sharing_defer_sharing_calculations.htm&release=264.0.0&type=5 "Performing a large number of configuration changes can lead to very long sharing rule evaluations or timeouts. To avoid these issues, a Salesforce admin can suspend sharing calculations, specifically for sharing rules and group membership, then resume calculations during an organization's maintenance period.") in Salesforce Help.

#### See Also

- [_Designing Record Access for Enterprise Scale_: Group Membership Locking](https://developer.salesforce.com/docs/atlas.en-us.draes.meta/draes/draes_group_membership_locking.htm)