--- schema_version: "1" id: 8ce7998bea312cd5653a69a1009be0fc8b3bccde8ed778ce27f183127aceb6f7 title: Create a Record-Level Policy in Data 360 collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/data/264-0-0/c360_a_create_rls_policy.md canonical_url: https://help.salesforce.com/s/articleView?id=data.c360_a_create_rls_policy.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 9d22a30181892111d102dbef37c97cca255cd8143d735b0d2017b89a52b5a75e description: Define who can access specific records within an object based on user and data attributes. products: - Data 360 release: "264" --- # Create a Record-Level Policy in Data 360 Define who can access specific records within an object based on user and data attributes. ### Required Editions Before completing this task, review these considerations. - When you create a record-level security policy (RLS) on a DMO or a calculated insight object, the policy applies only to the data space where the object is available. This is because the API name includes the data space prefix, and policies are authored based on this API name. - If an RLS with Join policy uses a masked field as the join key, the join operates on the masked value, which can lead to inaccurate results. Avoid using masked fields in RLS with Join queries. - Unmask primary key and foreign key fields to maintain accurate object relationships and effective data joins. - RLS policies aren’t enforced when creating segments and calculated insights because these operations run in system context. - Currently, the RLS policy filters records only for users who meet the policy criteria. Other users see all records because the default Day 0 Allow All object-level security (OLS) policy remains in effect. In an upcoming change, any RLS permit policy disables the Day 0 Allow All policy. Users who don’t meet the RLS criteria lose access to all records governed by the RLS policy. For example, if an RLS policy grants access only to US Opportunity records, users without the required permission no longer see any Opportunity records after this change. - Hierarchy data is synchronized periodically. It can take up to 15 minutes for changes in the source system to be reflected in Data 360. - Index custom user fields before using them in policies for optimal performance.
Available in: All Editions supported by Data 360. See Data 360 edition availability.
User Permissions Needed
To create a data access policy:

Permission set:

  • Data Cloud Architect
1. In Data 360, go to the Data Governance tab. 2. In the left pane, click **Policies**. 3. Click **New**, select **Data Access**, and click **Next**. 4. In Policy Builder, enter a unique policy name, and an optional description. The policy API name is auto-filled based on your policy name, but you can change it. 5. Select the user authorization level. For more information, see [Controlling External User Access in Data 360](https://help.salesforce.com/s/articleView?id=data.c360_a_control_external_user_access.htm&type=5&language=en_US). 6. Click **Next**. 7. Select **Rules**, and select the resources to protect. In the **Resource** dropdown, select **Record**. By default, the rule applies across all data spaces. As new data spaces are added, these rules apply to their resources. 8. To restrict policies to specific data space scopes, click **Customize Scope**, deselect **Apply to the resources in all Data Spaces in Data Cloud**, and select the desired data spaces. 9. Click **Save**. 10. Select the action you want to take on the resource. From the Action dropdown, select **Allow access** or **Deny access**. 11. Define the conditions when this action must take place. For example, allow access when **Account.Country** equals **United States**. Or, allow access when **Opportunity.OwnerId** equals **$User.Id**. Trigger the rule when objects meet any or all specified conditions. Reference standard user attributes in resource conditions using the $User variable. Standard user attributes include: - $User.CallCenterId - $User.CompanyName - $User.ContactId - $User.Department - $User.Division - $User.Email - $User.ProfileId - $User.UserRoleId - $User.Title - $User.Id - $User.OrganizationId - $User.Username 12. To add a hierarchy-based rule, use the Hierarchy operator (Is Hierarchically Above In) and select the appropriate hierarchy, such as a manager, role, or territory hierarchy, to grant access. For example, allow a manager to view records owned by their team, while team members view only their own records. Or, users assigned to the North America territory can access records across all regions within North America, including the United States, Canada, and Mexico. You must successfully ingest a hierarchy for it to appear as an option in the operator. To ingest hierarchical data, see [Ingest Hierarchical Data](https://help.salesforce.com/s/articleView?id=data.c360_a_ingest_hierarchy_data.htm&release=264.0.0&type=5 "Bring Salesforce CRM organizational hierarchies such as Role, Manager, and Territory into Data 360. After ingestion, you can reference these hierarchies in hierarchy-based record-level security (RLS) policies."). 13. To add more conditions, click **Add Condition**. Add up to five conditions to a record-level security (RLS) policy. 14. Group your conditions into different sets and use the OR operator to act when any group meets the rule conditions. 15. To add a group, click **Add Group**. 16. Click **Add Join Block** to add a custom join block. Custom joins let access rules reference external mapping or lockup tables and enable dynamic and context-aware access conditions. 17. Select the objects and fields to be referenced by the rule. 18. To add more join sections, click **Add Join**. Add up to three joins. To remove a join, click the delete button. If there are dependencies in the join, remove them before deleting a join. 19. To add filters and criteria for the join block, click **Add Filter**. 20. To apply the policy to users, select **Users**. Apply the policy to all users or to users who meet specific AND and OR conditions. The conditions are based on custom permissions or standard user attributes assigned to users. Standard user attributes include: - Call Center ID - Company Name - Department - Division - Profile ID - Title 21. To match multiple values, use the CONTAINS operator: `Department__c CONTAINS SALES_NW, SALES_SW, SALES_NE` 22. Related object fields are supported using relationship notation. For example: `AssignedBrands__r.BrandName__c equals GAP` `Departments__r.DepartmentCode__c CONTAINS DEPT-001, DEPT-002` 23. Click **Save and Activate**.