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.
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.