Account, organization and product workspace

A Beyond account is one person, an organization is a group of accounts, and a product workspace is where a product keeps its own people and permissions. None of them implies another.

  • Availability: Experimental
  • Evidence: Read from source
  • Explanation

The problem this solves

You joined an organization in Beyond Accounts and expected to see your team's project in Delegate, and it is not there. Or you were invited to a Delegate workspace and wonder why Accounts shows no organization. Both are correct, because these are three separate things.

The three in plain language

What it is Where you manage it What it gives you
Beyond account You: one person, reached by the sign-in methods you attached Beyond Accounts, under Your account and Sign-in and sessions The ability to be recognized by every Beyond product with one login
Organization A group of accounts, each with a role: Owner, Administrator, Developer or Viewer Beyond Accounts, under Organizations Membership, which products may read. No permission in any product by itself
Product workspace The place where one product keeps its own people, projects and permissions. In Delegate it is called a workspace and its places are called seats Inside that product. In Delegate: Workspace settings Whatever that product grants you there

What does not follow from what

  • Having an account does not put you in any organization. "You can use your account without one."
  • Belonging to an organization does not give you a Delegate seat, a Delegate project or a Delegate permission. A Delegate that is not connected to Beyond Projects does not read your Accounts organizations when you sign in: it receives who you are, and nothing else. A connected one reads them once, as you arrive, for a single purpose described below, and still grants nothing from them.
  • Holding a Delegate seat does not make you a member of any Accounts organization.
  • Holding a Delegate seat does not let you act in a project. Access is granted per project. See Workspace and collaboration.
  • The organization shown as Working in in Accounts is context that a product may use. It is never a grant.

Why it is built this way

An identity service that decided what you may do in every product would have to understand every product's resources, and a mistake there would be a mistake everywhere. So Accounts answers only "who is this, and which organizations do they belong to", and each product answers "what may this person do here" from its own records. Identity and resource permissions goes further into who decides what.

More detail

  • The roles have the same four names for every product because the products that read organizations validate exactly those four. A product with finer distinctions keeps its own roles on its side, as Delegate does with Administrator, Member and Viewer.
  • Account and organization identifiers are stable and opaque (acc_…, org_…). Renaming does not change them.
  • Accounts are never matched or merged by email address, in Accounts or in Delegate. A person is recognized by a sign-in method that a provider verified.

Next action

Setting up a team in Delegate? Invite people to the workspace. Managing membership for products that read it? Organizations in Accounts.