Experience Cloud versus a custom customer portal: the questions that decide it

This is not really "Experience Cloud versus custom"

Compare three implementation paths against the same customer task:

1. Configure Experience Cloud. Ask what your licensed setup can deliver through its available configuration and components, and which parts need development.
2. Use a packaged portal. Ask its supplier to demonstrate your roles, records and required operations against your intended systems.
3. Build a custom portal. Specify the screens, access controls, integrations and ongoing work your team would own or commission.

Keep all three open until you have evidence. A transaction, several user roles or an external system is a requirement to investigate. None of those facts alone establishes that custom development is necessary.

Start with the role and action matrix

List who needs access, what they may do and who owns the final record. Separate a request from permission to carry it out. These are example requirements, not a claim that a named product has implemented them.

Use the customer portal requirements worksheet to add the source system, denied actions and expected result to each row. Its completed address-change example supplies the same requirements to every option you compare.

Support tasks versus transactional tasks

Distinguish the customer's purpose from the records changed underneath it. A support conversation can create or update a ticket. A transactional request may need approval before a source record changes. Test the full sequence in either case.

Salesforce's Experience Cloud security guidance, checked October 25, 2026, discusses both declarative and custom access models, Apex access and flows for external users. It recommends limiting flow access to the profiles or permission sets that need it. Evaluate those available approaches before assuming a transactional workflow needs an external frontend.

HubSpot's support portal setup guide, updated August 13 and checked October 25, 2026, describes a ticket portal available with Service Hub Professional or Enterprise. It says only tickets appear there and distinguishes the updated experience from its legacy customer portal. That is a boundary of the documented portal, not a conclusion about every HubSpot app or integration.

These are documentation findings. We have not tested either product against your requirements or account configuration.

What stays your obligation, whichever way you build

List the systems you intend to retain. Treat their licensing, access, storage and usage assumptions as items to confirm with your administrator and supplier in writing. A proposal for a different frontend should say explicitly which subscriptions remain and which, if any, would end. Get the supplier to confirm any proposed removal of a retained system's subscription or access license.

Salesforce's external user license documentation, checked October 25, 2026, ties user access to license permissions and describes member-based and login-based options. Record the proposed license, applicable objects and expected usage for each role. This guide does not determine your contractual entitlements or substitute for an account-specific access review.

Integration and API access by edition

For each proposed path, have its implementer record:

• The product, edition, license and administrator who can confirm access.
• The exact read or write operation, fields and authentication method.
• The account and record permissions, including a denied-access test.
• The expected usage, counting window and other integrations sharing an allowance.
• The behavior after rejection, a repeated submission or an uncertain write result.
• The automation triggered by an accepted change and who investigates a mismatch.

Our platform limits guide explains how to read allowances. Its figures are dated examples; check current documentation and your account before sizing work. Record an unverified operation as unknown. A general API description does not establish that the proposed connector performs it correctly.

A way to think about cost, without a price list

Request comparable scope for the same roles and tasks. Separate setup work from recurring charges and staff time:

• Setup: configuration or development, integration, data preparation and acceptance testing.
• Recurring: retained licenses, packaged-product charges, hosting, usage and monitoring.
• Staff work: access administration, approval, exception handling and support.
• Change and exit: upgrades, regression checks, exports, documentation and handover.

Use the same evaluation period and usage assumptions for all three options. Label unknown costs and who will resolve them. Include continued manual handling of exceptions. A smaller build estimate does not settle the total operating comparison. Copy these inputs for each option; leave unknowns marked and unpriced. This is a comparison method, not a savings or delivery-time promise.

Option, evaluation period and expected usage:
Setup cost:
Recurring charges per period and number of periods:
Staff hours and the internal cost basis used:
Change and exit work included:
Known-cost subtotal = setup + recurring charges × periods + staff cost + change/exit work
Unknown cost / owner / next check:

A decision worksheet

Make one copy for each option. Beside every answer, record the evidence, date, reviewer and unresolved work. Use documented, demonstrated in the proposed setup, failed in that setup or not checked. Keep the configuration used for a test with its result.

Use one unresolved result to choose the next step

Synthetic demonstration: invented records. Reuse Cedar Services request R-014 from the requirements guide. The exercise proposes an approved address change whose response is lost after the source system writes it. No product or connector has been tested here.

Ask each option's implementer to explain how staff establish the stored address before another attempt. A diagram records a proposed design; a recorded execution in the proposed setup is test evidence. If the implementer has not run the case, record not checked and name the next test. If a test produces an incorrect confirmation, record the observed failure and configuration. Neither entry warrants an invented vendor score.

Use invented or sanitized records. Keep credentials and customer records out of shared evaluation packets. Compare the evidence and unresolved work before choosing an implementation path.

When native configuration is the right call

Favor configuration when the proposed setup satisfies the required actions and access boundaries, your team can operate it, and its documented costs and maintenance responsibilities fit. Ask for evidence of the whole task, including exceptions. A configured path can remain the best fit even when it includes some development.

When a custom build is worth considering

Consider a custom build when a defined gap remains after evaluating configuration and packaged options, and the proposed custom work has a testable scope and an accountable operating owner. Require the same evidence for it. A custom proposal with unresolved access or recovery behavior has unresolved work too.

You can also narrow the task or retain a manual step while investigating a critical unknown. A critical access, account-isolation or recovery unknown must be resolved before wider use, even if other criteria pass. The decision should identify the supported next step and what must be verified.

Using this with us, or without us

Take the same worksheet to every supplier. If you want help comparing the paths, bring the system names, roles and one action that remains unresolved. Our portal development overview explains the work we scope. Please leave out credentials and customer records.

Discuss a portal project