Table of Contents
So, getting Person Account record pages to pop up for external users in Salesforce, especially now in 2025? Yeah, it’s a whole thing. Not always straightforward, you know? It’s not like flipping a switch. People think, “Oh, it’s just a record page, what’s the big deal?” But when you toss in external users, Community Cloud – or Experience Cloud, whatever we’re calling it this week – it gets real messy, real fast.
I mean, Salesforce built Person Accounts for a reason: individuals as customers, not just contacts on a business account. Great idea. For internal users, it’s mostly fine. But then a client says, “We want our customers to see their own data, their past orders, their details, all on their personal page in the portal.” And suddenly, you’re diving deep into sharing models, profiles, and frankly, a bunch of stuff that feels like it should just work. It doesn’t.
Why It’s Not Simple: The Core Conflict
The basic issue boils down to how Salesforce handles data access for external users. Standard objects like Account, Contact, Opportunity – they have clear sharing rules. But Person Accounts are weird; they’re kind of a hybrid. They act like an Account but show up as a Contact. This dual nature messes with the standard external sharing model. External users usually connect via Contacts, and the system wants to tie that contact to a business account. Person Accounts are the business account in this scenario. That’s the first hurdle, the fundamental design clash.
Plus, external users have different license types. Community User, Customer Community Plus, Partner Community. Each has its own limitations, its own access levels. You don’t just throw a standard Salesforce license at them. You can’t. security is a beast, right? And Salesforce locks it down hard for external folks, which is good, but also a pain when you just need them to see their own stuff.
Getting Started: Laying Down the Groundwork
Before you even think about sharing Person Accounts, you gotta have your Experience Cloud site up and running. That’s non-negotiable. And those external users need to be set up correctly, with the right licenses and profiles. If you’re trying to do this without a solid portal foundation, you’re just building on quicksand.
First off, check your Organization-Wide Defaults (OWD). For Accounts, if it’s set to Private, you’re going to have to do a lot more work. If it’s Public Read Only or Public Read/Write, some of your battle is already won. But generally, for external users, OWDs usually won’t give them direct access to Person Accounts by default. You have to open the gate, sometimes just a tiny crack.
The Profile/Permission Set Tango
This is where I usually start. You need to give external users the right to even see the Person Account object. Sounds obvious, right? But it’s easy to miss.
Head to the Profile or Permission Set assigned to your external users. Make sure the ‘Account’ object has at least ‘Read’ access. And here’s the kicker: ensure ‘View All’ or ‘Modify All’ isn’t checked unless you really, really know what you’re doing. Because that throws open the barn doors. For Person Accounts, since they’re just glorified Accounts, giving Account read access is step one.
But that’s just object-level security. That doesn’t mean they can see specific Person Account records. It just means the object isn’t completely hidden from their view. It’s like having a library card; you can enter the library, but you still need to find the book.
After you set object permissions, dig into Field-Level Security. Are all the fields they need to see on the Person Account page visible? If a field is hidden at the FLS level, it doesn’t matter what you do with sharing rules; they won’t see it. This is a common trip-up. I’ve spent hours trying to debug why a user can’t see an address, only to find out it was FLS all along. Happens.
Sharing Models: Opening the Gates (Carefully)
Alright, so the profile or permission set says they can see the Account object. Now, how do they see their Person Account record?
1. Account Relationships: The simplest way, if it applies, is if the external user’s Contact record is directly linked to the Person Account. For example, if the external user is the Person Account (meaning, their Contact record is the Person Account record). This is often the case. In such scenarios, the ‘Account Owner’ role might be key. If the external user’s Contact is related to their Person Account and they are set as a “Customer User” or similar, they often gain access to that specific Account record because they are implicitly the “owner” or related contact. It’s a bit like, if I own a house, I can go inside. Salesforce usually just lets the connected user see their own Person Account.
But what if they need to see other Person Accounts? Say, a family member’s Person Account, or maybe they manage a group of individuals? That’s where it gets complicated.
2. Sharing Rules: You can create sharing rules for Person Accounts, but it’s not as clean as standard accounts. You’ll often need to base these on criteria or ownership. For example, a criteria-based sharing rule: “Share all Person Accounts where ‘Custom Field XYZ’ equals ‘Value ABC’ with users in this public group.” This works for broader access but might expose more than you intend. And remember, external users exist in a specific role hierarchy within the portal, not necessarily the main org’s role hierarchy. Setting up role-based sharing for external users means you’re sharing based on their portal role, which is different.
3. Manual Sharing: This is for one-off situations. You can manually share a Person Account record with an external user, just like any other record. But who’s got time for that? It’s not scalable.
4. Apex Managed Sharing: This is where things get serious. If your sharing requirements are complex – “User A can see Person Account B only if they attended the same event,” or “User C can see Person Account D if they’re in the same household” – you’re probably looking at Apex. You write custom Apex code to manage the `AccountShare` object directly. This gives you ultimate control, but it also means custom development, more testing, and ongoing maintenance. For what it’s worth, I’ve seen some pretty gnarly Apex sharing solutions. Sometimes, trying to untangle Salesforce permissions feels like trying to pull on a sweater that’s three sizes too small; I always wrestle with it. But custom code usually wins if you need something super precise.
Custom Pages & components: When Standard Won’t Cut It
Let’s be real. The standard Person Account record page, even if shared, might not be what your external users need. They might need a simpler view, or aggregated data from related objects that are also hard to share. This pushes you towards custom UI.
Building Custom UIs for External Views
Lightning Web Components (LWC): If you’re building an Experience Cloud site in 2025, LWC is probably your go-to. You can build custom components that query Person Account data (and related objects) using Apex controllers. This gives you full control over what data is fetched and how it’s displayed. You can implement all your sharing logic directly in the Apex, then only pass the relevant data to the LWC. This approach is powerful. It bypasses some of the clunkiness of standard sharing models for complex scenarios because your code dictates what data gets shown, not just out-of-the-box Salesforce sharing rules. You can filter records based on the logged-in external user’s relationship, permissions, or custom criteria.
Visualforce Pages: Older sites, or if you just prefer Visualforce, it’s still an option. You can embed Visualforce pages on an Experience Cloud site. A custom controller could fetch Person Account data, again, with your own logic controlling visibility. Not my first choice these days for new stuff, but it works.
Experience Builder Components: Sometimes, you can get away with just configuring standard components in Experience Builder. If the data is shared correctly through OWDs or simple sharing rules, standard record detail components or related lists might just work. But this is rare for complex Person Account sharing to external users. Usually, it’s not enough.
Staying Safe: Security First
Look, the most crucial part of this whole dance is security. You cannot just blast all Person Account data out to external users. Every single method you use – OWDs, sharing rules, Apex, custom components – must be scrutinized for over-sharing. External users are, well, external. They don’t need to see everything. They just need to see their stuff, or stuff directly relevant to their interaction with your business.
I always tell folks: if you’re not sure, over-restrict. Then slowly open up access bit by bit, testing every single step as an actual external user. Get a dummy external user, log in as them, and click everything. Can they see records they shouldn’t? Can they edit things they shouldn’t? It’s a pain, but better safe than sorry. Data breaches are no joke.
Final Thoughts: A Constant Evolution
Showing Person Account record pages to external users is less about one perfect solution and more about picking the right combination of tools for your specific needs. It’s often a blend of OWDs, specific sharing rules, and almost always some level of custom UI or Apex to fine-tune the experience and keep things secure. Don’t expect it to be a quick setup; it never is. This area of Salesforce often requires careful planning, deep understanding of your data model, and a willingness to get into the nitty-gritty of permissions and sharing.
So that’s how it goes, more or less. Not easy, never simple, but definitely doable if you put in the time.
Frequently Asked Questions:
1. Can external users see Person Accounts directly without any special configuration?: No, absolutely not; external users generally require specific sharing rules, profile/permission set updates, or custom development to view Person Account record pages; standard settings usually restrict this access.
2. What Salesforce licenses are typically required for external users to view Person Accounts?: Customer Community, Customer Community Plus, or Partner Community licenses are the most common, each offering different levels of access and capabilities, but none inherently grant full Person Account visibility without further setup.
3. Is it better to use sharing rules or Apex for Person Account visibility for external users?: It really depends on the complexity; simple, broad access might work with criteria-based sharing rules, but for highly specific, dynamic, or complex sharing requirements, Apex Managed Sharing is often the only way to get it done precisely.
4. What are the biggest security concerns when exposing Person Accounts to external users?: Over-sharing data is the primary concern; ensuring that external users can only see their own relevant data and nothing else, like other customers’ information or sensitive internal fields, is a constant challenge.
5. Can I use standard Lightning components in Experience Cloud to display Person Account data to external users?: Sometimes, yes, if the underlying sharing model (OWD, sharing rules) is already allowing the necessary access; but for more granular control, custom Lightning Web Components (LWC) with Apex controllers are usually needed to filter and display the data exactly as required.
