APAC Architects

@Lena Wong

did you try checking the below articles - 

Which cloud are you utilizing ? Is it a std or custom component

Hi @Lena Wong

What you're seeing is generally expected behavior rather than a bug. Duplicate Rules are evaluated based on the values Salesforce considers to have changed during the DML operation. A

For historical records, a common approach is to perform a one-time backfill (Batch Apex or Data Loader update) to populate the helper field, then run a real update on the affected records so the duplicate engine re-evaluates them consistently. After all legacy records have been normalized, the duplicate behavior is typically consistent for both new and existing records.

So I'd consider this more of a platform optimization/edge case with legacy data than a defect in Duplicate Management itself.

@Lena Wong

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

Hi @Lena Wong

This is a great question and here are some considerations which you need to consider before making the decision.  

1. Before making the decision on single vs multiportal, I would analyze the following. 

a. Is the data model and objects same across all the 5 business units/ 

b. What are unique objects to be shared across BU and what level of security needs to be established? 

c. Are there users who need to have access across all BU or users are unique per BU? 

d. Are the branding requirements simple or complex which needs to be customized across BU? 

e. Who is going to own the support of the BU and is there a need for separate teams to manage the BU depending on compliance? 

f. Are there compliance/security requirements across BU due to geographies like Europe for GDPR, Asia etc which needs to be established across BU? 

g. Is there any sensitive data shared across BU portals and are there any specific criterias or requirements for access for it? 

If your answer is yes for most of these questions, a multiportal makes sense compared to a single portal. 

To answer your question on asset hierarchy, a custom lwc component can solve the problem with hierarchy given different product categories and layers.  

I will not expose any ERP technical IDs to portal users which will confuse them. I would have a formula field or custom logic to display meaningful names for customers/account data . Couple of questions to you. 

1. Can you share some insights on what kind of data are you exposing on these portals? i am assuming distributers, resellers or product level data? 

2. I am assuming your ERP has the master data for most of orders, products and categories. Curious to know if your ERP is SAP or what system is your ERP? 

Hi Lena, this is a really common challenge in large multi-vendor Salesforce implementations. I have worked through this exact scenario and here are practical answers to each of your questions: 

Q1 - HOW TO REPLACE THE EXCEL WITH TOOL-NATIVE VISIBILITY FOR NON-TECHNICAL PMs 

The key insight is that the Excel was serving two purposes: conflict prevention and stakeholder communication. You need to solve each separately. 

For conflict prevention in Copado/Gearset: 

- Copado: Use "User Stories" with proper branch policies. Enforce that every change must be tracked in a User Story before it can enter a pipeline. The User Story list IS your living inventory - replace the Excel with the Copado backlog board (which non-technical PMs can view) 

- Gearset: Enable "Deployment Conflict Detection" - it automatically flags when two deployments touch the same metadata component. Pair this with Gearset's deployment history log (shareable via URL) for PM visibility 

- Both tools: Set up Slack/Teams notifications that fire when a deployment is initiated and completed - PMs see activity in real time without a spreadsheet 

For non-technical stakeholder visibility: 

- Copado has a built-in "Release" view that shows all User Stories going into a release - share this URL with PMs 

- Create a simple Salesforce Dashboard in your Salesforce org (or a Jira board) that maps to your deployment pipeline stages - PMs understand Kanban boards 

Q2 - HANDLING METADATA CONFLICTS WITHOUT A SHOPPING LIST 

- Use source-driven development: everything goes through Git first. Even the client Admin should commit changes via VS Code or SFDX before deploying. This makes Git the single source of truth, and conflicts surface in the branch/PR process, not at deployment time 

- Enforce protected metadata policies: In Copado, set "Locked" metadata components (like Global Picklist values) as protected components that require a change request to modify 

- For Picklist specifically: document a Picklist governance policy - only one team "owns" each Picklist - and use Copado's conflict resolution UI to manage conflicts visually instead of via Excel 

- In Gearset: use "Deployment Monitoring" + "Org Comparison" to see exactly what the internal Admin changed in production since the last Git sync 

Q3 - LIGHTWEIGHT AUDIT TOOLS FOR UNMANAGED SANDBOXES 

These are the tools I recommend for quickly identifying components created in unmanaged sandboxes: 

1. Salesforce Inspector (Chrome Extension) - FREE: Instantly shows all metadata in an org, lets you export object lists, field lists, etc. Great for quick inventory 

2. SFDX CLI + "sf org list metadata": Run sf org list metadata --metadata-type CustomObject to get a full list of metadata by type - much faster than manual Excel inventory 

3. Gearset's Org Comparison: Compare the sandbox directly against your Git repo baseline to see what's drifted - produces an exportable diff report 

4. Copado's "Commit Changes" screen: Shows you everything in a sandbox that hasn't been committed to Git yet - essentially your untracked component list 

5. Salesforce's own Setup Audit Trail: Export it (limited to 180 days) to see recent configuration changes 

OVERALL RECOMMENDATION: 

Make Git the mandatory first step for everything. The Excel shopping list exists because people bypass Git - once you enforce Git-first (via branch protection rules and CI/CD gates), the Excel becomes redundant. Start with Copado/Gearset's conflict detection and replace the Excel one team at a time. 

Hope this helps your implementation!

As Ravi said, knowing the order of execution is key here. "After" flows run after the record has been committed to the database, so any updates to the triggering record are considered, well, updates. 

Generally, when changing a field value on the triggering record, use a "Before" flow. Would that be something you could do? Keep in mind that Before flows run before before triggers (again, knowing the order of execution is key), so consider all automations on that object before making changes.

Scenarios Where Leads are Converted into Opportunities

1. Direct Sales Opportunities (B2B Sales)
   • When a lead expresses serious buying intent, has budget approval, and matches your target customer profile, converting to an Opportunity is essential.
   • Example: A company requests a detailed proposal for a SaaS subscription, and the decision-making process requires tracking stages such as Negotiation and Procurement.
2. High-Value Deals with Long Sales Cycles
   • Complex deals involving enterprise clients require creating Opportunities to manage deal stages, revenue forecasting, and collaborative tracking.
   • Example: Selling heavy machinery where discussions, demos, and legal approvals span several months.
3. E-commerce or Product Purchases with Multiple Stakeholders
   • In situations where the sales team needs to negotiate terms, discounts, or upsells, Opportunities become necessary.
   • Example: A lead requests a bulk purchase of electronics requiring price discussions and approvals.
4. Partnership Deals
   • If a lead represents a strategic business partner, creating an Opportunity allows tracking co-branded projects or joint ventures.
   • Example: A lead from a distribution channel that will promote your services.

Scenarios Where Lead Conversion into Opportunities is Not Needed

1. Marketing-Nurtured Leads
   • When leads require further nurturing before they are ready for sales, skipping Opportunity creation avoids cluttering the pipeline.
   • Example: A user downloads an eBook or attends a webinar but has no immediate purchase intent.
2. Low-Priority Leads (B2C Sales)
   • For small-scale, transactional sales without complex stages, converting to Opportunities may not be efficient.
   • Example: A lead wants to purchase a standard subscription plan online.
3. Informational or Inquiry Leads
   • Leads who request product information or support but have no budget, authority, or intent to buy.
   • Example: A prospect asking about software compatibility for future consideration.
4. Post-Sales or Support Requests
   • Leads that do not involve new revenue potential but are related to existing customer inquiries.
   • Example: A customer asking for training on already-purchased software.

Scenarios Where Leads are Converted into Existing Opportunities

1. Team-Selling Scenarios
   • Multiple contacts or departments within the same organization contribute to a single Opportunity.
   • Example: A lead from the finance team complements an existing Opportunity initiated by the IT department.
2. Re-engagement of Stalled Opportunities
   • New leads from the same account bring renewed interest to previously inactive Opportunities.
   • Example: A lead provides new budget approval for a stalled deal.
3. Cross-Selling and Upselling
   • When a lead is interested in additional services or upgrades related to an active Opportunity.
   • Example: A customer considering additional warranties or services after initiating a product purchase.
4. Avoiding Duplicates
   • Prevent duplicate Opportunities by linking the lead to an existing one.
   • Example: A marketing campaign generates duplicate leads from the same company already in the pipeline.

Most Common Real-World Scenarios

• Opportunities are created for:

• Deals requiring tracking, forecasting, or multiple stages (e.g., enterprise sales, long sales cycles, or partnerships).
• Opportunities are avoided for:

• Leads not sales-ready, transactional in nature, or aimed at marketing/educational purposes.