Loading
About Salesforce Data 360
Table of Contents
Filter by (0)Add
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

            Search all of Salesforce Help
            Search all of Salesforce Help
            Create a Record-Level Policy in Data 360

            You are here:

            1. Salesforce Help
            2. Docs
            3. Data 360

            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 an record-level security policy (RLS) on a DMO or 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.
            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. Click Next.
            6. 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.

            7. 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.
            8. Click Save.
            9. Select the action you want to take on the resource. From the Action dropdown, select Allow access or Deny access.
            10. 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.
              You can trigger the rule when objects meet any or all specified conditions.
            11. 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 can 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.
            12. To add more conditions, click Add Condition.
              You can add up to five conditions to a record-level security (RLS) policy.
            13. Group your conditions into different sets and use the OR operator to act when any group meets the rule conditions.
            14. To add a group, click Add Group.
            15. Click Add Join Block to add a custom join block. Custom joins allow access rules to reference external mapping or lockup tables and enable dynamic and context-aware access conditions.
            16. Select the objects and fields to be referenced by the rule.
            17. To add more join sections, click Add Join. You can 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.

            18. To add filters and criteria for the join block, click Add Filter.
            19. 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 assigned to users.

              Actions that explicitly deny access override other permissions to block the user from performing that action.

            20. Click Save and Activate.
             
            Loading
            Salesforce Help | Article