A subscription analytics platform where almost nothing is ours, and every boundary is

To render a private dashboard, something has to prove to the vendor that the request is legitimate.

The direct path hands that proof to the browser. A token, or in the worst version the credential that mints one. It works, it is faster to build, and on the day it ships it is indistinguishable from the alternative.

Anything that reaches a browser is readable, storable and replayable by whoever obtains it. On most products that is a bounded problem. On this one, the embedded layer carries the most sensitive data in the customer's business, so a client-side credential is not a small mistake. It is the whole dataset.

There was a second temptation in the same place. The credential returned by the identity provider is convenient to keep: pass it to the front end, forward it to the vendor, reuse it later.

Every vendor secret stays on the server. The credentials, the grant generation and the logic around both live exclusively in the service layer. The front end receives none of them, and gains no capability by inspection.

The browser receives a scoped, expiring grant. Not a credential. A grant already limited to one user and one view, valid for minutes rather than hours. Intercepted, it opens one thing for one person and then stops.

The identity provider's answer is discarded immediately. It exists on our server for as long as it takes to answer whether the person is who they claim to be, and is then thrown away. It is never stored, never forwarded, and never sent to a vendor.

Every hop is encrypted, front end to service, service to provider, service to vendor, with protocol downgrade refused.

And renewal happens behind the user. Short-lived grants are a deliberate security decision that creates an operational one, because an analytics session is longer than any sensible token lifetime. Somebody opens a dashboard, filters it, and returns to it twenty minutes later. The service re-mints before the current grant lapses, so the view never goes stale in front of the person using it.

Federated sign-on answers identity well and authorisation barely at all. It confirms that a user is valid. It does not know that this particular user may open the revenue view, and only for one property.

Getting that wrong on a platform like this means one operator seeing another operator's numbers. It is the failure mode that does not announce itself, because coarse permissions look like a working system right up until an audit or a support ticket.

And the decision has to hold for somebody who never touches the interface. Hidden navigation is a presentation choice. It is not a boundary.

The provider answers one question and stops. Is this person who they claim to be. Everything about what they may then do stays with us.

Our own session is the only identity in the system. Once the provider confirms the person, the service issues its own session carrying identity and role, held so the browser cannot read it, and time-boxed.

Every request is authorised on the server, against the role resolved at that moment rather than at sign-in. A role change takes effect on the next request rather than at the end of a session.

Scope is applied when the grant is minted, so a user limited to one property cannot widen their own reach from the client. The restriction travels inside the grant rather than being requested politely alongside it.

And a limited user sees a coherent product rather than a locked one. Menus and modules are assembled from what that person is entitled to, so a department head or an external stakeholder meets a curated portal rather than a full product with doors that refuse them. An empty module says so plainly instead of returning an error.

Most operators build next year in a spreadsheet and report this year in a system. The two are detached by construction, so the budget has no systematic benchmark against trailing performance, no automatic roll-up to earnings, and no agreement with the actuals it will later be measured against.

The obvious fix is to build the planning tool inside the reporting product. That removes the reconciliation and immediately creates a harder problem.

A planning tool that writes to the reporting warehouse is a tool that can be wrong at scale. One careless bulk action rewrites a year of assumptions across a chart of accounts, and every dashboard downstream agrees with it, confidently, because they are reading what was just changed.

Reporting and planning share the warehouse. Budget screens read and write the operator's own warehouse through the service layer, and on save the financial figures behind the dashboards are recomputed. The summary and the divisional views show the figures the planner has just entered, without a refresh cycle or an overnight batch.

And four rules make a write safe to allow.

An account cannot drive itself. Circular references in the forecasting configuration are refused rather than resolved.

Reach is stated before it is applied. A bulk action shows exactly how many account settings it will write, before it writes any of them.

Human edits survive automation. A month somebody set by hand is marked and retained through subsequent auto-fill, so a deliberate override is never silently replaced by an average.

Nothing writes by accident. Every save is preceded by an explicit confirmation. There is no page in the module that commits on a keystroke.

Around all of that sits context rather than a blank grid. Each assumption is shown against its trailing twelve month position, and an earnings bridge walks from the trailing figure through revenue, cost of sales, wages and other movements to the budgeted figure, so the effect of a change is visible while it is being made.

The visualisation layer is read-only by design. It renders what the warehouse holds, and for every dashboard in the product that is the right tool.

One area of the product is not a dashboard. It needs structured input, validation and write-back, which is an application rather than a report. That was built on a low-code platform and embedded into the portal.

Adding a second vendor reopened every problem the first one had already closed. A different trust model, a different token format, a different lifetime, and a different way of receiving user context. The default behaviour was exactly the failure already eliminated once: a user who had signed in, opened four dashboards without a prompt, and then reached this screen would be asked to authenticate again, by a vendor they had never heard of.

Single sign-on is only credible if it is unconditional. A product where four modules load silently and the fifth asks who you are does not read as one product with a small gap. It reads as two products stitched together.

Our own session stayed the only identity in the system. Both vendors are downstream of it and neither is ever an authority. Neither is aware the other exists.

Embed issuance was normalised behind one internal contract. A single service turns this user and this resource into a signed, expiring grant. The two vendors are two implementations behind that one interface rather than two parallel authentication paths.

The second vendor's credential joined the first on the server. The front end gained no new capability and received nothing beyond a scoped, expiring grant, so decision one holds unchanged for the second vendor.

Authorisation crosses the vendor boundary. Role and property scope are resolved once from our own model and injected into both grants, so a restricted user is restricted identically whichever platform is rendering.

Two expiry clocks are tracked rather than one. The vendors issue grants with different lifetimes, so background renewal is handled per vendor and neither surface goes stale mid-session.

And the second vendor reads the same warehouse. Nothing is copied into a second store, so the single source of truth survives the addition.