Workspace admin

The admin's view of the workspace: who's in it, who can see what, the keys that let machines in, and the settings that affect the whole firm. Everything here is admin-only;

Members

• Invite a member by email from the Users page. The invitation email comes from Ferrith's identity service; the invitee sets up sign-in (multi-factor included) and lands in the workspace on first sign-in. Resend from the same page if it didn't arrive.
• Grants: per member, tick author agents, author workflows or author documents (the drafting library) to extend them without making them an admin. Admins hold all three implicitly.
• Roles group members for access lists: create a role (say, Partners or Conveyancing team), assign members, and use the role anywhere access is granted, folder access, agent and workflow restrictions, reviewer lists. Granting a role updates everything it's used in.

Removing vs deleting. Remove from workspace un-links the member: they can no longer sign in to the workspace, their work stays, and re-inviting them later restores their access to it — the right call for leavers where records must be kept. Delete permanently erases them: their sign-in account, private documents and folders, conversations, and private grids are destroyed, after a confirmation that shows exactly what will go. Work they contributed to the workspace, shared documents, agents, workflows, past runs, survives, attributed to "Former member". Permanent deletion is not reversible; the Owner can't be deleted this way (transfer ownership first).

Access, in one page

The whole access model, as it applies everywhere:

• Private is private. A member's private folders, conversations, and private grids are invisible to everyone else — admins included. Admin power is over the workspace's material, not members' private material. The only time private becomes visible is within the data package provided when the owner performs a full export of data from Ferrith.
• Workspace folders carry two lists: who can read (a restricted folder vanishes for everyone else) and who can edit (upload, new versions, delete to the bin). Edit includes read; no edit list means only admins write. Subfolders inherit and can only narrow.
• Agents folders hold agent knowledge and are visible to admins, the Owner, and agent authors.
• Agents, workflows, and grids can each be restricted to members and roles; restricted items disappear entirely for everyone else. Authors, admins, and the item's creator always retain access.
• Workflow runs are visible to the person who started them and admins; a workflow's run visibility list adds named members or roles who can see all of its runs.

API keys

On the Automation plan, the API keys page issues the keys that let your own systems call the workspace (the API guide is the integrator's manual):

• A key carries a label, a fixed set of scopes (read workflows, run workflows, upload run documents, chat, produce documents from drafting templates), an expiry (365 days unless you set otherwise), and a rate limit.
• The key is shown once, at creation. The list shows only each key's first characters — keep your own record of which key went where.
• A key with workflow scopes can be restricted to specific workflows after it is issued: Workflow access on the key's row opens a checklist, and a Restricted chip then shows on the row. Narrow it, widen it, or remove it at any time, the change applies on the key's next call.
• A key's scopes can't be changed: to change them, or if a key may have leaked, revoke it and issue a new one. Revocation applies immediately.
• Each key shows last used, an expiring-soon warning, and a per-key usage log, every call, when, and from where, plus a workspace-wide audit view across all keys.

Workspace details

The workspace details page (the cog) collects the workspace-wide settings:

• Timezone — sets how times display for everyone. Storage of your data is unaffected.
• Included usage — the workspace's daily model-usage allowance and where it stands today, matching the chip members see in chat.
• Models — for each area (chat, agents, workflows, analysis grids, drafting, the API), which of the models your plan grants members may use, the default, and whether they may change it. Members' pickers follow it within a minute; an agent or grid already using a model you remove keeps running until it is next edited.
• Storage — total use against your allowance, broken down by kind, including what's sitting in recycle bins (with a purge control) and, for members' private pools, per member, so reclaimable space is visible. See Documents for how the limit behaves.
• Encryption keys — your workspace's data is encrypted at rest with a key that can be yours: on plans with bring-your-own-key, bind the workspace to your organisation's own key vault, after which access to your data depends on a grant only you control, revoke it and the workspace goes dark to everyone, Ferrith included, until you restore it. Key rotation is available once you're bound to your own vault.

Export workspace data

Export workspace data produces a complete, readable archive of the workspace, members, conversations, documents (original files included), agents, workflows and their runs, grids, and audit records. It is Owner-only: it's the one action that crosses every member's privacy, so it belongs to the accountable role alone. The export streams to the Owner's browser and is stored nowhere else.

What happens when you cancel

Cancelling is done by the Owner in the account portal. The workspace stays fully usable until the paid period ends; after that, sign-in is blocked. 15 days later, the workspace's data is permanently deleted and because the deletion destroys the workspace's encryption key, that includes every backup. Within the window, re-subscribing restores everything; before cancelling, the Owner can take the full export above.