Salesforce Docs Portal

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.
  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.
  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.