Connecting Salesforce to a custom-built customer portal removes the manual step that stalls every support and account team: instead of answering "where is my order?" or "what's my balance?" in email, your customers log in and see live Salesforce data — cases, invoices, orders, quotes — on their own terms. The connection is usually an API layer between the portal and Salesforce, either sync-on-login or event-driven.
TL;DR
- Salesforce exposes customer data through REST APIs your portal can call.
- Design the integration as sync-on-login or event-driven, not both at once.
- Scope a first portal around cases and invoices; quotes and billing come later.
- Identity, licensing and rate limits are the three decisions that break budgets.
Before you start
- A Salesforce edition with API access — Professional and Essentials editions limit or block REST API access; Enterprise and Unlimited include it. Check your edition before scoping, because the integration path changes if you cannot call the API directly.
- An identity approach — decide whether customers log into the portal with Salesforce Community (Experience Cloud) accounts, a separate identity provider, or email links. Changing this later means re-building login, not just a feature.
- The gotcha nobody budgets for: API rate limits. Salesforce caps API calls per day per org. A portal that re-fetches an account dashboard on every page view can burn a small org's daily quota in hours. Plan caching from day one.
Set up your Salesforce trigger layer
- Pick the object set the portal needs — typically Case, Invoice (or Invoice__c), Order, and Account. Map each portal screen to the objects and fields it reads.
- Create an integration user in Salesforce with the minimum object permissions the portal needs — read for display, create/edit only where the portal writes.
- Enable the REST API and decide your auth flow: OAuth 2.0 client credentials for server-to-server calls, or a connected app with refresh tokens if the portal acts on behalf of a logged-in customer. Salesforce's developer documentation details both flows and the daily API limits per edition.
- Verify with a test call: request
/services/data/vXX.0/sobjects/Casefor one test account. If you get a 200 with a case, the trigger layer is sound.
Expected result: the portal backend can read and write the Salesforce objects it needs, authenticated and rate-limit-aware.
Configure the sync design
Two patterns work; mixing them creates data conflicts:
Sync-on-login — when a customer logs into the portal, the backend calls Salesforce for their open cases, recent invoices and order status, caches the response for 15–30 minutes, and serves the cached view. Simple, secure, and cheap on API quota. Best when data freshness of 30 minutes is acceptable.
Event-driven — Salesforce Platform Events or outbound messages push changes (new case created, invoice posted, order shipped) to a webhook on the portal backend, which updates its own database. Best when customers must see updates within seconds, or when the portal needs history Salesforce does not store.
| Approach | Best for | Key limitation |
|---|---|---|
| Sync-on-login | Support and billing lookups for small customer bases | Data is as fresh as the cache window |
| Event-driven | Real-time order status, quote approvals, workflows that write back | More moving parts to monitor and secure |
| Hybrid | Most mid-size builds | Requires a deliberate cache and conflict policy |
Most mid-size builds land on hybrid: login-sync for the dashboard, event-driven for anything the customer acts on.
Set up the portal frontend
- Choose the portal stack. A custom React or Vue front end on a Node or .NET backend gives full control over branding and flows. Salesforce Experience Cloud is faster to launch but caps the custom workflows you can build without heavy development — Syndell's custom software development team scopes both paths from your existing Salesforce edition and workflow list.
- Build the customer screens in this order: login, case list and detail, invoice download, order status, and then the self-service actions (submit a case, pay an invoice, approve a quote).
- Wire write-backs deliberately. A customer submitting a case from the portal should create a real Salesforce Case, assigned to the right queue, with the portal conversation ID stored on the record so replies sync back.
Expected result: customers log in, see live Salesforce data, and can take self-service actions without emailing your team.
Customize your workflow (the second variant)
If your portal serves both customers and partners, the same integration layer supports a partner view: deal registration, inventory lookups, and co-branded quotes — each scoped by a Salesforce permission set per partner tier. Syndell's application integration practice has delivered partner and customer portals on the same Salesforce org where one data model serves both audiences with different visibility rules.
Troubleshooting
- Portal shows stale data — the cache TTL is too long for your ops team's tolerance, or the event listener stopped. Check the webhook delivery log before changing the cache.
- API limit errors mid-month — someone is polling. Move recurring reads to the cache layer and reserve API calls for writes and login-time refreshes.
- Case created in portal never reaches Salesforce — the write failed silently. Log every write with a correlation ID and surface failures to the portal admin, not the customer.
- Duplicate customer records — the portal matched on email but Salesforce dedupes on a custom external ID. Set one external ID field per customer and enforce it on both sides.
One last thing
The most common portal failure is not technical — it is scoping. Teams that spec every screen before launch ship twelve months later; teams that launch with login, case list and invoice download in ten weeks and add quote approval in phase two get adoption data that makes phase two worth funding.
