Admin: Your organization

DraftMesh’s Administration console is where your organization’s admins — and its auditors, who read it without changing it — can see the whole account at once: what has happened, who can reach which documents, who has been invited, and which agents are registered.

It lives in the Account menu → Administration…, and it is part of the signed-in cloud product. A DraftMesh running locally on your own machine has no organization and no console.

Where your organization comes from

DraftMesh does not have its own directory of companies. Your organization is your WorkOS organization — the same one your identity provider signs people into — paired with a DraftMesh account that every workspace, share, agent, and audit record then belongs to. An organization without a display name in DraftMesh shows as Unnamed organization, with its organization ID to copy; DraftMesh does not invent a name.

That pairing is set up deliberately, not on first sign-in. An organization DraftMesh has not been set up for is refused rather than quietly created, which is what keeps one company’s records from ever landing in another’s. From a personal account, use the Account menu → Create an organization…. A paid Team request goes through checkout and is set up when its subscription becomes active or trialing; a request without checkout is reviewed by a person on the DraftMesh team. Once the organization is set up, you are its first admin.

Signing in without an organization is different: you get a personal account, created for you on the spot. It is yours and nobody else is in it. With the Individual plan you can issue guest links from a document’s Share panel — view, comment or suggest, never edit; the whole document or one section; for 1 hour up to 30 days; revocable at once. A guest is named but not verified. Named sharing with verified identity, Shared with me, groups, agents as separate principals, the admin console, the audit log and SSO all belong to an organization — use Account menu → Create an organization… when you want to bring colleagues in.

Admins, members and auditors

There are exactly three roles, and they are flat: Admin, Member and Auditor. Every admin holds the same authority as every other — there is no senior admin, and no per-section permission to hand out.

Admin is the whole account: the console, sharing, agents, and edit on every document. Member is the ordinary role — you reach the documents you have been granted, and nothing else. Auditor is the read-only counterpart of admin, for the person whose job is to check rather than to change: they read every document in the organization and the whole console, and they can change nothing at all — not a comment, not a suggestion, not an approval, not a share, not a console action. It exists because the alternative was making a compliance reviewer an admin, which hands them edit on every controlled document in order to let them read one.

The person the organization was set up for is its first admin. Everyone else who signs in afterwards arrives as a member, until an admin says otherwise or they were invited at another role.

Admins change that in Administration… → People, in the Members (as observed) table: each person’s row carries a Role selector with those three values, and picking a new one applies it. Two things it refuses, and says why rather than failing silently:

• An organization can never reach zero admins. Once the member list has finished loading, the selector on the last remaining admin is disabled and reads “This is the organization’s only admin. Promote someone else before removing their admin access.” — and whether or not the console has got that far, the server refuses any move off admin for the last one, to Member and to Auditor alike. An auditor is not an admin, so making the last admin an auditor would leave the organization with nobody who can change anything.
• Only people can hold a role. Agents and service accounts are listed but are never admins or auditors.

Every role change bites immediately: the next thing that person asks DraftMesh for is answered at the new role, without waiting for them to sign out. That cuts both ways — a new auditor’s next write is refused, and their next read still works.

You can also set the role up front — an invitation sent from the People section carries Member, Admin or Auditor, applied when that person first signs in.

A seat is Author or Reviewer — separately from the role. Most members hold an Author seat. A Reviewer seat is for a named, signed-in member whose job is review: they can read, comment, suggest, ask and answer questions, approve and sign off — their approval is recorded and shown; a version is approved once an author approves it — and they cannot edit or save a document, accept or reject suggestions, manage workspaces, or administer anything. Only a Member can hold a Reviewer seat; an admin or auditor is always an author. People shows each person’s class in a Seat column with a picker, and Upgrade to full seat turns a reviewer into an author, which spends an author seat. Reviewer seats are free and unlimited on Team and included in Enterprise; only people who author need a paid Team seat. Individual has guest links, not named reviewers. When an organization has more than five reviewers per seated author, and again past ten, Overview shows a notice and the audit log records tenant.reviewer_ratio_flagged; nothing is blocked. Every seat-class change is recorded in the audit log as org.member_seat_class_changed.

Your account also records an owner, separately from these roles. It is the billing and accountability contact; the recorded owner must hold the Admin role. People marks the owner’s row Owner, and Billing & plan names them (Current owner: …). An admin can use Administration → Billing & plan → Transfer ownership… to choose another admin and confirm. Only current admins other than the owner are offered — your own name is marked (you) — so to hand ownership to someone else, make them an admin on People first. The previous owner stays an admin until their role is changed separately. Other admin roles can be promoted and demoted as the team changes.

Inviting someone in

Administration… → People → Invite someone… takes an Email address and a Role (Member, Admin or Auditor, defaulting to Member), and Send invitation puts the invitation out through your identity provider — this one always emails the person, where a document share does only when the host can send email (its Share panel says which happened).

The role you pick is applied when they first sign in with the invited address verified by your identity provider, not before; a sign-in with that address unverified gets no invited role. Until they accept, the invitation sits in the Invitations table below with a state of Pending, Accepted, Revoked, or Expired, and a pending one can be withdrawn with Revoke, which asks you to confirm first. A revoked invitation keeps showing the role it was sent with while the console stays open; after a reload its role reads —, because withdrawing an invitation also discards the role it had parked.

Inviting the same address twice is safe and honest about itself: you are told the person “already has an invitation outstanding — nothing new was sent”, or that they are “already a member of this organization”, rather than quietly sending a second email.

An invitation is about getting into the organization. It grants no documents — sharing is a separate act, described in Admin: Access & sharing.

Seats. Overview, Billing & plan, and the People invitation form show seated · invited · limit. The Seats tile’s Billing… link opens Billing & plan for admins and auditors; auditors see the same facts without billing actions. A seated person has signed in; a pending invitation is a commitment but does not reserve a seat. When seated plus invited exceeds the limit, the console warns that the organization is over-committed. That warning is distinct from being over the seat limit, where already seated people exceed it. Invitations are refused when all seats are already spent, but DraftMesh does not enforce a seat limit when an invitee signs in; review pending invitations before promising more places. Plans and limits come from your subscription. In Billing & plan, an admin can review a seat change, never lowering the limit below the number already seated (when the subscription carries an add-on item, the charge is previewed and confirmed in Billing & plan; a lower limit takes effect immediately and credits the next invoice), and manage cancellation or resubscription. Removing someone from People frees a spent seat. Suspending them keeps that seat. For an organization without a subscription, such as an Enterprise contract, the DraftMesh team sets its limit. Enterprise is set up by the DraftMesh team rather than bought in the console, on terms agreed with each organization, with the add-ons included.

What each role can do

Neither an admin’s nor an auditor’s reach is limited to the documents shared with them. Admin authority carries edit on every document in the organization, with no grant needed — promoting someone hands them that. Auditor authority carries view on every document in the organization, with no grant needed, and a grant cannot raise it. Sharing a document with an auditor of your own organization is refused at any level when DraftMesh can tell that the address belongs to one — it recognises an address it has already seen on a share or in a group here, and an address it has never seen names no account it can check. Either way the grant is inert: a row addressed to an auditor of this organization confers nothing at all while they hold the role, whether it was written before they became one or accepted afterwards. Treat the People roster, not the Share roster, as the answer to “what can this person do?”. (Someone who is an auditor elsewhere and holds a share here is an ordinary grantee here — the role governs the organization it belongs to.) The role is a ceiling as well as a floor, so the People roster saying “Auditor” means it everywhere.

A member does not see a greyed-out Administration entry, or one that fails when clicked. They see nothing — the menu simply does not have it. That is deliberate: a disabled control tells someone a door exists and invites them to rattle it. An auditor sees the console the same way from the other side: every list, every total and both exports are there, and the controls that would change something are simply not drawn — no invite form, no Role selector, no Revoke, no agent buttons, and no Manage in WorkOS link into the Admin Portal. One line under the title says why, so the absence reads as a role rather than a failure. The document’s own Share panel behaves the same: an auditor sees who holds what and which guest links exist, and nothing that would issue a grant or a revoke. An admin meets the other side of that same panel: opening a colleague’s document, from their own workspace list or from a link, they see Share on it and can grant from there, because sharing that document is authority they already hold.

Sharing and agent management are admin-only whatever else somebody holds. Being granted edit on a document never confers the ability to re-share it, register an agent, or read anyone else’s activity.

The six sections

• Overview — service health and the summary tiles: People & agents, Active sessions, Workspaces, Active agents, Document shares, Live guest links, Seats, and Agent activity — this month’s agent actions against the organization’s pooled allowance (agents are never seats; see Admin: Governing AI agents). Active sessions includes web, device, agent, and personal API-token credentials; the tiles distinguish credentials from browser sign-ins and live agents from the whole registry.
• People — the members DraftMesh has observed, organization members homed in another organization, people outside it who hold shares here, the organization’s workspaces, invitations, and groups. Each observed person’s row shows their role, connector state, session access, and suspension and removal controls where permitted. Suspend… also reaches organization members homed elsewhere. Its dialog accepts an optional reason and signs out DraftMesh devices and revokes API tokens by default; uncheck that box to keep unexpired credentials available after reinstatement. A suspended row shows its date, acting admin and reason. Reinstate restores access in one click. Suspension keeps roles, groups, grants, work and the seat; browser sessions remain with the identity provider. Auditors see the suspension facts without controls. Remove asks you to confirm in a dialog that names the person; on your own row (marked (you)), on the owner’s row, and on the last admin’s row it is disabled with the reason shown beneath it. Remove… also reaches organization members homed elsewhere: it ends their membership and access here, frees no seat because they hold none here, and leaves their own workspace and other organizations untouched. Every act that takes access away — removing a member, revoking an invitation, turning agent access off — confirms the same way; turning agent access back on does not ask. In the Account menu, Groups… brings an admin here, to People’s groups. Single sign-on reports the identity-provider connections; admins can open their WorkOS management page.
• Agents — registered agents, where their work is delivered, standing rules, and delivery results. Their document grants are under Access.
• Access — document shares and guest links across the organization, with revocation where permitted and separate CSV exports. The selected tab is part of the console URL.
• Audit log — recorded organization actions, filterable by action, person, result, and date, with a CSV export. Applied filters live in the URL, so you can share or reopen a filtered view.
• Billing & plan — the subscription, seat limit, and billing state. Admins can use Manage billing ↗, Update payment method ↗, Review seat change ↗, Cancel subscription… ↗, or Resubscribe ↗ when the corresponding action is available. Manage billing, payment-method changes, cancellation and resubscription open Stripe’s page. A seat change on a subscription with one item is confirmed there too. Seat changes on a subscription carrying an add-on, and Add… or Change… for an offered Governance pack, are previewed and confirmed in Billing & plan. Additions are charged for the remaining billing period before they apply; decreases and removals credit the next invoice. During a trial, additions cost $0 now and are billed when the trial ends. If payment needs action, Stripe’s invoice page opens to finish it. An add-on arranged by DraftMesh is changed through support@draftmesh.com. Auditors see the plan and billing facts without action controls.

Every section opens for an auditor too, with its listings, totals and CSV exports intact and its controls absent — no Role selector, no Block, no session Revoke, no per-row Revoke on Access, no Manage in WorkOS on the Single sign-on card, and none of the Agents buttons or the organization-wide agent switch. The exports are audited under the auditor’s own name, like anyone else’s.

People distinguishes who has used DraftMesh from who has been invited. Neither list is a full directory of your organization — DraftMesh does not read one.

Audit log, Access and Agents each get a topic of their own in this guide; Overview and People are covered above. The console has a shareable ?admin= address. Closing and reopening it restores the last section and filters in this session. Help opens beside the console on a wide screen.

What is not here yet

The console is a governance surface, not a control panel for your identity provider. Identity-provider group membership and who is allowed to authenticate at all are configured in your WorkOS organization, not in DraftMesh — and so is single sign-on itself: Overview’s Single sign-on card reports your connections and hands you a link into WorkOS, but adding, editing or removing one happens there. (DraftMesh’s own Groups…, in the Account menu, are targets for document grants and nothing more — they are not the identity provider’s groups and confer no console authority. An auditor sees every group there and can create or change none of them, including any they created before the role.) See Admin: Security posture FAQ for the full list of what does and does not live here.