Survey Response Access Control: A Configuration-First Guide

Introduction to Declarative Survey Security

When we deploy Salesforce Surveys, we often focus on the customer experience: the invitation emails, the question logic, and the branding. However, once the data starts flowing in, a critical architectural challenge arises: how do we ensure that only the right regional teams can view the feedback specific to their area?

In many enterprise environments, the default Org-Wide Defaults (OWD) for Survey Response objects are set to 'Private.' While this protects data, it often creates a bottleneck where admins are forced to write complex Apex-based sharing triggers. In this guide, we'll walk through how to architect a robust, scalable security model using only configuration—ensuring your Survey Response data remains compliant and partitioned without the technical debt of Apex.

Step 1: Architecting the Object Hierarchy

Before configuring sharing, we must understand the relationship between the SurveyResponse and the objects that define 'Region' or 'Account.' Salesforce Surveys are inherently linked to the SurveySubject and the associated record (like an Account or Opportunity).

To control access by region, your data model must support a lookup to a location-aware object. If your survey is triggered from an Account, ensure that every Account is tagged with a 'Region' picklist or lookup field. This field will become the primary key for our sharing rules.

1. Verify your SurveyResponse object is correctly associated with a record that contains regional data.
2. Ensure the OWD for SurveyResponse is set to Private.
3. Navigate to Sharing Settings in Setup and confirm the access level for Survey Response is effectively locked down.

Step 2: Leveraging Role Hierarchy for Regional Security

If your organization is structured by geography (e.g., North America, EMEA, APAC), the Salesforce Role Hierarchy is your strongest, most low-maintenance asset. By aligning your users into a hierarchy that mirrors your regional structure, you can inherit access to responses automatically.

• The Structure: Create a parent 'Region' role (e.g., 'EMEA Manager') and child roles (e.g., 'EMEA Sales Representative').
• The Benefit: By checking the 'Grant Access Using Hierarchies' checkbox in Sharing Settings, managers automatically gain access to all survey responses owned by their regional subordinates.

If your organizational structure is more matrixed—where users across different roles need access to the same region—we must move to Criteria-Based Sharing Rules.

Step 3: Implementing Criteria-Based Sharing Rules

Criteria-based sharing allows us to open up access to specific Survey Responses based on the values within the record itself, rather than who owns it. This is the 'secret sauce' for region-based access control.

To implement this:

1. Navigate to Setup > Sharing Settings.
2. Locate the Survey Response sharing rules section.
3. Click New to create a rule based on criteria.
4. Define the filter logic:
   • Criteria: Set the field SurveySubject.Record.Region__c (or your relevant lookup) equals 'EMEA'.
   • Share with: Select the specific Public Group (e.g., 'EMEA Support Team').
   • Access Level: Set to 'Read Only' or 'Read/Write' based on your requirements.

This approach effectively partitions your survey data into secure buckets without requiring a deployment of custom code.

Step 4: Scaling with Enterprise Territory Management

For large-scale global organizations, simple roles may not suffice. Enterprise Territory Management is a powerful, native alternative to code-heavy security models. When you assign accounts to territories, you can automatically grant territory members access to the survey responses linked to those accounts.

How to enable this:

• Enable Enterprise Territory Management in Setup.
• Assign Users to Territories based on regional zip codes or other metadata.
• Under the Territory Model settings, ensure that Access to Associated Objects is enabled.

This configuration ensures that as soon as a new Survey Response is logged against an Account, the user assigned to that Territory immediately inherits the visibility permissions, all handled by the platform engine.

Best Practices for Auditing Access

Even without Apex, you need to monitor access. Use the 'Sharing' button on a sample Survey Response record to see exactly who has access and why. This button provides a breakdown of whether access was granted by the Role Hierarchy, a Sharing Rule, or manual sharing.

• Regularly Audit: Run a report on Survey Responses and compare it against your public groups to ensure no 'over-sharing' has occurred.
• Keep it Simple: Avoid creating overlapping sharing rules. If a user is in a Role, don't create a separate criteria-based rule for them unless strictly necessary.
• Use Public Groups: Always share with Public Groups, not individual users, to prevent ongoing administration overhead when employees change teams.

Key Takeaways

• OWD is the Baseline: Always start by setting your Survey Response OWD to Private to ensure secure-by-default behavior.
• Hierarchy over Rules: Always utilize the Role Hierarchy first to reduce the number of explicit sharing rules you need to manage.
• Criteria-Based Sharing: Use this for regional partitioning where a user's role might not map 1:1 to the geographical survey data.
• Territory Management: Consider this for high-complexity, multi-national organizations to automate record access based on business geography.
• Audit Regularly: The native 'Sharing' button on records is your best friend for validating that your security architecture is behaving as intended without needing to query debug logs.