Hi Trailblazers,
I am currently evaluating the architecture for a B2B customer portal using Experience Cloud. I would like to get a clear technical understanding of how Salesforce handles duplicates during user self-registration, and whether utilizing Screen Flows or LWC is truly necessary for this specific validation.
My questions are:
- When enabling the native Configurable Self-Registration under the Login & Registration settings, what exactly happens behind the scenes if a potential user tries to register with an email address or any data that already exists in the system? Does Salesforce natively block the registration and throw an error message, or does it require manual implementation of Duplicate/Matching Rules?
- Does the standard self-registration mechanism only check for existing User records (login credentials), or does it also prevent creating duplicate Contact records if the email already exists in the CRM as a prospect or sales contact?
- Would you suggest using a custom Screen Flow on the public site to handle the registration intake and manually query for duplicates?. From a security and architecture perspective (especially running under the Guest User context), is a Flow recommended for this? Or is it better to stick to the native self-registration backend, perhaps customizing only the UI layer via a Lightning Web Component (LWC)?
I want to avoid reinventing the wheel if Salesforce already handles these validations natively, but I also need to ensure a clean user experience (UX) without data duplication.
Looking forward to your architectural insights and best practices!
Thanks in advance! @Salesforce Administrators & Developers, @Salesforce Administrators and Developers, @APAC Architects
Good architectural questions, Lena, and you're right to dig into this before building, because the default behavior surprises a lot of teams. Let me take your three questions in order.
On what native Configurable Self-Registration does when duplicate data comes in. This is the part that catches people out. Out of the box, the handler does a fairly narrow check. It can match an existing record and update it rather than create a new one, but it does not natively enforce your org's Duplicate Rules and Matching Rules the way a normal record save through the UI would. The self-registration path runs through the registration Apex handler and is not guaranteed to honor your declarative duplicate rules. So the honest answer is it does not robustly block duplicates for you. Treating native self-registration as a complete duplicate prevention layer is a mistake.
On whether it checks only User records or also Contacts. This is the crux of your concern. The native mechanism is primarily concerned with the User and login identity. When someone registers, Salesforce creates or matches a Contact and then provisions a User tied to it. The handler can be configured to look for an existing Contact by email and link to it, but that's configuration dependent, not automatic. So if an email already exists in the CRM as a sales prospect or Contact, native self-registration does not reliably prevent a second Contact unless you've built the matching logic to catch it. The duplicate-Contact scenario you're worried about is a real risk with the pure native setup, especially in B2B where the same person often already exists from sales activity.
On the architecture question. Here I'd push back gently on one part of your framing. A Screen Flow running under Guest User context on a public page is something I'd be cautious about for registration intake. Guest User has been progressively locked down for good security reasons, and giving it the query and create access needed to check for and provision users widens your attack surface in ways that are hard to control. You can do it, but you're taking on the security ownership.
The pattern I'd recommend for a B2B portal: keep the native self-registration backend as your foundation, because it handles User provisioning, license assignment, and the security-sensitive parts you don't want to hand-roll. Then customize the registration handler Apex class, which is where the real control lives. Inside that handler you can run explicit SOQL to check for existing Contacts and Users by email, apply your matching logic, and decide whether to link or create. This runs in a controlled system context rather than relying on Guest User permissions, which is the security advantage. For the UI, a custom LWC gives you the clean UX and inline validation you want while still posting into that controlled backend.
So the layering is: custom LWC for the front-end experience, native self-registration as the provisioning backbone, and a customized Apex handler as the place where you enforce duplicate prevention with real query logic. Clean UX, avoids reinventing the hard parts, keeps duplicate logic in a secure context.
Two things to decide deliberately as you design this. First, your matching key. Email is obvious, but in B2B you often have the same person across multiple accounts or shared inboxes, so decide whether email alone is your uniqueness rule or whether you need email plus account context. Second, plan for the "Contact already exists from sales" case explicitly, because it's the most common real-world collision in B2B. Linking the new portal User to the existing Contact is usually the right call so the portal and sales relationship stay unified, but it has ownership and sharing implications worth thinking through.
To directly answer your "avoid reinventing the wheel" goal: there is no robust duplicate prevention for self-registration natively, so you can't skip that logic. But you also shouldn't rebuild the whole provisioning stack. The sweet spot is native backend plus customized handler plus LWC, which reuses the wheel where it's solid and only adds custom code where Salesforce genuinely leaves a gap.
-SP
