Table of Contents
Look, in Salesforce, dealing with Person Accounts, especially when it comes to who sees what, well, it’s not always straightforward. You might think, “Accounts are Accounts, right?” But Person Accounts, they’re this unique beast. They combine the stuff of a regular business account with a contact record. And that hybrid nature? It throws a wrench in how you think about sharing. By 2025, if you’re still scratching your head over Person Account sharing, it’s time we cleared some things up. We’re talking about sharing rules here, how they work, and how they don’t.
Person Accounts: Why They’re Different (And a Bit Annoying)
Most folks get the hang of standard Accounts and Contacts. You set up your Organization-Wide Defaults (OWDs), maybe restrict contacts via their parent account. Simple. But then Person Accounts roll in. They are an Account record type, sure, but they also are a Contact. Salesforce kind of merges them into one record in the user interface. It looks like one thing, but under the hood, it’s two. That design means your sharing strategies need a little finessing.
You can’t just share “the Contact part” of a Person Account separately from “the Account part.” What you do to the Account side, that sticks to the whole Person Account. This is where sharing rules, specifically those built for accounts, become your go-to. They give you the levers you need when OWDs or your role hierarchy aren’t cutting it. Because let’s face it, your company probably doesn’t want everyone seeing every customer, right? Sales people in one territory shouldn’t see customers from another. That’s just basic business sense.
understanding Salesforce Sharing Rules for Person Accounts
Okay, so let’s get into the nitty-gritty of sharing rules. Basically, these rules let you extend access to records beyond what your OWDs or role hierarchy allows. They don’t take away access; they only give more. Think of them as opening doors to specific groups of users based on who owns a record or certain criteria on the record itself. For Person Accounts, this is powerful.
When you create a sharing rule, you’re telling Salesforce: “Hey, for these types of records, give these people this much access.” And since Person Accounts are just another type of Account record, you use the standard Account sharing rules. Don’t go looking for “Person Account Sharing Rules” specifically; they don’t exist as a separate entity. It’s just ‘Account Sharing Rules,’ and you apply them to your Person Account record type. That’s a common point of confusion I see people get stuck on.
How to Set Up a Sharing Rule for Person Accounts
Setting up one of these rules isn’t rocket science, but you gotta be precise. Here’s how it generally plays out:
1. Navigate to Sharing Settings: You’ll start in Setup. Type “Sharing Settings” into the Quick Find box. This is where all your OWDs live, and it’s also where you manage sharing rules.
2. Find Account Sharing Rules: Scroll down until you hit the “Account Sharing Rules” section. You’ll see a button to create a “New” rule. Click that.
3. Name the Rule: Give it a clear name. Something like “Sales Team East Person Account Access” is way better than “Rule 1.” A good description helps future you (or someone else) understand why it exists.
4. Choose Your Rule Type: This is a big one.
Owner-Based Sharing Rule: This type is simple: if a record is owned by this person or this group of people (like a role or public group), then these other people get access. For example, if a Person Account is owned by anyone in the “EMEA Sales” role, then the “EMEA Marketing” public group gets read-only access.
Criteria-Based Sharing Rule: This is where it gets interesting. You define criteria on the Person Account record itself. “If the ‘Customer Type’ field is ‘VIP’ AND ‘Region’ is ‘West,’ then grant access.” This is incredibly flexible. You pick the fields on the Account object (which includes Person Accounts) and set your conditions.
5. Define Who Gets Access: After you set which records are affected, you decide who gets to see them. You can pick:
Public Groups: These are super useful. You can put any mix of users, roles, and other public groups into them.
Roles: Everyone in a specific role (and roles below them, if you pick that option).
Roles and Subordinates: This means everyone in that role and any roles under it in the hierarchy.
Territories (if enabled): If your org uses Salesforce Territory Management, you can share based on territory assignments.
6. Set Access Level: Finally, you decide how much access they get.
Read Only: They can see the record, but not change it.
Read/Write: They can see and edit the record. Remember, if your OWDs are more restrictive than Read Only, a sharing rule can only grant more access, not less. So, if OWD for Accounts is Private, and you give Read/Write through a rule, users get Read/Write. But if OWD is Public Read/Write, a sharing rule can’t make it Read Only.
This process, it applies exactly the same to your Person Accounts because, well, they are accounts. Just don’t overthink it beyond that.
Common Scenarios for Sharing Person Accounts
So, why would you even need to do this? In my experience, it’s about control and ensuring the right data lands with the right people.
Regional Sales Teams: Imagine I’ve got Person Accounts scattered across the globe. My North American sales team doesn’t need to see my APAC customers, and vice-versa. I can set up criteria-based sharing rules: if `Billing Country` is ‘United States’ or ‘Canada’, share with the ‘North American Sales’ public group. Simple. And effective.
Customer Support Hand-offs: Say my Level 1 support team handles all incoming calls, but VIP customers get routed to a specialized Level 2 team. I can make an owner-based sharing rule: if a Person Account’s owner is in the ‘L1 Support Queue’ public group, then share Read Only access with the ‘L2 Support Queue’ public group. This way, L2 can always jump in and help, even if they don’t own the account yet.
Marketing Segmentation: My marketing department wants to run targeted campaigns. They don’t need to edit customer records, but they need to see who is a customer. If Person Accounts have a custom field like ‘Engagement Level’, I can share ‘Read Only’ access for all Person Accounts with ‘Engagement Level’ above ‘Bronze’ to the ‘Marketing Team’ public group. This lets them build lists without messing with data.
Project-Specific Access: Sometimes, a project team needs temporary access to a subset of Person Accounts related to a specific initiative. Creating a public group for the project team and then a criteria-based rule (e.g., `ProjectTagc` equals ‘Alpha-Pilot’) can grant them exactly what they need for the duration. And it’s easy to remove later.
The point is, these rules give you a scalpel, not a sledgehammer, for access control. You can get pretty granular, which for bigger orgs, is absolutely necessary.
Gotchas and Things to Watch For
Setting up sharing rules isn’t hard, but you can trip yourself up if you’re not paying attention.
OWDs Are King: Remember, sharing rules only grant access. They never restrict it. If your OWD for Accounts is Public Read/Write, a sharing rule can’t make certain Person Accounts private. OWDs are your baseline. Always start there. If you want things truly private by default, make your OWDs private.
performance Matters (Sometimes): If you end up with hundreds of complex criteria-based sharing rules, especially if they involve lookups or rollup summary fields, you might see performance issues. Salesforce does a good job optimizing, but there’s a limit. Generally, keep rules clean, consolidated where possible, and don’t over-engineer them. In my experience, most orgs won’t hit this wall, but it’s something to keep in mind if things get sluggish.
Testing is Not Optional: Seriously. Build your sharing rules in a Sandbox environment. Create test users with different profiles and roles. Log in as those users and verify they see exactly what they’re supposed to see, and nothing more. I can’t stress this enough. A wrong sharing rule can expose sensitive data or prevent critical work. Test, test, test.
Person Accounts Are Still Contacts: Yes, I said it before. But it’s worth saying again. When you share a Person Account using an Account sharing rule, you’re implicitly sharing the associated Contact record too. If you have separate Contact sharing needs (which is rare with Person Accounts, but possible if you’re mixing standard Contacts and Person Accounts in complex ways), remember this.
Rule Order: Salesforce processes sharing rules in a specific order, but you generally don’t control that order directly. More permissive access always wins. So, if one rule gives read-only and another gives read/write, read/write access is what the user gets.
It’s a balance. You want to give access, but not too much. You want to keep it simple, but robust.
Beyond the Basics: Other Sharing considerations for 2025
While sharing rules are often the answer for Person Accounts, they aren’t the only answer. And looking ahead to 2025, how we manage permissions in Salesforce keeps evolving.
Permission Sets and Permission Set Groups are becoming increasingly important. While they usually deal with object and field-level security, they can also grant ‘View All’ or ‘Modify All’ permissions for Accounts, which would naturally include Person Accounts. I’ve found that using Permission Set Groups to bundle access permissions makes management so much easier. Instead of assigning multiple permission sets, you assign one group. This isn’t sharing rules, but it impacts the broader security picture, so it’s worth thinking about. They don’t replace sharing rules for granular record-level access, but they complement them by setting the foundation.
Also, for super specific, programmatic sharing needs that sharing rules can’t handle (like if you need to grant access based on a complex calculation or an external system’s data), Apex sharing might be needed. But honestly, most of the time, for Person Accounts, sharing rules will get you there. Apex sharing is way more complex, and frankly, overkill for most standard sharing requirements.
So, in 2025, the core principles of sharing Person Accounts haven’t changed much from 2024 or even 2020. You’re still relying on Account sharing rules. What has changed, maybe, is a greater emphasis on cleaner, more maintainable security models overall, using Permission Set Groups more broadly, and ensuring your data governance is top-notch.
Sharing Person Accounts correctly with sharing rules, it means your sales team sees the right customers, your service team supports the right cases, and your data stays secure. It’s a fundamental part of a healthy Salesforce org. Don’t skip on this, it’s too important.
FAQs: How To Share Person Account Using Sharing RulesHow do I share a specific Person Account with a single user?
You can’t do it with a sharing rule built for just one user; sharing rules are for groups, roles, or territories. For a single user, you’d use manual sharing directly from the Person Account record page (if OWDs allow and you have permissions). That’s often simpler for one-off needs.
Can I create sharing rules based on fields from the Contact part of a Person Account?
Yes, because Person Accounts are fundamentally Account records with Contact fields on them. Any field that appears on the Person Account layout, even if it’s technically a Contact field, can be used as criteria for a criteria-based Account sharing rule.
What happens if I have conflicting sharing rules for a Person Account?
Salesforce applies the most permissive access. If one rule gives Read Only access to a user for a Person Account and another rule gives Read/Write access to the same user for the same Person Account, the user will get Read/Write access.
Do sharing rules for Accounts automatically apply to related Contacts if the account is a standard business account?
No, not directly for standard Contacts. Account sharing rules control access to the Account record. Contact sharing is often tied to the parent Account (controlled by OWDs for Contacts), or you might need separate Contact sharing rules or other methods for granular Contact access. This is one of the distinct differences from Person Accounts where the Contact part is part of the Account.
Is it possible to make Person Accounts completely private by default and then open access selectively?
Yes, absolutely. To achieve this, you set your Organization-Wide Defaults (OWDs) for the Account object (which includes Person Accounts) to “Private.” Once they are private by default, you can then use sharing rules (or manual sharing, or role hierarchy) to open up access to specific users or groups as needed.
