Start here

The shortest path from signing in to a published document — what to set up, in what order, and what you can safely skip.

<!-- Reviewed 2026-09-08 (no default team; team codes capped at three): the covered code lost one payload field (`isDefault` on `GET /api/teams?mine=true`, which no surface this page describes ever showed), renamed the team-less fallback helper, and had its comments corrected — the fallback itself is now the workspace's OLDEST team rather than its flagged one, which resolves to the same team on every workspace the app has made. New team codes are 2–3 characters; existing longer codes are untouched and keep numbering, because the numbers already issued cite them. Nothing this page states about behaviour changes. --> <!-- Reviewed 2026-09-07 (the mode left team settings): the covered teams.ts lost its permission-mode column read. This page's first steps never mentioned the setting and are unchanged. --> <!-- Reviewed 2026-09-05 (permission mode, docs/ASSISTANT-LOOPS.md §2): nothing this page describes changed. The covered `teams.ts` gained the team's permission-mode column and its reader/writer — the first-run path this page walks is unchanged, and a new workspace starts on the setting that waits for you. --> <!-- Reviewed 2026-08-27 (document clause audit retired): this page's covered code changed only where the audit touched it — `teams.ts` no longer lists `audit_reports` among a team's owned tables, and `withApi.ts` lost the `auditReports` resource gate. Nothing this page describes to a reader moved: a team still owns its documents and risks, and the permission rungs are unchanged. Confirmed rather than rewritten. -->

This page is the ten-minute version. It walks the path once, end to end, and points at the page with the detail for each step. If you would rather understand the model before touching anything, read the Document system overview first.

1. Sign in and name your workspace

The first thing you do is name a workspace. Nothing exists until you submit that form — there is no placeholder workspace sitting there waiting to be renamed, and no way to end up with an accidental empty one.

The name you type does two jobs: it is the display name you will see everywhere, and it becomes the workspace's address. Names are claimed globally, so a name already in use will be refused and you will be asked for another. Pick the real name of your organization or department.

Sign up with your work or personal email — accounts made on temporary-email services cannot sign up or create a workspace. Each account creates and owns one workspace of its own; being invited into other workspaces is unlimited.

You also confirm the workspace's time zone on the same form. It is filled in from your browser, so usually you glance at it and carry on — it decides what 09:00 means for anything you later schedule.

One team is created for you automatically, so you are never looking at an empty workspace with nowhere to put anything.

Detail: Workspaces.

2. Understand the two containers

Almost every confusing moment in the first week comes from mixing these up:

  • A workspace is your organization. Members, billing and settings live here.
  • A team inside it owns records — documents and registers alike. What you can see and do is decided per team, and the team's short code is stamped into every record it numbers — PLC-HR-001, LIST-HR-001 — so pick that code before the records pile up: once anything carries it, it cannot be changed.

You do not need more than the one starter team to begin. Add teams when you have genuinely separate bodies of documents with different people accountable for them — not because your org chart has departments. A team you no longer need can be archived later: nothing it holds is deleted, but the team goes out of reach for everyone on it and cannot be reopened from the app, so move anything you still want first.

Detail: Workspaces and teams.

3. Write something

Create a document in your team and start typing. There is no "new document" ceremony to learn: you get a draft, it saves as you go, and nobody else sees it as official until it is published.

Three ways to start — from scratch, from a template, or by uploading a file you already have. If you already maintain documents elsewhere, uploading one is the fastest way to see how the system behaves with real content.

Detail: Creating documents and The editor.

4. Invite the people who matter first

You can do this later, but reviews need at least two people, so it is worth doing early.

When you invite someone you choose their workspace role and which team they join, in one step. The role you give them on that team decides what they can do to its documents — read only, write and submit, or approve and publish.

Invite at least two people who can approve. With a single approver, that person's own submissions can never be reviewed by anyone else.

Detail: Members and invitations and Roles and permissions.

5. Send it for review, then publish

Submit the draft. Someone with approval rights on that team reviews it and either approves or sends it back with comments. On approval it becomes the published version — the one everyone else reads.

The one rule that surprises people: whoever submitted a document cannot approve that same submission, regardless of their role. That is deliberate and cannot be overridden.

Detail: Submit and approve and Publishing.

What you can skip for now

These matter eventually and none of them block you today:

  • Connections. Pulling in evidence from other systems can wait until you have documents worth checking.
  • Controls and evidence. Start with the written documents; map them to controls once they exist.
  • More teams. One is fine until it isn't.
  • Billing. The free workspace covers you and one other person, which is enough to exercise a full review cycle.

When something is refused

Alchex decides permissions on the server, so a refusal is the real answer rather than a UI guess. The two you are most likely to meet early (editing, note, is never refused for a review being open — the review decides on a pinned copy, and you keep typing into the next version):

  • You cannot approve your own submission. Expected. Someone else with approval rights has to.
  • An invitation is refused. You are out of licences, you are in a personal workspace, or one of the teams you named is not one you can place someone on — an archived team, usually. See Seats and licences and Members and invitations.