Start here

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.

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 documents. What you can see and do is decided per team.

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.

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 three you are most likely to meet early:

• You cannot approve your own submission. Expected. Someone else with approval rights has to.
• You cannot edit a draft that is out for review. The draft is sealed until the review is decided.
• An invitation is refused. You are out of licences, or you are in a personal workspace. See Seats and licences.