he customer wants to see their data in real time" is one of the most expensive sentences in a portal requirements document, because three different requirements hide inside it and only one of them is usually the real one.

Freshness is how old the number on screen is. Propagation is how quickly a change in Salesforce reaches that screen. Authority is whether the number the customer is looking at is the same number your rep would read out on the phone.

Customers almost always want authority. Engineering effort almost always goes into propagation. That mismatch is why portals ship with sub-second streaming widgets and still generate tickets that begin "your portal says one thing and your account manager said another."

What the widget is actually allowed to see

Before any of the plumbing, settle what the query returns, because the Experience Cloud sharing model does not behave like the internal one and this is where widget projects quietly go wrong.

The external license types differ in ways that matter for a data widget. Customer Community has no role support at all, so access is driven primarily through sharing sets. Customer Community Plus adds external roles, configurable up to three per account by default, and lets you write sharing rules with role-based criteria. Partner Community gives you the three-tier hierarchy of Partner User, Partner Manager and Partner Executive, rolling up to the internal account owner's role.

Sharing sets are the workhorse here. They grant access by relationship, matching a field on the record against the logged-in user's Account or Contact, and they cover cases, orders, and custom objects tied to those relationships.

Note the boundary. A sharing set matches on the relationship, not on arbitrary field values. You cannot express "and Status equals Open" in a sharing set. Plenty of widget specs assume you can.

Aggregates are where the sharing model bites

A single record on a page is straightforward. Totals are not, and a data widget is usually a total.

Consider a widget reading "Open orders: 14, value $212,000." That number is an aggregation across records, and it's only correct if the set the widget aggregated is exactly the set the user is entitled to see. Two ways to get that wrong, and they fail in opposite directions.

Compute the total in a context with wider access than the user's, an Apex class running without sharing being the usual culprit, and you have leaked information. Nobody sees a record they shouldn't, but the customer now knows their account has more orders than the list shows them, and in a partner or multi-account scenario the aggregate can expose the existence of records belonging to a sibling account.

Enforce sharing properly, and the widget is correct but may disagree with what your internal team sees, because the internal view includes records the customer's sharing configuration excludes. That's not a bug, and it will still be reported as one.

The rule worth adopting is that any aggregate shown to an external user should be computed under that user's own access, in with sharing context, and should be reconcilable by clicking through to the list of records that produced it. If a customer can't click the number and see the fourteen orders, the number will eventually be disputed and nobody will be able to settle it.

Push, poll, and what each actually costs

With scope settled, propagation becomes a straightforward engineering choice rather than a philosophical one.

Polling on view is the boring option and it is correct far more often than it gets chosen. The customer opens the page, the widget queries, the data is current as of that moment. Cost is one query per view.

Push is the interesting option. Platform Events and the Pub/Sub API let a change in Salesforce notify a subscriber without being asked, and Salesforce retains streaming events for up to three days, which lets a client that dropped its connection catch up rather than miss the interval. For a genuinely live surface, a case feed a customer is watching during an incident, a shipment moving through checkpoints, this is the right architecture.

The cost is not the event delivery. It's everything around it: a subscriber that has to stay connected, replay handling for the reconnect case, and an authorization question that gets awkward fast, since the event stream itself doesn't know about your sharing model. Filtering a push stream down to what one external user is entitled to see is work you do yourself.

Which is why the honest default for most portal widgets is polling on view with a visible timestamp, and push reserved for the two or three surfaces where the customer is actually watching the screen waiting for something to change.

The number that starts arguments

Here's the part that cuts against how portal vendors, mine included, talk about this feature.

We sell live. Real-time dashboards, live record visibility, always-current data. And a number that changes while you're looking at it is genuinely impressive in a demo.

In production, an undated number is a liability. A customer reads "Balance: $4,200" at 9:14, calls at 9:40 about something unrelated, and your rep quotes $3,900 because a payment posted. Now you are not discussing the payment. You are discussing whether your portal can be trusted, and that conversation costs more than the one you were trying to avoid.

A stale number that says "as of 09:14" survives that call. A live number without a timestamp does not. Freshness without attribution isn't a feature, it's an unfalsifiable claim, and the fix costs a line of markup rather than an event architecture.

The same logic applies to anything derived. If a widget shows a status that your system computes rather than stores, "On track", "At risk", show the inputs or show the rule. A customer who cannot reconstruct why the light is amber will call to ask, and you will have built a widget that generates contacts.

A design that survives contact with customers

What tends to hold up over a couple of years of production use is fairly plain.

Query under the user's own access, always. Stamp every widget with the time the data was read, and make that stamp visible rather than a tooltip. Make every aggregate clickable through to its constituent records. Poll on view by default and reserve push for surfaces where the customer is genuinely waiting. Show the rule behind any computed status.

None of that is architecturally exciting and all of it removes a category of support contact. Portal products in this space, CRMJetty included, ship widget layers that handle the sharing-aware query and the refresh behavior so the build is configuration rather than Apex, which is worth something on the second and third portal. It doesn't decide the design questions above. Those are yours regardless of what you buy or build.

When live really is the requirement

Sometimes the customer does mean propagation, and it's worth recognizing when.

Incident and outage surfaces qualify. During an active incident customers refresh, and a page that updates itself measurably reduces inbound contacts. Anything that behaves like an auction or a booking queue qualifies, since two customers acting on stale availability produces a conflict a timestamp cannot fix. Logistics tracking during the final delivery window qualifies for the same reason.

Everything else, order history, invoices, case lists, entitlement balances, is a freshness and authority problem wearing propagation's clothing. Build those as polled, timestamped, reconcilable widgets, spend the saved effort on the sharing model, and the portal will produce fewer arguments than the one with the live streaming dashboard.