6.3 Data Visibility, Access & Integrity Fundamentals

Data Visibility, Access & Integrity Fundamentals

Quick Summary: Security in Salesforce operates through a multi-layered architecture commonly visualized as an onion or pyramid. Functional access (what objects, fields, and tabs a user can touch) is controlled by Profiles, Permission Sets, and Field-Level Security. Data access (which specific record rows a user can view or edit) is controlled by Organization-Wide Defaults, Role Hierarchy, and Sharing Rules. Complementing security, data integrity tools like Validation Rules and Unique Fields ensure that submitted data is clean, complete, and reliable.

The Layered Security Architecture: Functional vs. Record Access

To master Salesforce administration, you must understand the clear distinction between Object & Field Permissions and Record-Level Access:

• Object & Field Access (Functional Permissions): Answers the question: "What object types and field columns is this user permitted to view, create, edit, or delete across the system?"
• Record-Level Access (Data Scoping): Answers the question: "Assuming a user has permission to read the Account object, which specific Account records (rows) in the database can they actually see and modify?"

+--------------------------------------------------------------------------+
|                     Salesforce Layered Security Model                    |
|                                                                          |
| LEVEL 1: OBJECT & FIELD PERMISSIONS ("What can you do?")                 |
| - Profiles: Baseline CRUD permissions (Every user has exactly one)       |
| - Permission Sets: Additive permissions layered on top of profiles       |
| - Field-Level Security (FLS): Overrides page layouts across entire org   |
|                                                                          |
| LEVEL 2: RECORD-LEVEL ACCESS ("Which records can you see?")              |
| - Organization-Wide Defaults (OWD): Baseline non-owner access (Private)  |
| - Role Hierarchy: Opens access vertically to managers                    |
| - Sharing Rules: Opens access horizontally based on owner or criteria    |
| - Manual Sharing: Ad-hoc record sharing by owners or administrators      |
+--------------------------------------------------------------------------+

---

Level 1: Object & Field Access Controls

1. Profiles: Baseline Permissions

Every Salesforce user must be assigned exactly one Profile. A profile defines the user's core operational identity and baseline permissions:

• Object Permissions (CRUD): Determines whether the user can Create, Read, Edit, or Delete records of a particular standard or custom object. Profiles also control high-level administrative permissions like View All (bypasses record sharing to view all records of an object) and Modify All (bypasses record sharing to view, edit, delete, and transfer all records of an object).
• User Interface Access: Controls assigned apps, visible tabs, record types, and page layout assignments.
• System and Administrative Privileges: Controls capabilities such as exporting report data, running dashboards, or managing other users.
• Login Restrictions: Controls permissible Login Hours (e.g., blocking logins outside 8:00 AM–6:00 PM) and Login IP Ranges (restricting logins to corporate VPN networks).
• Standard Profiles: Pre-configured profiles include System Administrator, Standard User, Marketing User, Contract Manager, and Solution Manager.

2. Permission Sets and Permission Set Groups: Additive Flexibility

Modern Salesforce administration follows the core design principle: "Profiles provide the baseline; Permission Sets grant additive access."

• Additive Architecture: A user has only one profile, but can be assigned zero, one, or dozens of Permission Sets. Permission sets can only grant additional permissions; they can never revoke, restrict, or subtract permissions granted by a profile or another permission set.
• Avoiding Profile Proliferation: In older implementations, if three sales representatives out of a fifty-person team needed permission to export reports, administrators often created a whole new custom profile. With permission sets, the administrator maintains a single baseline profile for all sales representatives and assigns an "Export Reports" Permission Set to just those three individuals.
• Permission Set Groups: Bundles multiple permission sets together into a single administrative package. For example, a "Sales Operations Specialist" Permission Set Group can combine separate permission sets for Opportunity Management, Data Export, and Custom Discount Approvals, allowing administrators to assign the complete bundle in a single action.

3. Field-Level Security (FLS)

Field-Level Security (FLS) determines whether a specific field on an object is visible, read-only, or completely hidden for users with a particular profile or permission set.

• FLS Settings:
  • Visible (Read/Write): The user can view and edit values in the field.
  • Read-Only: The user can view the field value, but cannot edit or update it.
  • Hidden (Visible unchecked): The user cannot see the field anywhere in Salesforce.
• FLS Strictly Overrides Page Layouts: A common exam scenario tests the difference between removing a field from a Page Layout versus hiding it via FLS:
  • If an administrator merely removes a field from a Page Layout, the user cannot see it on that record page, but can still access the data through reports, list views, global search, and APIs.
  • If an administrator hides a field using Field-Level Security, the field is completely stripped from the user's access across the entire platform—it cannot be seen on page layouts, list views, search results, reports, dashboards, or external API queries.

---

Level 2: Record-Level Access Controls (The Sharing Funnel)

Once a user has object-level "Read" permission, the platform evaluates record-level access to determine which specific records the user can see. Record access is governed by a progressive access funnel:

+--------------------------------------------------------------------------+
|                       Record Access Evaluation Funnel                    |
|                                                                          |
|   [Is User the Record Owner?] --------(Yes)--------> [Full / Owner Access]|
|               | (No)                                                     |
|               v                                                          |
|   [Organization-Wide Defaults (OWD)]                                     |
|   - Public Read/Write -------------(Yes)-----------> [Read/Write Access] |
|   - Public Read Only --------------(Yes)-----------> [Read Only Access]  |
|   - Private -----------------------(Yes)-----------> [Check Hierarchy]   |
|               |                                                          |
|               v                                                          |
|   [Role Hierarchy Enabled?] --------(Yes)----------> [Inherits Subordinate|
|               | (No)                                  Access]            |
|               v                                                          |
|   [Matching Sharing Rules?] --------(Yes)----------> [Grants Read or R/W]|
|               | (No)                                                     |
|               v                                                          |
|   [Manual Share Granted?] ----------(Yes)----------> [Grants Read or R/W]|
|               | (No)                                                     |
|               v                                                          |
|       [ACCESS DENIED]                                                    |
+--------------------------------------------------------------------------+

1. Organization-Wide Defaults (OWD)

Organization-Wide Defaults (OWD) establish the baseline level of record access across the entire organization for users who do not own the record.

• The Golden Rule of OWD: OWD is the only record-level security control that can restrict access. All subsequent layers (Role Hierarchy, Sharing Rules, Manual Sharing) can only open or expand access. Therefore, OWD should always be set to the most restrictive level required by any user group.
• Primary OWD Settings for Custom Objects:
  • Private: Only the record owner and users above the owner in the Role Hierarchy can view and edit the record. All other users cannot see the record.
  • Public Read Only: All internal users can view and report on all records of the object, but only the record owner (and their hierarchy managers) can edit or delete them.
  • Public Read/Write: All internal users can view, report on, and edit all records of the object.
  • Controlled by Parent: Available exclusively for detail records in Master-Detail relationships. The detail record inherits the access level of its master parent record.

2. Role Hierarchy: Vertical Access Expansion

The Role Hierarchy models management and supervisory structures. It automatically opens record access vertically up the organizational tree:

• Vertical Inheritance: Users positioned at higher levels in the role hierarchy automatically inherit the exact same record access permissions as users positioned beneath them in their hierarchy branch.
• Example: If a sales representative owns an Account record and OWD is Private, their direct Sales Manager and the Vice President of Sales automatically gain full view and edit access to that Account record.
• Custom Object Control: On custom objects, administrators can disable this vertical inheritance by unchecking the Grant Access Using Hierarchies checkbox in Sharing Settings. (Note: On standard objects, Grant Access Using Hierarchies is permanently enabled and cannot be turned off).

3. Sharing Rules: Horizontal Access Expansion

Sharing Rules allow administrators to open record access horizontally across different branches of the role hierarchy or between functional departments.

• Sharing rules can grant either Read Only or Read/Write access.
• Sharing rules can never make record access more restrictive than the OWD baseline.
• Two Types of Sharing Rules:
  1. Owner-Based Sharing Rules: Shares records owned by members of a specific Role, Role & Subordinates, or Public Group with another Role or Public Group (e.g., "Share all Leads owned by the US Sales Team with the Marketing Team as Read Only").
  2. Criteria-Based Sharing Rules: Shares records based on specific field values regardless of who owns the record (e.g., "Share all Accounts where BillingCountry = 'Canada' with the Canadian Support Public Group as Read/Write").

4. Manual Sharing

Manual Sharing provides ad-hoc record sharing. The record owner, an administrator, or any user with Modify All permissions can manually share an individual record with a specific user, role, or public group to support temporary collaboration.

---

Declarative Data Integrity Controls

Security controls who sees data; Data Integrity Controls ensure that data saved into Salesforce is accurate, complete, and formatted correctly.

1. Validation Rules

A Validation Rule contains a formula expression that evaluates record data before changes are saved to the database.

• The Inversion Principle of Validation Formulas: A validation rule formula evaluates to TRUE when data is INVALID!
• Save Blocked: When the formula evaluates to TRUE, Salesforce halts the save transaction, rolls back pending database changes, and displays a customized error message.
• Error Message Placement: Administrators configure the error message to appear either at the top of the record page or immediately adjacent to a specific field.
• Universal Enforcement: Validation rules execute during both record creation and record updates, and enforce business rules across the browser UI, automated flows, and API data loading operations.
• Example Formula: To require a discount reason whenever a discount exceeds 15%: AND( Discount_Percentage__c > 0.15, ISBLANK( Discount_Reason__c ) )

2. Required Fields: Database-Level vs. Page Layout Enforcement

Ensuring required data entry can be implemented at two different architectural layers, with critical differences in behavior:

• Field Definition Level (Database-Wide): Checking the "Required" box in the custom field definition enforces data entry universally across the entire database. The field is required in the browser UI, Lightning record pages, automated Flows, Apex code, and data imports via the Data Loader or APIs.
• Page Layout Level (UI Only): Marking a field as required on a Page Layout enforces data entry only when an end user manually creates or edits a record through that specific page layout in the web browser. Records imported through APIs or created via backend automations can bypass this requirement and save records with blank values.

3. Unique Fields and External IDs

• Unique Fields: Checking "Unique" on a custom field definition prevents duplicate values across all records of that object. Administrators choose between Case-Sensitive uniqueness (where ABC-123 and abc-123 are treated as unique) and Case-Insensitive uniqueness (where ABC-123 and abc-123 are treated as identical duplicates, blocking save).
• External IDs: Marking a custom field (Text, Number, or Email) as an External ID designates it as a unique record identifier originating from an external enterprise system (such as SAP, Oracle, or an ERP). External IDs accelerate database indexing, streamline upsert operations in Data Loader, and prevent duplicate data entries during system integrations.

4. Duplicate Management: Matching Rules and Duplicate Rules

Duplicate records are one of the most common data-quality problems. Salesforce handles them declaratively with two linked tools:

• Standard rules: Salesforce provides standard matching and duplicate rules for Accounts, Contacts, and Leads, which administrators can activate, clone, or customize in Setup.
• Resolving existing duplicates: Users can merge duplicate Accounts, Contacts, or Leads, up to three records at a time, choosing which field values to keep.
• During imports: The Data Import Wizard can match incoming rows to existing records (for example, by name, email, or Salesforce ID) so an import updates records instead of creating duplicates.

5. Choosing the Right Integrity Tool