CrossTenant
Home / Demo

See CrossTenant in five steps

A guided walkthrough of the console over fictional customer tenants: the whole book on one screen, one finding followed from signal to audited action, and the evidence a customer gets at the end. Nothing here is live. Every organisation, person and value is invented, and the screens are illustrations of the product rather than a sandbox.

Start the tour Book a demo

Prefer a person? Request access and the founder replies to set up your invitation.

Step 1 of 5

Every customer on one screen

The scope picker sets all tenants, a group, or one, and the same pages work at every scope. Rows sort worst-first, each one carries its tenant, and a health grade summarises posture from live Google data fetched for that request. Nothing is warehoused between visits and nothing is installed in a customer's tenant.

  • ✓Per-tenant attribution. Every row, alert and action names the customer it belongs to.
  • ✓Live, not cached. Each screen is a fresh read of Google Workspace; the console keeps no copy of your customers' content.
  • ✓Worst-first. The tenant that needs you today finds you.
Next: evidence first

Step 2 of 5

Evidence before the headline

Before any score, the console shows the tenant, the time window and the state of every source it read. A capped or unavailable source stays visible as partial or unavailable; it never quietly becomes a zero or an all-clear. Only then come the findings, ranked by what matters.

  • ✓Sources, stated. Directory, sign-in reports, OAuth grants and device lifecycle each carry their own completeness.
  • ✓Partial means partial. A read capped at 100 users is labelled as such, not rounded up to complete.
  • ✓One finding to follow. The administrator without enforced 2-step verification is the thread the rest of the tour pulls.
Back Next: signal to action

Step 3 of 5

From signal to audited action

A leaver at Harbour & Co. The offboarding flow previews each step against live Directory data, then waits for an explicit confirmation. Nothing runs from a schedule, and nothing runs because an assistant suggested it. Workspace mutations remain explicit operator actions and are recorded in a tenant-bound audit trail.

  • ✓Dry-run first. The preview names every step that will change something, per customer.
  • ✓Confirmation, always. Second-person approval is optional and configurable, and is the next step of the tour.
  • ✓Bounded steps. Sign out, revoke tokens and app passwords, suspend: the same actions an engineer would take in Google Admin, in order.
Back Next: second approver

Step 4 of 5

A second pair of eyes, when you want one

Second-person approval is optional and configurable. When it is switched on, elevated writes park as requests instead of running: requester and approver are different people, the approver sees a live preview re-run at review time rather than a stale snapshot, and an unactioned request expires. If the gate cannot be checked, the write is refused rather than waved through.

  • ✓Ships off. You decide which actions are worth the friction.
  • ✓Fresh eyes. Approval is of what will run now, with a drift check against what was queued.
  • ✓Fails closed. A broken gate looks like a refusal, never like permission.
Back Next: customer evidence

Step 5 of 5

Evidence the customer can hold

Every write lands in a per-tenant, hash-chained audit log that verifies on demand. The 90-day customer review draws on the same evidence, and it is withheld while any required fact is incomplete, so what reaches a customer is complete or it is not sent. No Google Workspace message or file content is retained in CrossTenant's server-side stores.

  • ✓Tamper-evident. Each entry binds to the one before it; an edit, deletion or reorder is detectable at the first affected entry.
  • ✓Complete or withheld. A review with an unavailable source says so instead of shipping a false zero.
  • ✓Work, not claims. The review identifies work to do; it does not claim savings have been realised.
Back Finish: ways to start

Ready for the real thing?

Three ways to start

Access to the console is by invitation, and we set it up with you. Book a call and we onboard your first tenant together, or ask for access by email and a person replies.

Book a demo Request access

Already have access? Sign in · How onboarding works

Everything on this page is invented: the MSP, its customers, the people and every number. Domains end in .example for that reason. The screens illustrate how the product behaves and are not a live sandbox; the real console reads your customers' Google Workspace data live and keeps no copy of message or file content. Restricted Gmail-settings and Drive operations are not part of the launch profile and do not appear here. Read-only onboarding is available where Google provides read-only scopes. Our security statement and privacy policy set out the whole picture.