In September 2025, Salesforce started blocking most users from authorizing connected apps that aren't installed in the org. Since Spring '26, no org can create a new connected app at all unless Support switches the permission back on, and External Client Apps are the path forward. Neither change was aimed at customer portals. Both still landed on the admins who run one.
That's the pattern with portal decisions. Whether to build or buy gets treated as a developer question ("can we build this?") and settled at kickoff. Then the work that never stops, like permission reviews and release testing, moves to the admin team and stays there for years.
So this piece skips the feature comparison. It walks through the build-versus-buy decision for a Salesforce customer portal by asking one thing: what does each option leave on the admin's desk once the project team has gone?
It's Three Options, Not Two
"Build or buy" hides a split inside "build." Admins should name all three paths before anyone compares them.
Build on the platform. You stand up an Experience Cloud site, usually on an LWR template, and write custom Lightning web components and Apex for anything Experience Builder can't do out of the box. Every person who logs in is a Salesforce user on an external license.
Build off the platform. Your developers write a separate web app that talks to Salesforce through its APIs, authenticated through a connected app or External Client App and an integration user. Portal visitors aren't Salesforce users unless you add an identity license for them.
Use a pre-built product. Someone else has already written the portal. Depending on the product, it's either a package that runs inside Experience Cloud or an external app connected the same way as option two.
Those groupings matter more than the labels. A pre-built external portal shares its architecture with a custom off-platform build. What changes is who writes and maintains the code. So before you compare vendors with developers, work out which architecture you're signing up for.
Where Does "Who Sees Which Record" Live?
This is the question that sorts the options fastest, and it's the one admins get asked about least.
On the platform, it lives in your sharing model
On an Experience Cloud build, Salesforce enforces visibility for every portal user. Customer Community users get access through sharing sets, since that license has no roles. Customer Community Plus and Partner Community add external roles and role-based sharing rules. Unauthenticated visitors are tighter still. Secure guest user record access has been enforced since Winter '21 and can't be turned off. Guest users can't receive records through manual sharing, queues, public groups or Apex managed sharing, and the one remaining route, a guest user sharing rule, grants read-only access.
That's a strong default, and custom code can quietly undo it. An Apex controller declared without sharing, or a query that skips field-level security, will hand portal users records the sharing model would have hidden. Nothing in Setup flags it. You find it by reading code, so on-platform builds need someone who can review Apex before every release.
Off the platform, it lives in someone's code
An external app reaches Salesforce through one integration user, and that user can see whatever its permission sets allow. The sharing model stops there. Deciding that customer A sees only customer A's cases is now a filter inside the app.
If your developers wrote it, the filter lives in a repository the admin team probably can't read. If a vendor wrote it, it usually shows up as configuration. CRMJetty, for example, reads and writes through a connected app over OAuth 2.0, keeps the records in Salesforce instead of copying them, and scopes each portal user's access by contact or account in its admin settings. Either way, the integration user still needs tight permissions. Whoever builds the portal, it should never see more than the portal is meant to show.
The admin's test: ask your developer or vendor to show you where you'd change who sees what, without a deployment. If the answer is "open a ticket," you've learned who really owns your portal's security.
What Will It Cost Your Org's Limits?
Daily API requests are allocated per org over a rolling 24 hours. Enterprise Edition starts at 100,000 and adds a per-license allocation on top. The external licenses don't add much. Customer Community licenses contribute zero calls each, while Customer Community Plus and Partner Community contribute 200 each.
An off-platform portal, custom or bought, works through those APIs, so its traffic draws on the same pool as your ERP sync and every data loader job someone schedules overnight. An Experience Cloud site renders inside the platform and mostly runs into per-transaction Apex limits instead. Neither is free. They just break in different places.
Two practical steps cut most of the risk:
- Give the portal its own integration user. Enterprise, Unlimited and Performance editions include five Salesforce Integration user licenses at no charge. They're API-only, so a portal credential can't be used to log in to the UI. One integration user per integration also makes the API usage report readable.
- Ask for the call budget in writing. Before go-live, find out how many requests a typical portal session makes and whether the app caches reference data. Then check System Overview after the first busy week and compare it with what you were promised.
Who Absorbs the Release Calendar?
Salesforce ships three major releases a year. Each one is a test window for anything that touches your org, and the three options carry that load differently.
On-platform custom code carries the most. Every deployment to production needs at least 75% Apex test coverage with all tests passing, so a field change on the portal can turn into a test-class repair. There's also the template question. LWR sites run only Lightning web components, and Aura components don't work in them. A portal built on Aura custom components can't move to the newer runtime without rewriting those components.
Off-platform custom code sidesteps UI changes but not platform changes. API versions 21.0 through 30.0 were retired in Summer '25, and calls to them now fail outright. The connected app restrictions described at the top fall into the same category. Your web team has to track Salesforce release notes even though they never open Setup.
Pre-built products shift the code work to the vendor. Your job becomes checking that the vendor has certified the new release, and asking pointed questions. Do they support External Client Apps yet? What API version does the connector call? How quickly did they ship a fix the last time Salesforce broke something?
The Handover Test
The cost of a portal that nobody plans for is turnover. Try this test on each option. If the person who built it leaves next month, can the admin who stays add a field to the case form?
| What the admin inherits | Build on platform | Build off platform | Pre-built product |
|---|---|---|---|
| Visibility rules live in | Sharing model plus your Apex | App code plus integration user | Vendor settings plus integration user |
| Draw on daily API pool | Light | Every request | Every request |
| Release regression work | Your code, three times a year | API versions and auth changes | Vendor's job, your verification |
| Skill needed for a small change | Salesforce developer | Web developer on the app's stack | Admin, with vendor support |
None of these rows picks a winner. They tell you which skills you'll be paying for in year three.
When Building Is the Right Call
Building isn't the wrong answer, and admins shouldn't treat it as one. It's a good fit when:
- The portal is the product. If the customer experience itself sets you apart, say a configurator or a claims flow nobody else offers, generic portal software will hold you back.
- You already run a Salesforce development practice. Teams with source control, scratch orgs and a deployment pipeline can absorb one more app. A portal costs much more when it forces you to build that practice first.
- You need platform features inside the portal. Knowledge articles and Agentforce self-service components both live natively in Experience Cloud. Rebuilding them in an external app is expensive.
- The portal combines several systems of record. If Salesforce is one of four back ends, an off-platform app your web team owns may be the cleanest home for it.
Pre-built fits the other profile. Your requirements look like most companies' requirements, such as cases, orders, invoices and documents. The admin team has no spare developer hours. And the portal's forms and fields will change more often than its architecture will.
Questions to Settle Before Kickoff
Bring these to the first architecture meeting, whichever way you're leaning:
- Which of the three architectures is this, and who will maintain the code after launch?
- Where are visibility rules defined, and can an admin change them without a deployment?
- Which integration user does the portal run as, and what can that user see?
- How many API requests does a typical session make, and what's the daily budget?
- Who tests the portal against each release preview, and who signs off?
- Does the setup depend on creating a new connected app, or does it support External Client Apps?
In our work at CRMJetty, the portals that age badly are rarely the ones built on the wrong architecture. They're the ones where nobody wrote down who owns the integration user. Settle that before the build starts and either path can work.
Leave a Reply