What Should a Customer Portal Show When ERP Data Is Stale?

A customer portal should distinguish the last known business state from the last successful source check. When source data is too old for the decision, explain what cannot be confirmed, stop actions that require current information, and give the customer a clear route to an accountable operator. Access checks still apply to every record and document.

A customer opens an order page. It says “Ready to ship.” The ERP connection failed earlier that morning. The page loads quickly, the customer is logged in, and every component looks healthy.

The unresolved question is whether the customer can rely on that status now.

This is a product decision as well as an integration problem. A cache can keep a portal available during an outage. It cannot decide whether an old value is safe to act on. That needs an explicit rule for the workflow.

Separate the order's age from the connection's age

A status may have remained unchanged for three days while the connection was checked successfully a minute ago. Another status may have changed recently in the ERP but never reached the portal.

Those situations need different messages. Record the source's business timestamp where available, when the portal last successfully checked the relevant source, and whether that check covered the requested record. A successful connection to an unrelated endpoint is insufficient evidence that this order is current.

Avoid resetting “last checked” when the page merely reads its own cache. Otherwise a failed source connection can produce a reassuring timestamp on every refresh.

HTTP cache freshness is a separate layer. RFC 9111 defines HTTP caching, but also distinguishes application use of retrieved data from HTTP cache behavior. A response freshly served by the web application may still contain an old ERP snapshot. Document both layers when investigating the discrepancy. RFC 9111, application caching

Agree on what the customer may do with each field

The useful question is what an incorrect value would cause the customer to do.

A historical invoice and an inventory promise have different consequences. An invoice may remain useful during a source outage if its identity and version are established. A displayed stock quantity may be unsuitable for confirming an order without a current check or reservation in the authoritative system.

For each field or action, agree on the source, freshness rule, customer message and fallback owner. There is no universal refresh interval that makes every portal reliable.

These are design options to evaluate, not default settings to copy into production. A workflow that promises immediate confirmation may need to refuse the action until the source recovers. A workflow with a documented manual review step can make a different choice.

Work through one outage before expanding the portal

Consider a fictional distributor portal. These times and thresholds are illustrative acceptance rules, not measured customer results.

At 10:00, the portal successfully checks Account A's order. At 10:20, the ERP connection fails. At 10:25, the customer opens the order. The business has agreed that this status may be displayed for up to 30 minutes after a successful check, provided its age is visible. A shipping-address change always requires confirmation from the source system.

At 10:25 the portal shows the last known status, says it was checked at 10:00, and explains that an update is currently unavailable. It does not promise that the order will ship today. The address-change action cannot report success from a local screen alone.

At 10:31 the status crosses the agreed display limit. The portal replaces the operational status with “Current status unavailable” and provides a support reference. It can retain a clearly separated history if that history is authorized and useful. Repeatedly refreshing the page does not renew the old snapshot's age.

The internal tool should now show the affected order, last successful check, failed operation, responsible queue and customer reference. A page-wide banner without an internal work item leaves the operator to reconstruct the problem.

When the connection returns, a successful check for this order supplies a new status and timestamp. A recovered health check alone should not clear every affected customer's exception.

Keep permissions current even when business data is old

Displaying a retained snapshot does not establish permission to read it. A user removed from Account A must not regain access by opening a saved order URL or switching back to an old browser tab.

OWASP recommends object-level authorization for API operations on identified objects. For a portal, that means checking the requested record and action against the caller's permissions. A signed-in user or an account identifier supplied by the browser is insufficient by itself. OWASP object authorization

Document what happens if the permission source is itself unavailable. An old order snapshot and an old membership record should not inherit the same retention policy by accident. A conservative workflow may refuse new access until authorization can be established.

Downloaded documents need their own review. Amazon S3 presigned URLs are bearer tokens and may be used repeatedly until expiry, subject to their credentials and applicable permissions. Removing a user from the portal does not automatically revoke an already issued storage URL. Choose delivery and expiry controls around the required access policy, and test them. No system can recall a document the recipient has already downloaded. Amazon S3 presigned URLs

Make the failure behavior part of acceptance

Use fictional accounts and documents in an isolated environment. Agree on expected behavior before the demonstration, then retain the observed results and unresolved gaps.

The last case matters because a timeout does not establish whether the source accepted a write. Do not invite the customer to resubmit an apparently failed change without resolving that uncertainty. The broader investigation process belongs in Finding Data Inconsistencies in Production; the portal must still give the customer an honest outcome while that investigation runs.

Scope the first release around a decision customers repeat

Start with one customer group and one useful journey, such as finding an order and its documents. Check whether the existing native portal or a packaged product can express the account relationships, freshness rules and operating handoff before commissioning custom development.

If it can, configuration and a clearer runbook may be enough. If it cannot, those gaps define a focused engineering scope. They also make proposals easier to compare than a list of dashboard features.

Before a build discussion, bring one real workflow with private details removed: the records it uses, who may access them, the action that needs current data and the person who handles an exception. Discuss that workflow with Better Software.