> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aptlydone.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Document Management

> How Aptly captures policies, procedures, and supporting documents — linked or uploaded — and connects them to Decisions and Delegations with oversight, versioning, and sharing controls.

## Overview

Documents in Aptly capture the **policies, procedures, protocols, and supporting materials** that govern decisions and delegations of authority. Each document can be either **linked** to an external file or **uploaded** directly into Aptly, and once created can be associated with one or more Decisions and Delegations so the relevant context travels with the authority record.

Documents move through a simple lifecycle — **Draft**, **Published**, **Archived**, **Deleted** — and can carry oversight stakeholders, versioning metadata, and (when enabled) external sharing controls.

> The Documents module appears in the left navigation when `tenant.access_documents_module` is granted by the user's role.

***

## 🔗 Linked vs. Uploaded documents

Aptly supports two distinct storage modes for documents. Both are configured at the tenant level under **Settings → Account Settings → Documents → Document Management**, and each can be enabled or disabled independently.

### Linked documents

A **linked** document references a file hosted outside Aptly — for example, on SharePoint, OneDrive, an intranet, or another document management system. Aptly stores the URL and metadata; the file itself stays at the source. Linked documents are useful when the source system is the authoritative store and Aptly should reference (not duplicate) the file.

### Uploaded documents

An **uploaded** document is stored directly within Aptly. Uploaded files support common office and image formats and are subject to a per-file size limit. Uploaded documents are the right choice when Aptly should be the system of record for the file, when external sharing of the file content is required, or when there's no existing DMS to link to.

> Either or both modes can be enabled for a tenant. Disabling Link Documents prevents new external links from being added; disabling Upload Documents prevents new files from being uploaded. Existing documents and their associations remain preserved either way — these settings control what users can do **going forward**.

***

## 📑 Document types

**Document Types** classify documents (e.g., Policy, Procedure, Protocol) so they can be filtered, reported on, and governed consistently.

* Aptly ships with default types — **Policy**, **Procedure**, and **Protocol** — each independently enableable.
* Admins can add **custom types** (e.g., Charter, Code of Conduct, Standard Operating Procedure) to reflect the organization's vocabulary.
* The Document Types feature itself has a master toggle. When disabled, document type selection is hidden when users create or link documents.
* Individual types each have an enable/disable toggle. Disabling a type removes it from selection for new documents but preserves historical records.

> Document type names must be unique within the tenant.

***

## 🔁 Document versioning

**Document Versioning** captures version-related metadata on documents — useful for audit trails, regulatory compliance, and change tracking.

### Default versioning fields

Three default fields ship with Aptly, each independently toggleable:

* **Effective Date** — the date the document version takes effect.
* **Code** — a free-form identifier (e.g., `POL-FIN-001`).
* **Version** — a free-form version label (e.g., `1.0`, `2.3`, `Final`).

### Custom versioning fields

Admins can add custom versioning fields (e.g., "Regulatory Reference," "Revision Cycle") with a configurable Field Name and Field Type (**Alphanumeric** or **Date**). Custom fields appear on every document when enabled and behave the same way as default fields. Field names must be unique within the tenant.

### Master toggle

When **Document Versioning** is disabled at the tenant level, versioning fields are hidden from individual document Settings and users cannot enter versioning data on new or existing documents. Existing version metadata is retained and reappears if the feature is re-enabled.

***

## 👥 Document Oversight

**Document Oversight** defines accountability for each document and (optionally) automates the generation of approval and review tasks. It's configured at the tenant level under **Settings → Account Settings → Documents → Document Oversight**.

### Oversight roles

| Role            | Purpose                                                               | Notes                                  |
| --------------- | --------------------------------------------------------------------- | -------------------------------------- |
| **Owner**       | The person accountable for the document overall.                      | Always present; cannot be disabled.    |
| **Responsible** | Accountable for content accuracy and applicability.                   | Independently enableable. Single user. |
| **Approver**    | Must formally approve the document before it is considered finalized. | Independently enableable. Single user. |
| **Reviewer**    | Performs initial and periodic review for compliance or relevance.     | Independently enableable. Single user. |

> Oversight assignments are made to **specific users** (Specific Personnel). Oversight does not use position-based or role-based eligibility evaluation.

### Action generation

Two optional toggles drive automatic Action creation when oversight roles apply:

* **Generate Approval Action** — only adjustable when **Approver** is enabled. When on, assigning an Approver to a document (or editing a document that already has an Approver assigned) creates a **Document Approval Action** routed to that Approver. The document's status reflects **Approval Pending** until the Approver approves or rejects it.
* **Generate Review Action** — only adjustable when **Reviewer** is enabled. When on, assigning a Reviewer (or editing a document with a Reviewer assigned) creates a **Document Review Action**. The document's status reflects **Review Pending** until the Reviewer marks it reviewed.

When a document is edited after approval or review, the prior status reverts to Pending and a new Action is generated; any previously open Action is automatically cancelled.

> If Document Oversight is disabled at the tenant level, oversight roles and fields are hidden across the platform, and no approval or review Actions are generated. Disabling action generation while oversight roles remain enabled cancels any open approval/review Actions.

> See [Actions and Workflows →](/essentials/actions-and-workflows) for how Document Approval and Document Review Actions are routed, completed, and tracked alongside other system-generated Actions.

***

## 📎 Associating documents with Decisions and Delegations

Documents become operationally meaningful when associated with the authority records they govern.

### How associations are created

Document associations to Decisions and Delegations are created **from within the Decision or Delegation record**, not from the Documents module. The flow:

1. Open the Decision or Delegation record.
2. In the Documents section, click **Link Document**.
3. Either select an existing document or create a new one in the same flow.

Documents can be created independently in the Documents module (and remain unassociated until linked from a Decision or Delegation), but the **association** is always made on the Decision/Delegation side.

### Cascading behavior

* **Decision-level documents** cascade to all delegations issued from that Decision. Users viewing a delegation see the parent Decision's documents alongside any documents attached to the delegation itself.
* **Delegation-level documents** apply only to that specific delegation and do **not** cascade to redelegations issued from it.

This split lets organizations attach broad policy at the Decision level (where it applies to every delegation in the chain) and attach delegation-specific terms at the individual delegation level.

***

## 📤 External sharing

When enabled, documents stored in Aptly (uploaded documents) can be shared with people who do not have an Aptly login.

### Account-level controls

Configured under **Settings → Account Settings → Documents → Document Sharing**:

* **External Sharing** — when enabled, document owners can generate shareable links for external recipients. When disabled, external sharing options are hidden on individual documents.
* **Require Password** — when enabled, all externally shared document links must be password-protected. The password control on individual documents appears enabled and may be non-editable.

> External sharing and password enforcement may be controlled by subscription level. If these controls are not visible in your tenant, they may not be enabled for your plan.

### Document-level controls

When External Sharing is enabled at the account level, the document owner can configure the shareable link, optional expiration, and password (if not already enforced at the tenant level) on the individual document.

> Linked documents (which reference external files) are governed by the host system's sharing model — Aptly's external sharing controls apply to **uploaded** documents.

***

## 🔐 Permissions

Access to documents is governed by role permissions in the `document` namespace, scoped using the **sharing-aware** scope set, plus stakeholder relationships (Owner, Responsible, Reviewer, Approver, shared users/groups) that grant additional record-specific access.

| Permission                                                                                             | Options                                             | Controls                                                                                                               |
| ------------------------------------------------------------------------------------------------------ | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `tenant.access_documents_module`                                                                       | Toggle (On/Off)                                     | Whether the **Documents** module appears in the left navigation.                                                       |
| `document.view` / `document.create` / `document.edit` / `document.archive_restore` / `document.delete` | Global / Groups or User Shared / User Shared / None | Core access to view, create, edit, archive/restore, and delete documents.                                              |
| `document.share`                                                                                       | Global / Groups or User Shared / User Shared / None | Manage document sharing settings (internal sharing and external link configuration).                                   |
| `document.view_change_log`                                                                             | Global / Groups or User Shared / User Shared / None | View the changelog of a document's history.                                                                            |
| `document.change_owner`                                                                                | Toggle (On/Off)                                     | Reassign the owner of a document. Intentionally separated from `document.edit` to tightly control ownership transfers. |

**Sharing-aware scope set** (used by Documents and Matrices):

* **Global** — applies across all documents in the tenant.
* **Groups or User Shared** — applies when the document is group-aligned with the user's effective group membership *or* explicitly shared to the user.
* **User Shared** — applies only when the document is explicitly shared to the user.
* **None** — no access via the role.

### Stakeholder inheritance

Beyond role permissions, oversight stakeholders inherit access to the documents they're assigned to:

* **Owner** — broader management rights including edit, archive/restore, share, and view changelog.
* **Responsible** — edit access on documents they're responsible for.
* **Approver** — approve/reject access on documents awaiting approval.
* **Reviewer** — review access on documents awaiting review.

> See [Roles & Permissions →](/essentials/roles-permissions) for the full permission model, default role descriptions, and how permissions, scopes, and stakeholder relationships combine to determine effective access.

***

## 🧾 Related Pages

* [System Settings Overview →](/essentials/system-settings)
* [Delegation Lifecycle →](/essentials/delegation-lifecycle)
* [Delegation Approvals & Logic →](/essentials/delegation-approvals)
* [Actions and Workflows →](/essentials/actions-and-workflows)
* [Roles & Permissions →](/essentials/roles-permissions)
* [Group Management →](/essentials/groups)
* [Matrix Management →](/essentials/matrix-management)

***

<Info>
  Need help modeling document oversight workflows, configuring versioning fields, or aligning documents with your delegation framework?
  Contact <a href="mailto:support@aptlydone.com">[support@aptlydone.com](mailto:support@aptlydone.com)</a> or visit the <a href="https://support.aptlydone.com/">Aptly Support Portal</a>.
</Info>