Data security is the bedrock of client trust, especially in the Financial Services sector where confidentiality is non-negotiable. We recently partnered with a firm facing a distinct compliance requirement: they needed to onboard a specific group of users but limit their Salesforce access to one single client relationship.
These users needed full context—Contacts, Opportunities, and Leads—for that specific Account, but absolute blindness to the rest of the organization’s data.
Achieving this level of isolation requires moving beyond standard configuration. In Salesforce, the security model is additive—meaning the system is designed to layer more access on top of a baseline. To create a silo for a specific group without breaking the model for everyone else, we went back to the architectural roots of the platform.
The Solution: A “Lock and Key” Architecture
Rather than creating complex patches or custom code, we utilized a streamlined, three-step security architecture.
Step 1: The Foundation (Organization-Wide Defaults) Security starts at the baseline. We first analyzed the client’s sharing model to ensure their Organization-Wide Defaults (OWD) were set to “Private”. If the default setting is “Public,” restricting specific users becomes a maintenance nightmare. By confirming the baseline was Private, we ensured the door was closed by default.
Step 2: The Lock (Minimum Access Profile) To ensure these users had zero visibility upon logging in, we assigned them the Minimum Access Profile.
-
What this means: A standard Profile often comes with default permissions (like seeing all active users or standard reports). The Minimum Access profile is a blank slate. It allows the user to log in, but they cannot see objects, records, or app settings until we explicitly say otherwise.
Step 3: The Access Layer (Permission Sets vs. Sharing Rules) This is where the distinction between “what you can do” and “what you can see” becomes critical. We used two distinct tools to grant access back to the users:
-
The Permission Set (The “License to Drive”): We built a “Restricted Access” permission set. This grants Object-Level Security. It tells Salesforce, “These users are capable of reading and editing Accounts and Contacts.” However, it does not actually show them any specific records yet. It simply gives them the functional ability to interact with that type of data.
-
The Sharing Rule (The “Keys to the Car”): To show them the specific data, we configured a Sharing Rule. This rule acts as the bridge, stating: “If a record belongs to this specific Account, share it with this specific group.” This linking ensured that when they accessed the main Account, they automatically gained access to the related Contacts and Opportunities.
The Outcome
By decoupling the functional permissions (Permission Set) from the data visibility (Sharing Rule), we created a robust security model. The users can fully manage the Contacts and Opportunities associated with their assigned Account, but the rest of the database remains completely invisible to them.
This approach provided the client with immediate operational readiness and total compliance, without the technical debt of over-customization.