Key takeaways
- Put an API layer between the React front end and Salesforce; never call Salesforce directly from the browser with privileged credentials.
- Authenticate portal users in your own identity layer, then enforce exactly what each user may see on the server.
- Cache read-heavy data and use events or webhooks to keep it fresh, which protects Salesforce API limits.
- Design the portal around customer tasks, not around Salesforce objects.
Some businesses want a portal that feels like a modern web product rather than a configured site: fast, branded and combining data from Salesforce with billing, ERP or product systems. React is a popular choice for building that front end. The key is a sound architecture behind it.
Recommended architecture
| Layer | Responsibility |
|---|---|
| React front end | User interface, routing, forms and client-side state |
| Back-end API (backend for frontend) | Authentication, authorization, business rules, calls to Salesforce and other systems |
| Salesforce | Customer records, cases, orders, documents and automation |
| Cache or database | Fast reads for frequently viewed data; session data |
| Other systems | Billing, ERP, shipping or product data as needed |
Why not call Salesforce from the browser?
Anything in the browser can be inspected. A token with broad Salesforce access in front-end code would let a curious user query far more than their own records. Instead, the back-end API holds an integration credential, typically using an OAuth flow designed for server-to-server access such as the JWT bearer flow, and only returns data the logged-in customer is entitled to see.
Authentication and authorization
- Use an identity provider or your own authentication service for customer logins, with multi-factor options.
- Map each portal user to their Salesforce contact and account, for example with an external ID.
- On every request, filter data by that mapping on the server; never trust IDs sent from the browser without checking ownership.
- Log access to sensitive data for audit.
Designing the API
- Expose task-oriented endpoints such as “my open cases” or “my invoices”, not generic query access.
- Combine data from several systems in the API so the front end stays simple.
- Validate input on the server and return clear, safe error messages.
- Version the API so the front end and back end can evolve independently.
Performance and Salesforce limits
Salesforce allocates API requests per rolling 24-hour period. A portal that queries Salesforce on every page view can consume that allowance quickly. Cache data that changes infrequently, batch queries with composite requests, and refresh caches using Change Data Capture or Platform Events when records change, rather than polling.
Front-end practices
- Use a data-fetching library with caching and background refresh for a snappy experience.
- Render meaningful loading and empty states.
- Build accessible forms with clear validation.
- Measure Core Web Vitals and keep the JavaScript bundle lean.
When Experience Cloud is the better choice
If the portal mainly exposes Salesforce data with standard self-service patterns and a modest audience, Salesforce Experience Cloud may be faster and cheaper to deliver. A custom React portal shines for large audiences, unique experiences or data from many systems.
Our web development team builds React portals backed by Salesforce and other systems, with security designed in from the start.
Frequently asked questions
Can React run inside Salesforce?
Inside Salesforce, Lightning Web Components are the native framework. React is typically used for external portals and apps that talk to Salesforce through APIs.
How do portal users log in?
Usually through an identity provider or a custom authentication service, with each user mapped to their Salesforce contact on the server.
Will a custom portal hit Salesforce API limits?
It can if every page view calls Salesforce. Caching, composite requests and event-driven refreshes keep usage low.
