> ## Documentation Index > Fetch the complete documentation index at: https://docs.autype.com/llms.txt > Use this file to discover all available pages before exploring further. # Document processes > Create reusable review, QA, and approval flows for Workspace documents. # Document processes Document processes move one exact document revision through a reusable sequence of human checks. They are different from Engine automations: a Workspace process coordinates people around a document; n8n, Make, the API, and MCP remain the recommended surfaces for system-to-system automation. ## Start a process Open **Workspace → Processes** and choose **Start process**, or use **Document options → Start process** in the editor. 1. Choose a published process template. 2. Choose the Autype document. 3. Fill the template inputs. Inputs can be text, numbers, yes/no values, workspace members, email addresses, or PDF files. 4. Assign every role that is configured for selection at process start. A role may point to a workspace member or, where allowed, an external email address. 5. Review the template, document, participants, and optional revision note. 6. Start the process. Autype then pins the published template version and creates an immutable `WorkflowRevision` from the current document snapshot. Reviewers decide on that revision, not on a silently changing editor draft. ## Process views * **Running** shows active documents, the current step, status, revision, and next action. * **Templates** contains the three executable Autype starting templates and your company templates. System templates are immutable; choose **Customize a copy** before changing one. * **History** contains completed, rejected, canceled, and failed runs. The run detail can export a JSON audit record with revisions, decisions, timestamps, and hashes. ## Build a reusable template The fullscreen builder has two parts: available steps on the left and one fixed, top-to-bottom process canvas in the center. The small **+** positions between steps are insertion points: drag a block onto the exact position where it should run. While dragging, every insertion point immediately shows whether that block's input and output types are compatible. An incompatible drop is rejected before it can change the template. Clicking a palette block provides a touch and keyboard fallback and inserts it at the latest compatible position. Existing process blocks use quiet dashed borders without card shadows and remain in their fixed sequence: they cannot be freely moved or wired, so the process stays readable and cannot acquire invalid branches. Autype creates the required success, change-request, and rejection behavior automatically. A successful step continues downward, a change request returns to **Submit document**, and a failed decision ends the process. For a review, **If rejected** can either end the process or return to one of the earlier steps offered by the builder. Forward jumps and arbitrary cycles are not available. These outcomes are summarized on the affected step instead of being shown as editable branches. Definitions created with the earlier canvas may still contain `ui.positions`. Those coordinates remain valid for backward compatibility and survive edits, but the linear builder intentionally ignores them. Click a step or its pencil button to configure its details in a focused modal. Removable steps have a visible trash button directly on the card; undo restores an accidental removal. **Submit document** cannot be deleted, and **Completed** is shown as a subdued status marker rather than another editable step. New and invalid steps are shown in red until their required person, document source, and step-specific settings are complete. Undo and redo remain available. The mandatory start, document submission, and completion structure is protected; additional review, approval, task, and PDF-finishing steps can be inserted safely. | Block | Purpose | Outputs | | - | - | - | | Submit document | Pin the first or changed Autype revision | Submitted document | | Review | Approve, request changes, or reject | Approved / changes / rejected | | QA checklist | Require named quality checks | Passed / changes / failed | | Approval | Collect one or more approvals in order or in parallel | Approved / changes / rejected | | Manual task | Assign a clear human action | Completed / canceled | | Create PDF | Render the pinned document | PDF document | | Add attachments | Append one or more uploaded PDFs | Combined PDF | | Watermark | Add a text watermark | Watermarked PDF | | Protect PDF | Encrypt the PDF with a runtime password | Protected PDF | | Compress PDF | Reduce PDF file size | Compressed PDF | | Flatten PDF | Flatten fields and annotations | Flattened PDF | | Signature | Collect a typed-name simple electronic signature on the pinned revision | Newly rendered signed PDF | Every step has a fixed input and output contract. The document input is not manually selectable: it is always connected to the immediately previous successful step. Only the first **Submit document** step receives the document chosen when the process starts. Separate runtime inputs such as attachments and PDF passwords remain selectable where needed. Unknown input names, skipped document sources, future outputs, missing outputs, and incompatible types are rejected by the shared validator and API. Human review steps consume and return an Autype document. **Create PDF** converts that document to PDF. Watermark, protect, compress, flatten, and attachment steps accept PDF only. When a PDF-only step is added at the end of a document flow, the builder inserts **Create PDF** automatically. A document-only review cannot be placed after PDF creation, and a PDF-only operation cannot be placed between two document-only steps. Mark the last PDF operation as the final process output; Autype copies it from temporary tool storage into durable organization storage and offers it for download from the process detail. A signature is a final human action on an Autype document revision. It cannot follow PDF finishing steps: after all signers have acted, Autype fills the role-bound signature fields in the pinned snapshot and renders a new durable PDF from that exact snapshot. Process inputs are defined once under **Process settings**. A `document` input represents the selected Autype document. `file` inputs upload PDFs for operations such as adding attachments. Sensitive text inputs, including PDF passwords, are filled at process start, encrypted at rest, redacted from API responses and job history, and never stored in the template. Template roles are reusable responsibilities such as Author, QA, Legal, or Customer. A role can be configured in the selected block as: * **Choose when process starts** — select a workspace member or enter an external email when starting the run. * **Fixed workspace member** — always assign the same organization member. * **Fixed external email** — always invite the same external participant. The document author is intentionally limited to workspace members because that person must edit and submit an Autype revision. Reviewers, QA participants, approvers, task owners, and email-link signers may be internal or external. External participants receive a random, hashed, expiring access link. The link shows only the process and the immutable revision assigned to that participant; sequential approvals stay unavailable until the preceding participant has acted. External actions use the same checklist, outcome, idempotency, and audit rules as workspace actions. The public page embeds a PDF rendered from the exact pinned workflow snapshot; later editor changes cannot alter that preview. Invitation delivery is visible in the run detail as pending, sending, sent, failed, or revoked. Autype retries temporary failures up to five times and recovers an interrupted delivery claim after a worker restart. The process starter or an organization admin can resend an invitation, which rotates its token, or revoke it immediately. A revoked or expired link returns no process data. Configure `FRONTEND_URL` with the canonical public origin in production so emails never contain localhost links. In local development, transactional messages use a safe structured outbox log by default instead of contacting real recipients. Search the API log for `Development email outbox`; its fields contain the intended recipient, subject, plain-text message, and `actionUrls` such as the temporary `/process/...` link. Set `EMAIL_DELIVERY_MODE=provider` only when a deliberate local provider test is required. Production always uses provider delivery and never enables the log outbox. On smaller screens, **Steps** and **Process** switch between the palette and the fixed flow without horizontal scrolling. Step details still open in the same focused modal. Publishing validates every node, outcome, role reference, cycle, and deadline. A published version is immutable. Editing it creates a new draft; restoring an older version also creates a new draft. Existing runs always keep their originally pinned version. ## Requested changes and revisions **Request changes** does not end a run. It records the decision against the current hash, returns the run to **Waiting for changes**, and lets the assigned author submit a new revision with a summary. Previous steps, comments, and decisions remain in the audit trail. Downstream decisions always refer to one specific revision and are never silently transferred to a newer draft. ## Permissions and safety * Reading requires Workspace access and document read permission. * Starting or resubmitting requires editor access to the document. * Only the participant assigned to a step can decide it. * Publishing, archiving, and restoring templates requires an organization owner or admin. * Only the process starter or an organization owner/admin can cancel a run. * Only the comment author or process owner can resolve a current-revision comment; completed and older revisions remain immutable. * The four-eyes option rejects role assignments that resolve to the same person. * Fixed participants are validated against the organization when a run starts; fixed assignments cannot be overridden by a request payload. * External links are stored only as SHA-256 hashes, expire after 30 days, and are rate limited. A token is scoped to one run and one role; resending rotates it and revoking invalidates it immediately. * Process inputs are type checked and unknown inputs are rejected. Uploaded file inputs must belong to the same organization and must not be expired. * Final PDF outputs are durable assets; intermediate tool files remain short-lived. * System templates cannot be edited, archived, or restored. * Snapshot, revision, decision, and template hashes are calculated server-side. * PDF previews and workflow PDF blocks render the pinned workflow snapshot, not the latest mutable document state. * Documents referenced by an audit trail cannot be deleted through the editor. The Workspace builder supports **simple electronic signatures** by typed name. Each successful action records the signer role, authenticated account or secure email-link method, server time, template/revision identifiers, and source hash. The document must contain required `signature` (and, when configured, `initials`) fields whose `signerRole` matches the process role, unless the block explicitly allows confirmation-only signing. The final artifact is rendered as PDF/A-2b with the matched fields flattened, so the typed name and initials are visibly embedded rather than left editable. This is not a cryptographic, qualified, or PAdES signature. Secure email links and authenticated Autype accounts are executable now. Email OTP, manual link distribution, imported byte-exact external PDFs, and arbitrary visual field placement on an already finished PDF remain separate follow-up work. User-selectable PDF/A and page-number process operations also remain hidden until their worker implementations are available. The process definition is validated by the shared `WorkflowDefinition` Zod schema. The generated JSON Schema is `shared/schemas/generated/workflow-definition.schema.json`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.