Experience Cloud versus a custom customer portal: the questions that decide it
A native portal and a custom one are not really opposites. The comparison that matters is per role and per task. One yes or no for the whole project hides the answer.
By David, The Goodstack Company.
This is not really "Experience Cloud versus custom"
Most people ask the question as if there were two products to choose between. In practice there are at least three paths: configure the native portal your CRM already includes, add a third-party portal product on top of it, or build something custom that reads and writes to the same records. Each path can be right for one role and wrong for another, inside the same company.
The comparison worth making is not speed, price or which vendor sounds more capable. It is whether the task in front of a given role is something that platform can already do inside your edition, or something you would have to build no matter which path you choose.
Start with the role and action matrix
Before comparing platforms, list who needs the portal and what they need to do. Separate "do" from "see." A lot of portal disappointment comes from a role that needed to change a record being given a screen that only shows one.
| Role | Example task | Support conversation or transaction |
|---|---|---|
| Customer | Check an order or case status | Support |
| Customer | Change an address, request a return | Transaction |
| Partner | Ask about a deal, open a case | Support |
| Partner | Submit a price exception, update inventory | Transaction |
| Staff | Answer a question raised in the portal | Support |
| Staff | Approve a request that updates the record | Transaction |
Your own list will have different rows. Build it before you read the rest of this guide, because the answer below depends on it.
Support tasks versus transactional tasks
A support task ends with a conversation: someone reads a question and writes an answer, whether that happens through a case, a ticket or a chat. A transactional task ends with a record changing: an address, a quantity, an approval, a payment status.
Native portals, including Salesforce Experience Cloud and HubSpot's customer portal, are strong where the task is a conversation. A case, a question, a knowledge article and a status check are close to what the product does out of the box.
Where it gets harder is a transaction that follows a rule specific to your business: a custom object updating in a particular way, a validation that only makes sense for how you operate, a workflow that has to check something outside the platform before it lets the change through. That is configuration and development work inside the platform, the same as it would be anywhere else. The honest question is whether that work is smaller done inside your current platform, or smaller done as a purpose-built screen against the same data.
What stays your obligation, whichever way you build
A custom frontend does not change what you owe the platform behind it. If a portal reads or writes Salesforce or HubSpot data, it does so through that platform's API, and the platform's licences, seats, storage and usage limits still apply. Building outside the native UI does not remove them. We say this plainly because it is easy to hear "custom portal" and assume it replaces a contract. It replaces a screen, not a subscription, unless you separately decide to change what is underneath it.
Integration and API access by edition
Salesforce and HubSpot both gate certain objects, automation and API call volume by edition, and that gating changes over time. Before you commit to a native portal, a third-party product or a custom build, check your current edition's documentation for:
- The daily API call limit at your edition, and how close your expected portal traffic gets to it
- Which standard and custom objects your workflow touches, and whether they are exposed at your edition
- Whether external ID fields exist on those objects for safe write-back from outside systems
- What happens to automation, such as flows or workflow rules, when a record is changed through the API instead of the native UI
We do not repeat specific limits here, because they change by edition and by release. Reading your own account's current documentation, or asking your CRM administrator to, takes less time than it sounds like and settles arguments that otherwise run in circles.
A way to think about cost, without a price list
We do not publish a price list, because the scope decides the cost and we have not scoped your project. What we can hand you is the list of things that drive the number, so a quote from anyone is easier to evaluate:
- How many roles need access, and how different their permissions are from each other
- How many of their tasks are transactions rather than conversations
- How many systems beyond the CRM the task touches: an ERP, a document store, a payment processor
- What has to happen when something fails, and who is supposed to see it
- Who maintains the result after launch, and what that ongoing cost looks like
A scope built from that list, for one workflow, is something you can compare across native configuration, a third-party product and a custom build, using the same five questions each time.
A decision worksheet
Use this after you have your role and action matrix. It will not hand you an answer, but it will tell you what you still need to find out before choosing.
| Dimension | Question to ask before you choose |
|---|---|
| Transactional actions | Which of your role's tasks change a record, not just view one, and can your current platform do that at your edition today? |
| Integration reach | Which systems beyond the CRM does the task touch, and does the path you are considering reach all of them? |
| Ownership | If you build inside the platform, do you own the customization the way you own code in your own repository? If you build outside it, who owns what gets written? |
| Maintenance | Who upgrades and secures this after launch, and is that written down anywhere yet? |
| A real test | Can you try the workflow with a small group of real users before committing to a platform decision? |
When native configuration is the right call
If most of what your roles need is a conversation, a status and a document, and your current edition already exposes the objects involved, configuring the portal you have is very often the faster and cheaper answer. We would rather tell you that in a first call than scope something you did not need.
When a custom build is worth considering
It is worth a closer look when several roles need different, narrow slices of the same account; when the tasks are transactions with rules specific to your business; when the workflow spans more than one system and a failure in any of them needs a person to see it; or when the maintenance of a heavily customized native portal has become a project of its own.
Using this with us, or without us
This matrix and worksheet are useful whatever you decide, including staying with the portal you already have. If you want help filling them in, we do it with you as the second step of our process, after a discovery call, and you keep the result.