Managing several customers as a partner

If you look after several organisations rather than one, four pages exist for you: Portfolio, Work queue, Standards and Customer report. They answer the question a managed service provider actually has on a Monday morning — which of my twenty customers needs me today — without making you sign in to twenty consoles to find out.

This article covers what those pages do, and then covers what they do not, because four capabilities a partner will reasonably expect are absent and one of them will decide whether this is usable for you.

How the platform decides which customers are yours

This is the part worth understanding first, because it explains both the strengths and the limits of everything else.

There is no partner-to-customer ownership table. Your portfolio is derived, per request, from your own organisation memberships: it is the set of tenants the signed-in person is a member of, and nothing else. It is never received from the client, never cached across requests, and never inferred from a relationship record.

Adding a customer to your portfolio therefore means being added as a member of their organisation, with a role there. It is their grant to make, not ours, and they can revoke it. That is the right way round for a relationship a customer is paying for.

Note this is a flat membership model. There is no hierarchy — see the absences below.

The three permissions

The reason write is withheld from the ordinary roles is worth quoting because it is a good piece of reasoning: a baseline is how a partner's whole book of business gets configured, so editing one is an act with reach far beyond the tenant the editor is sitting in.

The cross-tenant pages are gated by holding portfolio read in any tenant, which is a gate rather than the scoping decision — the actual scoping is the membership check per organisation described above. A customer who has not granted you a role with these permissions simply does not appear.

Portfolio and the work queue

Portfolio is one row per customer with the state that matters, including sensor coverage broken down as total, online, silent and revoked. Note the definition of online: it requires both a non-revoked status and a recent check-in. A sensor row marked online that has not reported in a fortnight is counted as silent, because as the code puts it, a stale online row is the normal way a fleet lies about itself.

Work queue is the cross-tenant list of things waiting for a person: pending response approvals, AI action plans awaiting approval, Sentinel-Q escalations, silent sensors and expiring credentials. It is the page that replaces logging in to each tenant to check.

Standards: define once, hold every customer to it

A baseline is your own standard — the controls you want every customer configured with — expressed as a list of control keys, each with a target value and a severity of low, medium or high. Baselines live in your organisation; a customer tenant is then bound to one.

Three design details with practical consequences.

• A tenant may be bound to at most one baseline. Enforced as a uniqueness constraint, and the reason is sound: two standards disagreeing about the same control has no defensible resolution.
• A baseline survives the person who wrote it. The creator reference is nulled rather than cascading, because the technician who wrote the standard leaving the practice must not delete the practice's standard.
• An unknown control key is reported as unknown rather than dropped. Control keys are an application-level list, not a database relationship, so a baseline referring to something the platform does not recognise tells you so instead of silently shrinking.

Coverage is partial and the platform tells you by how much. Some controls in the catalogue cannot be measured from live tenant state — one, for instance, is expressed as sign-on and authentication policy rules whose conditions are stored as documents this build cannot evaluate. The Capabilities view reports the measurable count against the catalogue total at runtime, so read the number from there rather than from any figure quoted in documentation, including this article.

The four things that do not exist

The platform publishes its own honest account of this: a capabilities endpoint that marks each partner capability implemented, partial or absent, with the reason, and the console renders it verbatim. Four are absent.

Acting on an item without leaving the queue

Covered above. The workaround — a deep link that switches organisation visibly — works, and it is a workaround.

Automatically configuring a new tenant from a baseline

Binding reports drift; it does not perform the changes. Onboarding a new customer to your standard is still a sequence of approvals inside their tenant.

Sub-partners and multi-level resale

The authorisation boundary is a flat membership set, so a distributor cannot see their resellers' customers without being a member of each tenant individually. If your business model has two levels, this model does not express it.

One invoice across your portfolio

Licensing and billing are per organisation. There is no partner-level aggregation, no margin model and no consolidated invoice. This is the one most likely to decide whether the platform fits your business today, so it is stated in the product's own words rather than softened.

A fifth capability, the customer report, is marked partial for a specific and easily-stated reason: there is no document renderer and no scheduled email in this build. You can produce the report and read it; you cannot have it arrive in a customer's inbox on the first of the month as a document.

Practicalities worth planning around

1. Get the right role in each customer tenant, not a shared login. Your portfolio is your membership set, so a properly-roled account per technician gives you attribution in each customer's audit log. A shared credential gives you a portfolio and destroys the record of who did what.
2. Expect per-customer billing. Plan your commercials around each organisation holding its own subscription. See Plans and what each includes.
3. Use one baseline per customer type, not per customer. A tenant binds to exactly one, so dental practice, 20 seats is a more useful baseline than a bespoke one each.
4. Tell your customers you can see this. The portfolio shows you their alert queue and their sensor coverage. They granted it and they may not remember granting it, and a partner who volunteers that is a partner who keeps the account.

What to read next

1. Roles and permissions — which role to ask each customer for.
2. Delegated administration — scoping an administrator inside a single tenant, which is a different mechanism from this one.
3. How tenants are kept apart — the isolation model your customers will ask you about.