Getting the most out of Salesforce sharing rules
Look, we’ve all been there. You set your Organization-Wide Defaults (OWD) to private because security is a priority, but then the sales team in the West region suddenly needs to see what the East region is doing. This is exactly where Salesforce sharing rules come into play to save your sanity.
In my experience, record access is one of the things that trips people up the most when they’re new to the platform. We often talk about understanding the difference between roles and profiles, but sharing rules are the secret sauce for lateral access. They let you open up records to specific groups of users without having to mess with your entire hierarchy.
How they fit into the security model
Think of your security like an onion. Profiles and permission sets handle what a user can do with an object (Read, Create, Edit). OWDs set the baseline for which records they can see. Salesforce sharing rules sit right on top of that baseline to grant extra access when the OWD is too restrictive. But remember: they can only grant access, never take it away.
Breaking down the types of Salesforce sharing rules
When you’re sitting in the Setup menu, you’ll see two main paths. Honestly, most teams get this right, but it’s the “why” that matters. You’re either sharing based on who owns the record or what’s actually inside the record fields.
Owner-based rules
These are the workhorses. You use these when you want to say, “If someone in the ‘California Sales’ role owns an Opportunity, let the ‘Support Team’ public group see it.” It’s simple, it’s predictable, and it follows your organizational structure. I’ve used these countless times to bridge the gap between departments that don’t report to the same VP.
Criteria-based rules
Now, here’s where it gets interesting. Criteria-based rules don’t care who owns the record. They look at the data. For example, if an Account has an “Annual Revenue” greater than 10 million, you might want your Enterprise team to have access immediately. Just be careful with these. If you have a lot of changing data, you might see some performance lag because Salesforce has to re-evaluate the access every time that field changes.
Pro Tip: If you find yourself building dozens of criteria-based rules for the same object, stop. You might be better off looking at your OWD or reconsidering how you’ve grouped your users into Public Groups.
When to move beyond Salesforce sharing rules
So what does this actually mean for a growing org? Most of the time, declarative Salesforce sharing rules will handle 95% of your requirements. But sometimes, the business logic is just too messy. Maybe you need to share a record based on a complex calculation or a related list that isn’t directly on the record.
That’s when you look at Apex Managed Sharing. But a word of caution: don’t jump to code too early. I’ve seen developers write complex sharing triggers that become a nightmare to maintain when a simple public group and a standard rule would have worked fine. Also, if you’re managing large data volumes, keep an eye on your recalculation times. When you save a new rule on an object with millions of records, Salesforce has to do a lot of heavy lifting in the background.
A quick note on Role Hierarchy
One thing that often gets forgotten is that the Role Hierarchy already shares records vertically. If a manager is above a rep in the hierarchy, they already see what the rep sees. You don’t need a sharing rule for that. In fact, before you add a rule, I always recommend checking if deleting a role or moving one would solve the problem more cleanly.
Key Takeaways
- Salesforce sharing rules only expand access; they never restrict it.
- Use Owner-based rules for structural sharing and Criteria-based rules for data-driven sharing.
- Public Groups are your best friend when managing the “who” in your sharing rules.
- Always check your Role Hierarchy first to see if access is already granted naturally.
- Watch out for “Sharing Recalculation” delays on objects with huge amounts of data.
At the end of the day, keep your sharing model as simple as possible. Start with a restrictive OWD, use the hierarchy for management access, and use sharing rules to handle the exceptions. It makes your life as an admin or dev much easier when you’re trying to troubleshoot why a user can see something they shouldn’t. Stick to the declarative tools until they truly break, and you’ll have a much more stable org.