Skip to content

Product platform overview

What this is: how a customer organisation (a tenant), its people and their rights fit together. Who it is for: tenant admins and anyone who asks "who may command Ben, and why?". You will learn: what a tenant is, how people sign in, and how every action is checked.

The idea in one minute

Bill & Ben is sold as a product. Nobody uses it unless a person was created in the system first (rule G8). Every section, tool and agent is behind a permission key. No code asks "is this person a developer?". It asks "does this person hold code.push?". Admins change the answer in the console; no deploy is needed.

The parts

Part What it does
Tenant One customer organisation. Everything below belongs to exactly one tenant.
People Users exist in the platform. A user is created or invited; it is never made by the first message.
Identity One sign-in organisation per tenant. Sign-in by Microsoft, Google or email.
Roles Named bundles of permission keys, per tenant. Seven system roles are copied in when a tenant is created.
Policy check A single service answers "may this person do this here?".
Plan Trial, Team, Business or Enterprise. A plan switches features and quotas on.
Agents Bill, Ben and custom agents. Each is bound to chats, channels or meetings.

Sign-in and recognition

  • People sign in once; the sign-in tells every part of the product which tenant they belong to, so nobody is asked again.
  • Each sign-in has an assurance level: none, weak, linked, strong, strong_mfa. A key states the level it needs. Chat messages use linked (a Teams user matched to a platform user); the console and Helmora need strong.
  • In Teams a person is matched to an active user by their Microsoft organisation and account. An unmatched person is not recognised, and the agent does not run for them. See Access check.

Tenant isolation

In short: each company has its own people, plan and data, and every action is checked.

what belongs to one company and how every action is checked what belongs to one company and how every action is checked

Legend: yellow = a person, blue = Bill & Ben, red dashed = a check or a stop, grey = stored data. Open full size

Every record belongs to exactly one tenant, and each request can only see its own tenant's records. The permission check also refuses any request where the person's tenant differs from the resource's tenant.

What happens on each action

  1. The service finds who is asking (a platform user and an assurance level).
  2. It asks the permission check and waits (default 300 ms).
  3. The check runs its gates in order. See Permissions and roles.
  4. The answer is allow or deny, with a reason and sometimes an obligation. Every denial and every write is audited.
  5. If the check cannot answer, the action is denied. The system fails closed.

Agents answer only people allowed to command them

For chat and meeting speech, the agent first checks that the speaker may command it (agent.command), then ask it (agent.ask). Someone who holds neither gets the agent's unauthorised policy: decline_once (default), silent or decline_always. With decline_once the agent says one polite line per person per conversation per 24 hours, then stays quiet. It never starts a run for that person. The policy is set per agent in the console.

Plans

A plan is a set of entitlements (meeting minutes, sandbox minutes, gateway detail, model roles, devices, SSO, audit export). A catalogue key may name a plan gate, so the plan narrows what a role can do. Detail: Permissions and roles. Billing states (active, past due, read only) also gate writes.

Where to go next