# Owner

**Owner** is the platform operator's own workspace and session: JBRH Digital Solutions using Connect for its own business, in a workspace with no plan and no allowances. It is not a permission level, and it is not the person who owns your company — a customer's most senior administrator is not an Owner in this sense.

- **Status:** Available
- **Audience:** both
- **In the app:** #/account, #/billing
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/glossary/owner/

## The definition, precisely

Two things carry the name together. There is one **Owner workspace** — the operator's own records, mailboxes and relationships — and an **Owner session**, which is a sign-in that resolves to it. In engineering terms a session is either in customer mode or it is not; the Owner session is the one that is not, and its API paths are the direct ones rather than the customer facade.

Everything else follows from that. The Owner sees the same screens, over the same code, with the same isolation applied — the Owner workspace is a [workspace](/docs/glossary/workspace/) like any other and cannot read a customer's rows. What it does not have is a plan, which means no allowance ceiling and no metering gate on a day's work.

## What is, and is not, Owner-only

The rule the product holds itself to is that there is **one feature set**. Every capability the Owner has, a customer has, over the same implementation. Three things are correctly restricted, and they share a shape: each is about *running the platform* rather than using Connect.

| Capability | Why it is not a customer's |
|---|---|
| Verifying a customer's payment | It is the operator confirming money received, not a business's own work |
| JBRH's own pricing | The commercial terms of the platform, not of your business |
| Enquiries sent to JBRH's website | Mail addressed to the operator; it sits outside every workspace by design |

Anything else that works for the Owner and fails for a customer is a defect, not a design. It is usually one of two things: a path the customer facade does not recognise, which fails closed with a 403, or a route missing from the customer-safe allowlist. A parity check enumerates the two surfaces against each other rather than asserting they match, and its list of known gaps may shrink and must never grow.

## Four things called owner, and only one of them is this

**Owner (this page)** — The platform operator's workspace and session. There is exactly one, and it belongs to JBRH.
**The owner of a business** — A customer's proprietor or director. In this manual they are a person using a customer workspace, and the manual addresses them as *you*.
**An account administrator** — Whoever manages users and settings inside a workspace. That is a role within a workspace, not the Owner.
**A record's owner** — The person a lead, opportunity or case is assigned to. A field on a record, unrelated to sessions or workspaces.

The confusion is worth taking seriously because it changes what a support answer means. "Only the Owner can do that" read as "only your director can do that" sends someone to the wrong colleague; read correctly it means "nobody in your business can, and that is deliberate." When a page here says Owner, it means JBRH.

## Why the manual mentions it at all

Because the corpus is written from a system that has two audiences, and a page that quietly described only one of them would mislead the other. Each page carries the audiences it applies to, and a capability marked as available to the operator alone says so in its status rather than in a footnote. [One implementation, two audiences](/research/two-audiences-one-implementation/) is the engineering note behind that.

## Questions

### Can the Owner read my workspace's mail?

Not through the product. The Owner workspace is scoped like any other and the three isolation layers apply to it identically; there is no cross-workspace read in the screens or the API.

### Am I the Owner of my workspace?

Not in the sense this glossary uses. You are a member of a customer workspace, possibly its administrator. Owner names JBRH's own workspace, and the distinction exists so that a sentence about permissions is unambiguous.

### Does the Owner get features first?

There is no operator-only feature beyond the three platform ones above, and the parity check fails a release that introduces one. What the Owner does have is no plan, so no allowance limit applies to its own use.

## Related

- [Tenant](https://connectbyjbrh.com/docs/glossary/tenant/)
- [Workspace](https://connectbyjbrh.com/docs/glossary/workspace/)
- [Customer-safe](https://connectbyjbrh.com/docs/glossary/customer-safe/)
- [Account and access](https://connectbyjbrh.com/docs/account/)
- [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/)

## What this page is based on

- docs-source/sources/GENERAL.md §1 — one codebase, two audiences
- `docs-source/facts.py` — AUDIENCES and CAPABILITY_STATUS (available_owner)
- docs-source/sources/GENERAL.md §1 — the enumerated parity rule