Workflows in documents and registers

A document is asked things by its controls. Each control is one request on a clock; each time it runs it opens a session you can read and reply to.

Nothing is read out of your text. A sentence like "every quarter, the Records Manager checks the retention of files" is a fact about your organization, not an order to the product. Saving a document never starts, changes or stops anything. If you want something done on a date, add a control.

The Controls page

Controls in the sidebar lists every control in your team, one row each: the control, the standard it belongs to, the clauses it proves, its result and when it last ran. The result is what the last run found: Effective when every check passed, Not effective when a check found a problem (with how many checks passed), Partly checked when some checks could not be done, Couldn't run when the run stopped before it finished, and Not run yet. A paused control also says Paused. Open a row for the control's own page, where its document and clock live.

A control is one request plus a clock. On its date, the request is sent to the agent as the first message of a session, with the document it runs on: the control is the task, the document is what the run follows. A document can carry as many controls as you need; each is its own row, with its own clock and its own sessions.

Adding a control from the library

Press Add a control. The library opens in place of the list, the way the app catalog opens when you add a connection. It holds every control of every standard Alchex knows, not only the standards your workspace works to. On the left are the standards, each a checkbox with how many controls it brings; the ones your workspace has added start ticked, so the table opens on them, and with none ticked you see everything. Under them is every process, with how many of the ticked standards' controls run on it. At the top, one search by title, clause or control ID. The table comes a page at a time, each row with the control's whole name, the standard and clauses it proves, how often it runs and the process it belongs to; Required marks the ones a clause depends on. Previous and Next walk the pages; a change of filter goes back to page 1.

Press Add on the row you want. One question follows: the document the control runs on, offered as the process's own document when you have written it. Press Add again and that is all: the control starts on the clock its row names, and the clause it proves reads its runs from then on. A control already running shows Running instead of Add.

Writing your own control

Press Write your own control at the top of the library. Give it a name and say what to check, in your own words, the way you would type them in chat: "Count the laptops without disk encryption and tell me which." Choose how often it runs (every day, week, month, three months, six months or year) and the document it runs on, and press Add. What you type is exactly what is sent; the document goes with it, so you never restate what is already in it.

Your own controls show Your own where a library control shows its standard. Open one and you can change its name, what it checks and its clock, or Remove it. Removing a control deletes its schedule; the sessions it already ran stay.

A control's page

Open any control for its page: what it checks, the document it is set up on, its switch and its clock, whether it may use the internet, and its runs, newest first. The latest run says what it read and what failed.

• Run now starts a run today without touching the clock. It does not start a second run while one is still running.
• Switching off keeps the clock. Switch a control off and back on, or archive its document and restore it, and it picks up where it left off: if its date passed meanwhile, it runs at the next check. Changing the clock starts a fresh period from that moment; editing what it checks does not move it.
• A library control's request is its card, written out in full. Each run records a result for every requirement the control proves: passed, failed or couldn't run, each with one line of why. The result shows on your Compliance page, linked to the session that produced it.

Write what you want done. "Tell me what is out of date" asks for a report. "Fix the retention periods" asks for the work. A few changes always wait for a person, exactly as in chat: archiving, and sending a version to a workspace that subscribes to yours.

Sessions — what happened

Every run is a session. A control's page lists its own; Sessions in the Chat rail lists every session run on the documents of a team you are in, newest first, one line each: what it was, when it started, and where it got to — done, asking you something, waiting on an approval, or stopped. Click one and it opens in Chat, where you can read every step.

Sessions belong to the record's team. Everyone on that team sees them, and anyone on it can answer one. Nobody outside the team sees them, and your own chats stay your own.

Archiving a record stops its controls. Their schedules stop firing but are not deleted; restore the record and they come back. Delete a register outright and its schedules go with it, but the sessions it already ran stay as the record of what was done.

Replying in a session

When a session is asking something, type your answer in its composer. The agent picks up from your answer and carries on, in the same session. A session that is not asking treats your message as a note.

What a run can reach

A run has the same tools the assistant has in chat:

• your documents, registers and sheets;
• the systems connected under Connections, to read them and, under the same Auto or Ask settings as chat, to change them;
• the internet, only when the control's Internet access is on.

Internet access. Each control has its own Internet access switch, in the settings on the right of its page, and it is off until you turn it on. While it is off, a run opens no web page. While it is on, a run may search the web and open any public https page, such as the page where your privacy policy is published, and it cites each page it used by its address and the time it read it. A search result alone is never proof: the run opens the page before it relies on it. A change applies from the next run.

If the request names a system that is not connected, the session stops and asks you, rather than guessing. When a decision belongs to a person, the run files it in My Approvals and waits; deciding there lets it continue.

What a check looks at

A control's check is only as good as what its session actually read. Before it records a result, the session shows in the chat what it read — the rows from the app or register, or the exact sentence it quotes — and then its conclusion. So you can read the session and judge it yourself.

• A pass needs something read. A check that read nothing cannot pass.
• A connected app or a register shows the rule is actually done.
• Documents alone show the rule is written, and Compliance says Written, not proven yet.
• Couldn't run is never a pass and never a fail. It says why — an app that is not connected, or a question waiting on a person.

A check records against the requirements its own request lists, and only for standards your workspace works with. It changes nothing in the record itself.

What a run keeps

Every session keeps its whole transcript: what it read, what it did, and what it cost. A control's result keeps its reason and what it read, beside the requirement on Compliance. Every result is kept; the latest one is what Compliance shows today.

Which account a run uses

A run acts as a person: whoever pressed Run now, or the person who added the control. It has that person's role and sees their teams, so it is refused exactly where they would be refused. If their role changes while a session waits, it picks up the change when it continues; if they leave the workspace, it carries on reading and stops writing.

When a run reaches a connected app, it uses that person's own connection if the app has personal accounts. If they have not connected theirs, the step stops and says so — connecting theirs under Settings → Connections is the fix. It never borrows someone else's account. An app that signs in with one shared key keeps using the workspace's connection.

Long jobs

Most requests in the chat are answered right there. A big one, such as building a whole standard, becomes a job. The assistant first shows you its plan, an estimate and a ceiling, both in credits, and asks for one yes. After that it works without asking again.

• It runs on the server. You can close the chat; the job carries on.
• You can follow it on the job's own page: a progress line, the credits used against the ceiling, and the agreed plan. The chat links to it.
• It pauses, it never ends half-way. It stops to wait when it reaches its ceiling, or when it needs a fact or a decision only you can give. The page says why. Press Resume to go on, from where it stopped.
• It ends with a receipt: what you asked, what it did, the credits it used, its steps and the tools it used.

Your one yes covers publishing the job's own documents and running its controls. Deleting, archiving and any change to a connected app still ask you every time; a job that reaches one pauses and waits for you.

A whole standard as one job

When you ask for a whole standard, the job takes one process at a time, in the order of the plan. You still say yes once, to one plan, one estimate and one ceiling; every process draws on that same ceiling.

• The job's page lists each process and how it stands: not started, working, paused or done, with the credits it used.
• It pauses on the whole job. When the ceiling is reached, or a process needs a fact from you, the whole job waits. Resume goes on with the process that stopped; finished processes are not redone.
• The receipt adds it all up: the credits used, the documents published, the controls run, and each process, including what paused or was left.
• It keeps a project to follow it. The job opens a project named after your request, with a task for each process, so you can track it with the rest of your work.

A job acts as you, with your role and your teams, exactly as a run does. Credits are the same meter as the chat's; see AI review and assistance.

From the chat

You can ask the assistant about a document's controls. It can run a control now, or switch it off or on, when you ask. How the assistant decides what to offer is on AI review and assistance.

Where you see it

• Controls in the sidebar: every control of the team, and each control's own page with its clock and its runs.
• Chat: every session, under Sessions in the rail for the team.
• My Approvals: any decision a run is waiting on.
• Compliance: each control's result, linked to its session.
• Your team's Activity: every run as one line, newest first; see Teams. A run's record is kept even if the document is later deleted.