mirror of
https://github.com/documenso/documenso.git
synced 2026-07-25 17:35:05 +10:00
feat: docs v2 (#2460)
Co-authored-by: Catalin Pit <catalinpit@gmail.com>
This commit is contained in:
Lucas Smith
GitHub
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: Document Lifecycle
|
||||
description: Track document progress through draft, pending, completed, and rejected states.
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
|
||||
## Document States
|
||||
|
||||
A document can be in one of four states:
|
||||
|
||||
| State | Description |
|
||||
| ------------- | ----------------------------------------------------------------- |
|
||||
| **Draft** | Document is being prepared and has not been sent |
|
||||
| **Pending** | Document has been sent and is awaiting recipient actions |
|
||||
| **Completed** | All recipients have completed their required actions |
|
||||
| **Rejected** | A recipient has rejected the document (when rejection is enabled) |
|
||||
|
||||
## How a Document Moves Through States
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Draft -- Send --> Pending
|
||||
Pending -- All recipients complete --> Completed
|
||||
Pending -- Recipient rejects --> Rejected
|
||||
```
|
||||
|
||||
## Draft
|
||||
|
||||
When you upload a document or create one from a template, it starts in the **Draft** state. In this state, you can:
|
||||
|
||||
- Add and remove recipients
|
||||
- Assign roles to recipients (signer, approver, viewer, CC)
|
||||
- Add, move, and configure fields
|
||||
- Set signing order
|
||||
- Configure document settings (expiration, reminders, rejection)
|
||||
- Delete the document
|
||||
|
||||
A draft document is only visible to you (the owner) and team members with appropriate permissions. Recipients cannot see or access the document until you send it.
|
||||
|
||||
**Transition:** A draft becomes **Pending** when you send it to recipients.
|
||||
|
||||
## Pending
|
||||
|
||||
Once sent, a document enters the **Pending** state. Recipients receive email notifications with links to view and complete their assigned actions.
|
||||
|
||||
While pending, you can:
|
||||
|
||||
- View recipient progress
|
||||
- Resend notifications to recipients
|
||||
- Void the document (cancels all pending actions)
|
||||
|
||||
<Callout type="info">
|
||||
You cannot modify the document content, recipients, or fields while it is pending.
|
||||
</Callout>
|
||||
|
||||
**Transitions:**
|
||||
|
||||
- Becomes **Completed** when all recipients finish their required actions
|
||||
- Becomes **Rejected** if any recipient rejects the document (requires rejection to be enabled)
|
||||
|
||||
## Completed
|
||||
|
||||
A document reaches the **Completed** state when all recipients have fulfilled their roles:
|
||||
|
||||
- Signers have signed
|
||||
- Approvers have approved
|
||||
- Viewers have viewed (if view confirmation is required)
|
||||
|
||||
At completion:
|
||||
|
||||
- All parties receive a copy of the signed document
|
||||
- The document is sealed with a digital certificate
|
||||
- An audit log is attached showing all actions taken
|
||||
|
||||
<Callout type="info">
|
||||
Completed documents cannot be modified. You can download the signed PDF or view the audit trail.
|
||||
</Callout>
|
||||
|
||||
## Rejected
|
||||
|
||||
If you enable document rejection in settings, recipients can reject instead of signing. When any recipient rejects:
|
||||
|
||||
- The document immediately moves to **Rejected** state
|
||||
- Other pending recipients can no longer act on the document
|
||||
- The document owner is notified
|
||||
|
||||
<Callout type="info">
|
||||
Rejected documents cannot be modified or reactivated. To proceed, you need to create a new
|
||||
document.
|
||||
</Callout>
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [Recipient Roles](/docs/concepts/recipient-roles) - The different roles recipients can have
|
||||
- [Field Types](/docs/concepts/field-types) - Fields you can add to documents
|
||||
- [Signing Workflow](/docs/concepts/signing-workflow) - How the signing process works for recipients
|
||||
@@ -0,0 +1,314 @@
|
||||
---
|
||||
title: Field Types
|
||||
description: Placeholder types for capturing signatures, text, dates, and selections during signing.
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
|
||||
## Field Types Overview
|
||||
|
||||
| Field Type | Description | Auto-filled |
|
||||
| ---------- | ------------------------------------------------- | ----------- |
|
||||
| Signature | Recipient's signature (drawn, typed, or uploaded) | No |
|
||||
| Initials | Recipient's initials | No |
|
||||
| Email | Recipient's email address | Yes |
|
||||
| Name | Recipient's full name | Yes |
|
||||
| Date | Date the field was completed | Yes |
|
||||
| Text | Free-form text input | No |
|
||||
| Number | Numeric input with optional validation | No |
|
||||
| Radio | Single selection from a list of options | No |
|
||||
| Checkbox | Multiple selections from a list of options | No |
|
||||
| Dropdown | Single selection from a dropdown menu | No |
|
||||
|
||||
## Signature
|
||||
|
||||
|
||||
|
||||
The signature field captures the recipient's legally binding signature. Recipients can:
|
||||
|
||||
- **Draw** their signature using a mouse or touchscreen
|
||||
- **Type** their name and select a font style
|
||||
- **Upload** an image of their signature
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| --------- | -------------------------------------------------- |
|
||||
| Required | Whether the field must be completed before signing |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Contract execution
|
||||
- Agreement acceptance
|
||||
- Authorization approvals
|
||||
|
||||
<Callout type="info">Each signer must have at least one Signature field assigned to them.</Callout>
|
||||
|
||||
## Initials
|
||||
|
||||
The initials field captures abbreviated signatures, typically used to acknowledge individual pages or clauses.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| -------------- | -------------------------------------- |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Page acknowledgment
|
||||
- Clause acceptance
|
||||
- Change or amendment approval
|
||||
|
||||
## Email
|
||||
|
||||
The email field displays the recipient's email address. This field is automatically populated with the email address used to send the signing request.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| -------------- | --------------------------------------------------- |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field (recommended for auto-filled values) |
|
||||
| Label | Display text shown above the field |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Contact information sections
|
||||
- Identity verification
|
||||
- Record keeping
|
||||
|
||||
## Name
|
||||
|
||||
The name field captures the recipient's full name. When the recipient has a name on file, the field can be auto-populated.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| -------------- | -------------------------------------- |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Signature blocks
|
||||
- Party identification
|
||||
- Contact details
|
||||
|
||||
## Date
|
||||
|
||||
The date field records when the recipient completed the field or signed the document. By default, it auto-fills with the current date.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| -------------- | -------------------------------------- |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Signature date
|
||||
- Agreement effective date
|
||||
- Timestamp records
|
||||
|
||||
## Text
|
||||
|
||||
|
||||
|
||||
The text field accepts free-form text input from recipients. Use this for any information that doesn't fit other field types.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| --------------- | ------------------------------------------ |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
| Placeholder | Hint text shown when the field is empty |
|
||||
| Default value | Pre-filled text that recipients can modify |
|
||||
| Character limit | Maximum number of characters allowed |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
| Line height | Spacing between lines of text |
|
||||
| Letter spacing | Spacing between characters |
|
||||
|
||||
### Rules
|
||||
|
||||
- A field cannot be both required and read-only at the same time
|
||||
- A read-only field must have a default text value (it cannot be empty)
|
||||
- The field is inserted automatically into the document if there is a default text value
|
||||
- The text field character count cannot exceed the character limit
|
||||
- The signer cannot modify a read-only field
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Address input
|
||||
- Company names
|
||||
- Job titles
|
||||
- Custom information
|
||||
|
||||
## Number
|
||||
|
||||
The number field accepts numeric input with optional validation constraints.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| -------------- | -------------------------------------------- |
|
||||
| Required | Whether the field must be completed |
|
||||
| Read-only | Lock the field with a pre-filled value |
|
||||
| Label | Display text shown above the field |
|
||||
| Placeholder | Hint text shown when the field is empty |
|
||||
| Default value | Pre-filled number that recipients can modify |
|
||||
| Minimum value | Lowest allowed number |
|
||||
| Maximum value | Highest allowed number |
|
||||
| Number format | Display format for the number |
|
||||
| Text alignment | Left, center, or right alignment |
|
||||
|
||||
### Rules
|
||||
|
||||
- The value must be a number
|
||||
- A field cannot be both required and read-only at the same time
|
||||
- A read-only field must have a default number value
|
||||
- If a default number and a maximum value are set, the default must be less than the maximum
|
||||
- If a default number and a minimum value are set, the default must be greater than the minimum
|
||||
- The value must match the number format if a number format is set
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Quantities
|
||||
- Pricing
|
||||
- Phone numbers
|
||||
- Employee IDs
|
||||
|
||||
## Radio
|
||||
|
||||
The radio field presents a list of options where the recipient can select exactly one.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| ----------------- | ---------------------------------------- |
|
||||
| Required | Whether a selection must be made |
|
||||
| Read-only | Lock the field with a pre-selected value |
|
||||
| Label | Display text shown above the field |
|
||||
| Options | List of selectable values |
|
||||
| Default selection | Pre-selected option |
|
||||
| Direction | Vertical or horizontal layout |
|
||||
|
||||
### Rules
|
||||
|
||||
- A field cannot be both required and read-only at the same time
|
||||
- A read-only field must have at least one option
|
||||
- The field auto-signs if there is a default value
|
||||
- The signer cannot select a value that's not in the options list
|
||||
- Only one option can be selected at a time
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Yes/No questions
|
||||
- Single-choice selections
|
||||
- Status indicators
|
||||
- Plan or tier selection
|
||||
|
||||
## Checkbox
|
||||
|
||||
|
||||
|
||||
The checkbox field presents a list of options where the recipient can select multiple items.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| ------------------ | ------------------------------------------- |
|
||||
| Required | Whether at least one selection must be made |
|
||||
| Read-only | Lock the field with pre-selected values |
|
||||
| Label | Display text shown above the field |
|
||||
| Options | List of selectable values |
|
||||
| Default selections | Pre-selected options |
|
||||
| Validation rule | Rules for minimum/maximum selections |
|
||||
| Direction | Vertical or horizontal layout |
|
||||
|
||||
### Rules
|
||||
|
||||
- A field cannot be both required and read-only at the same time
|
||||
- A read-only field must have at least one checked option
|
||||
- The field auto-signs if there are default values
|
||||
- The validation rule enforces selection counts: "At least", "At most", or "Exactly" a specified number of options
|
||||
- The signer cannot select a value that's not in the options list
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Terms and conditions acceptance
|
||||
- Multiple acknowledgments
|
||||
- Feature selection
|
||||
- Preference lists
|
||||
|
||||
## Dropdown
|
||||
|
||||
|
||||
|
||||
The dropdown field presents a list of options in a collapsible menu. Recipients select one option from the list.
|
||||
|
||||
### Configuration Options
|
||||
|
||||
| Option | Description |
|
||||
| ------------- | ---------------------------------------- |
|
||||
| Required | Whether a selection must be made |
|
||||
| Read-only | Lock the field with a pre-selected value |
|
||||
| Label | Display text shown above the field |
|
||||
| Options | List of selectable values |
|
||||
| Default value | Pre-selected option |
|
||||
|
||||
### Rules
|
||||
|
||||
- A field cannot be both required and read-only at the same time
|
||||
- A read-only field must have a default value
|
||||
- The default value must be one of the options
|
||||
- The field auto-signs if there is a default value
|
||||
- The signer cannot select a value that's not in the options list
|
||||
|
||||
### Common Use Cases
|
||||
|
||||
- Country or state selection
|
||||
- Department selection
|
||||
- Category classification
|
||||
- Status selection
|
||||
|
||||
## Common Configuration Options
|
||||
|
||||
All field types share these base configuration options:
|
||||
|
||||
| Option | Description | Default |
|
||||
| --------- | --------------------------------------------------- | ------- |
|
||||
| Required | Recipient must complete the field to finish signing | `false` |
|
||||
| Read-only | Field value cannot be changed by the recipient | `false` |
|
||||
| Label | Text displayed above or near the field | None |
|
||||
| Font size | Size of the text in the field (8-96px) | 12px |
|
||||
|
||||
## Validation
|
||||
|
||||
Fields validate input based on their type and configuration:
|
||||
|
||||
- **Required fields** must be completed before the recipient can finish signing
|
||||
- **Read-only fields** display pre-filled values that cannot be modified
|
||||
- **Number fields** validate against minimum and maximum values when configured
|
||||
- **Checkbox fields** can enforce a minimum or maximum number of selections
|
||||
|
||||
If validation fails, the recipient sees an error message and must correct the input before proceeding.
|
||||
|
||||
## Related
|
||||
|
||||
- [Add Fields to Documents](/docs/users/documents/add-fields) - Learn how to place fields on your documents
|
||||
- [Recipient Roles](/docs/concepts/recipient-roles) - Understand who can be assigned fields
|
||||
- [Fields API](/docs/developers/api/fields) - Programmatically add fields via the API
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Concepts
|
||||
description: Foundational concepts behind document signing, recipient roles, field types, and certificates.
|
||||
---
|
||||
|
||||
## Core Concepts
|
||||
|
||||
<Cards>
|
||||
<Card
|
||||
title="Document Lifecycle"
|
||||
description="How documents move from draft to pending to completed or rejected."
|
||||
href="/docs/concepts/document-lifecycle"
|
||||
/>
|
||||
<Card
|
||||
title="Recipient Roles"
|
||||
description="Signers, approvers, viewers, assistants, and CC recipients."
|
||||
href="/docs/concepts/recipient-roles"
|
||||
/>
|
||||
<Card
|
||||
title="Field Types"
|
||||
description="Signatures, text, dates, checkboxes, dropdowns, and more."
|
||||
href="/docs/concepts/field-types"
|
||||
/>
|
||||
<Card
|
||||
title="Signing Workflow"
|
||||
description="The complete process from preparing a document to collecting signatures and sealing the final PDF."
|
||||
href="/docs/concepts/signing-workflow"
|
||||
/>
|
||||
<Card
|
||||
title="Signing Certificates"
|
||||
description="How documents are digitally signed and verified."
|
||||
href="/docs/concepts/signing-certificates"
|
||||
/>
|
||||
</Cards>
|
||||
|
||||
---
|
||||
|
||||
## How These Concepts Apply
|
||||
|
||||
These concepts work consistently across all ways you interact with Documenso:
|
||||
|
||||
- **Web application**: When you create documents in the UI, you'll select recipient roles, add fields, and track documents through their lifecycle states.
|
||||
|
||||
- **API integration**: The same concepts map directly to API endpoints. Documents have status fields, recipients have role properties, and fields have type configurations.
|
||||
|
||||
- **Self-hosting**: The signing certificate concept becomes particularly relevant when you deploy your own instance and configure your own certificates for document signing.
|
||||
|
||||
Understanding these fundamentals will make the rest of the documentation easier to follow.
|
||||
|
||||
---
|
||||
|
||||
## Related Sections
|
||||
|
||||
<Cards>
|
||||
<Card
|
||||
title="User Guide"
|
||||
description="Apply these concepts when sending documents."
|
||||
href="/docs/users"
|
||||
/>
|
||||
<Card
|
||||
title="Developer Guide"
|
||||
description="Work with these concepts through the API."
|
||||
href="/docs/developers"
|
||||
/>
|
||||
<Card
|
||||
title="Compliance"
|
||||
description="How these concepts relate to legal standards."
|
||||
href="/docs/compliance"
|
||||
/>
|
||||
</Cards>
|
||||
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"title": "Concepts",
|
||||
"pages": [
|
||||
"document-lifecycle",
|
||||
"recipient-roles",
|
||||
"field-types",
|
||||
"signing-workflow",
|
||||
"signing-certificates"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,171 @@
|
||||
---
|
||||
title: Recipient Roles
|
||||
description: Signers, approvers, viewers, assistants, and CC recipients.
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
|
||||
|
||||
## Role Overview
|
||||
|
||||
| Role | Action Required | Can Sign | Description |
|
||||
| --------- | --------------- | -------- | ---------------------------------------- |
|
||||
| Signer | Yes | Yes | Must sign the document |
|
||||
| Approver | Yes | Optional | Must approve the document |
|
||||
| Viewer | Yes | No | Must view the document |
|
||||
| Assistant | Yes | No | Can pre-fill fields for other recipients |
|
||||
| CC | No | No | Receives a copy after completion |
|
||||
|
||||
## Role Details
|
||||
|
||||
<Tabs items={['Signer', 'Approver', 'Viewer', 'Assistant', 'CC']}>
|
||||
<Tab value="Signer">
|
||||
|
||||
Signers are the primary recipients of a document. They must complete all signature fields assigned to them before the document can be finalized.
|
||||
|
||||
**What they can do:**
|
||||
|
||||
- Sign signature fields assigned to them
|
||||
- Fill out any other fields assigned to them (text, date, checkbox, etc.)
|
||||
- Download the document after signing
|
||||
|
||||
**What they cannot do:**
|
||||
|
||||
- Sign on behalf of other recipients
|
||||
- Modify fields assigned to other recipients
|
||||
|
||||
**When to use this role:**
|
||||
|
||||
- Contracts requiring a legally binding signature
|
||||
- Agreements where the recipient must formally consent
|
||||
- Any document that requires a signature to be valid
|
||||
|
||||
</Tab>
|
||||
<Tab value="Approver">
|
||||
|
||||
Approvers must review and approve the document, but signing is optional. The document cannot be completed until all approvers have given their approval.
|
||||
|
||||
**What they can do:**
|
||||
|
||||
- Approve or reject the document
|
||||
- Optionally add a signature if signature fields are assigned
|
||||
- Fill out fields assigned to them
|
||||
- Download the document after approval
|
||||
|
||||
**What they cannot do:**
|
||||
|
||||
- Complete the document without explicitly approving it
|
||||
- Modify fields assigned to other recipients
|
||||
|
||||
**When to use this role:**
|
||||
|
||||
- Documents requiring manager or supervisor approval
|
||||
- Workflows where review is required before final signatures
|
||||
- Compliance processes requiring sign-off from multiple parties
|
||||
|
||||
</Tab>
|
||||
<Tab value="Viewer">
|
||||
|
||||
Viewers must acknowledge that they have viewed the document. They cannot add signatures but must confirm they have reviewed the content.
|
||||
|
||||
**What they can do:**
|
||||
|
||||
- View the complete document
|
||||
- Confirm they have viewed it
|
||||
- Download the document after viewing
|
||||
|
||||
**What they cannot do:**
|
||||
|
||||
- Sign the document
|
||||
- Fill out fields (no fields can be assigned to viewers)
|
||||
- Modify the document in any way
|
||||
|
||||
**When to use this role:**
|
||||
|
||||
- Informational documents that require acknowledgment
|
||||
- Policies or disclosures that recipients must review
|
||||
- Documents where you need proof of receipt without a signature
|
||||
|
||||
</Tab>
|
||||
<Tab value="Assistant">
|
||||
|
||||
Assistants can prepare the document by pre-filling fields on behalf of other signers. This role is only available when sequential signing is enabled.
|
||||
|
||||
**What they can do:**
|
||||
|
||||
- Pre-fill suggested values in fields assigned to later signers
|
||||
- Help prepare the document for the actual signers
|
||||
- Fill out any fields specifically assigned to them
|
||||
|
||||
**What they cannot do:**
|
||||
|
||||
- Sign on behalf of other recipients
|
||||
- Submit the document as complete
|
||||
- Be used in parallel signing mode
|
||||
|
||||
**When to use this role:**
|
||||
|
||||
- Administrative staff preparing documents for executives to sign
|
||||
- Workflows where one person gathers information and another signs
|
||||
- Situations where you want to reduce the burden on the final signer
|
||||
|
||||
<Callout type="info">
|
||||
The Assistant role requires sequential signing to be enabled. You cannot use this role when
|
||||
recipients sign in parallel.
|
||||
</Callout>
|
||||
|
||||
</Tab>
|
||||
<Tab value="CC">
|
||||
|
||||
CC recipients receive a copy of the completed document but do not need to take any action. They are notified when the document is fully signed.
|
||||
|
||||
**What they can do:**
|
||||
|
||||
- Receive a copy of the completed document
|
||||
- Download the signed document
|
||||
|
||||
**What they cannot do:**
|
||||
|
||||
- Sign or approve the document
|
||||
- View the document before it is completed
|
||||
- Take any action that affects document completion
|
||||
|
||||
**When to use this role:**
|
||||
|
||||
- Keeping stakeholders informed about signed agreements
|
||||
- Sending copies to legal or compliance teams
|
||||
- Archiving completed documents with relevant parties
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Signing Order
|
||||
|
||||
You can control the sequence in which recipients receive and act on a document by enabling signing order.
|
||||
|
||||
<Tabs items={['Parallel signing (default)', 'Sequential signing']}>
|
||||
<Tab value="Parallel signing (default)">
|
||||
|
||||
All recipients receive the document simultaneously and can act in any order. The document is completed when all required recipients have finished their actions.
|
||||
|
||||
</Tab>
|
||||
<Tab value="Sequential signing">
|
||||
|
||||
Recipients receive the document one at a time, in the order you specify. Each recipient must complete their action before the next recipient is notified.
|
||||
|
||||
To enable sequential signing:
|
||||
|
||||
1. When adding recipients, check the "Enable signing order" option
|
||||
2. Assign an order number to each recipient
|
||||
3. Recipients with the same order number can act simultaneously
|
||||
4. The document proceeds to the next order number only when all recipients at the current level have completed their actions
|
||||
|
||||
<Callout type="info">Sequential signing is required if you want to use the Assistant role.</Callout>
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Related
|
||||
|
||||
- [Add Recipients](/users/documents/add-recipients) - How to add recipients to a document
|
||||
- [Field Types](/concepts/field-types) - Learn about the different field types you can assign to recipients
|
||||
@@ -0,0 +1,123 @@
|
||||
---
|
||||
title: Signing Certificates
|
||||
description: Documenso digitally signs completed documents using X.509 certificates, providing cryptographic proof of authenticity and integrity.
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
import { Step, Steps } from 'fumadocs-ui/components/steps';
|
||||
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
|
||||
|
||||
## How Documenso Signs Documents
|
||||
|
||||
Documenso applies a digital signature to the PDF when all recipients complete their actions.
|
||||
|
||||
{/* prettier-ignore */}
|
||||
<Steps>
|
||||
<Step>
|
||||
### Create hash
|
||||
|
||||
Creates a cryptographic hash of the document content.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Sign the hash
|
||||
|
||||
Signs the hash using the certificate's private key.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Embed signature
|
||||
|
||||
Embeds the signature and certificate information into the PDF.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
The signature is applied at the platform level, not by individual signers. Each signer's actions (signature image, text, checkboxes) are recorded and sealed together in the final signed document.
|
||||
|
||||
## What the Signature Proves
|
||||
|
||||
The digital signature provides two guarantees:
|
||||
|
||||
| Guarantee | Description |
|
||||
| ---------------- | -------------------------------------------------------------------------- |
|
||||
| **Integrity** | The document has not been altered since signing |
|
||||
| **Authenticity** | The document was signed by the certificate holder (the Documenso instance) |
|
||||
|
||||
If anyone modifies the PDF after signing, the signature becomes invalid. PDF readers will display a warning that the document has been changed.
|
||||
|
||||
## Timestamps
|
||||
|
||||
Documenso can include a trusted timestamp from a Time Stamping Authority (TSA) in the signature. This proves when the document was signed, independent of the signer's system clock. Timestamps are important for:
|
||||
|
||||
- Legal evidence of when signing occurred
|
||||
- Long-term validation (LTV) of signatures
|
||||
- Compliance with archival requirements
|
||||
|
||||
## Viewing the Signature in PDF Readers
|
||||
|
||||
You can verify a signed document's signature in any PDF reader that supports digital signatures.
|
||||
|
||||
<Tabs items={['Adobe Acrobat', 'Other PDF readers']}>
|
||||
<Tab value="Adobe Acrobat">
|
||||
|
||||
1. Open the signed PDF
|
||||
2. Click the signature panel on the left, or click on a signature field
|
||||
3. View certificate details, signing time, and validation status
|
||||
|
||||
</Tab>
|
||||
<Tab value="Other PDF readers">
|
||||
|
||||
Preview, Foxit, and other PDF readers also display signature information, though the interface varies. Look for a signatures or security panel in the application menu.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
The signature panel shows who signed (certificate subject), when it was signed, whether the document has been modified, and certificate trust status.
|
||||
|
||||
## Certificate Trust and Validation
|
||||
|
||||
PDF readers validate signatures against their list of trusted Certificate Authorities (CAs). You may see different validation results depending on the certificate type:
|
||||
|
||||
| Certificate Type | Validation Result |
|
||||
| ---------------- | ---------------------------------------------------------------------- |
|
||||
| **CA-issued** | Green checkmark in Adobe if the CA is on the Adobe Approved Trust List |
|
||||
| **Self-signed** | Warning that the certificate is not from a trusted source |
|
||||
|
||||
<Callout type="info">
|
||||
A self-signed certificate still provides integrity verification. The document cannot be modified without invalidating the signature. The warning only indicates that a third-party CA has not verified the certificate issuer's identity.
|
||||
|
||||
For most use cases, self-signed certificates are sufficient. The signature still proves the document came from your Documenso instance and has not been tampered with.
|
||||
|
||||
</Callout>
|
||||
|
||||
## Using Custom Certificates
|
||||
|
||||
If you self-host Documenso, you can use your own signing certificate.
|
||||
|
||||
<Tabs items={['Self-signed', 'CA-issued']}>
|
||||
<Tab value="Self-signed">
|
||||
|
||||
Free and suitable for most use cases. The signature still proves document integrity and authenticity.
|
||||
|
||||
You may see a warning in PDF readers that the certificate is not from a trusted source, but the document cannot be modified without invalidating the signature.
|
||||
|
||||
</Tab>
|
||||
<Tab value="CA-issued">
|
||||
|
||||
Provides trusted validation in PDF readers (e.g. green checkmark in Adobe) when the CA is on the Adobe Approved Trust List.
|
||||
|
||||
Required for some compliance scenarios where third-party verification of the certificate issuer is needed.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
See [Signing Certificate Configuration](/docs/self-hosting/configuration/signing-certificate) for setup instructions.
|
||||
|
||||
## Related
|
||||
|
||||
- [Signature Levels](/docs/compliance/signature-levels) - Simple, Advanced, and Qualified electronic signatures
|
||||
- [Standards and Regulations](/docs/compliance/standards) - ESIGN, eIDAS, and other compliance frameworks
|
||||
- [Signing Certificate Configuration](/docs/self-hosting/configuration/signing-certificate) - Self-hosting certificate setup
|
||||
@@ -0,0 +1,260 @@
|
||||
---
|
||||
title: Signing Workflow
|
||||
description: The complete process from preparing a document to collecting signatures and sealing the final PDF.
|
||||
---
|
||||
|
||||
import { Callout } from 'fumadocs-ui/components/callout';
|
||||
import { Step, Steps } from 'fumadocs-ui/components/steps';
|
||||
import { Tab, Tabs } from 'fumadocs-ui/components/tabs';
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
A typical signing workflow follows these steps:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Prepare Document] --> B[Send Document] --> C[Notify Recipients] --> D[Recipients Sign] --> E[Seal & Finalize] --> F[Document Completed]
|
||||
```
|
||||
|
||||
1. **Prepare** - Upload the document, add recipients, and place fields
|
||||
2. **Send** - Distribute the document to recipients
|
||||
3. **Notify** - Recipients receive signing requests
|
||||
4. **Sign** - Recipients complete their assigned fields
|
||||
5. **Complete** - Document is sealed and distributed to all parties
|
||||
|
||||
{/* prettier-ignore */}
|
||||
<Steps>
|
||||
<Step>
|
||||
### Prepare the document
|
||||
|
||||
Document preparation involves three main tasks: uploading, adding recipients, and placing fields.
|
||||
|
||||
**Upload the document**
|
||||
|
||||
Start by uploading a PDF. You can upload directly:
|
||||
|
||||
- from your device
|
||||
- create from an existing template
|
||||
- or duplicate a previously sent document.
|
||||
|
||||
Once uploaded, the document enters the **Draft** state.
|
||||
|
||||
**Add recipients**
|
||||
|
||||
Add the people who need to interact with the document. Each recipient needs:
|
||||
|
||||
- an email address
|
||||
- a name
|
||||
- a role
|
||||
|
||||
Available roles are:
|
||||
|
||||
| Role | Purpose |
|
||||
| --------- | --------------------------------------------------- |
|
||||
| Signer | Must sign the document |
|
||||
| Approver | Must approve (signature optional) |
|
||||
| Viewer | Must confirm they viewed the document |
|
||||
| Assistant | Pre-fills fields for other recipients |
|
||||
| CC | Receives a copy after completion (no action needed) |
|
||||
|
||||
**Place fields**
|
||||
|
||||
Add fields that recipients will complete. At minimum, each signer needs one signature field. You can also add:
|
||||
|
||||
- name
|
||||
- email
|
||||
- date
|
||||
- text
|
||||
- number
|
||||
- dropdown
|
||||
- checkbox
|
||||
- radio
|
||||
- initials fields
|
||||
|
||||
Each field is assigned to a specific recipient, indicated by color coding in the editor.
|
||||
|
||||
<Callout type="info">
|
||||
The document cannot be sent until every signer has at least one signature field assigned to them.
|
||||
</Callout>
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Send the document
|
||||
|
||||
When the document is ready, you send it to recipients. You have two distribution options:
|
||||
|
||||
<Tabs items={['Email distribution', 'Manual distribution']}>
|
||||
<Tab value="Email distribution">
|
||||
|
||||
Recipients receive an email notification with a link to sign.
|
||||
|
||||
You can customize the email:
|
||||
|
||||
- subject line
|
||||
- message body with personalized variables
|
||||
- reply-to address for recipient responses
|
||||
|
||||
</Tab>
|
||||
<Tab value="Manual distribution">
|
||||
|
||||
Generate signing links without sending emails.
|
||||
|
||||
Use this when you want to:
|
||||
|
||||
- send links via SMS or messaging apps
|
||||
- embed links in your own application
|
||||
- control notification timing yourself
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
After sending, the document moves from **Draft** to **Pending** status.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Recipients are notified
|
||||
|
||||
When you send a document via email, each recipient receives a notification containing:
|
||||
|
||||
- the document title
|
||||
- your name and email (or team name)
|
||||
- your custom message (or a role-specific default)
|
||||
- a unique signing link
|
||||
|
||||
The signing link is specific to each recipient and cannot be used by others. Links remain active until the document is completed, deleted, or expired.
|
||||
|
||||
**Signing order**
|
||||
|
||||
By default, all recipients are notified simultaneously (parallel signing). If you enable sequential signing, only recipients in the first signing position receive notifications initially. When they complete their actions, the next group is notified.
|
||||
|
||||
This continues until all recipients have been notified and completed their actions.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Recipients sign
|
||||
|
||||
When a recipient clicks their signing link, they see the document with their assigned fields highlighted. The signing experience depends on their role:
|
||||
|
||||
<Tabs items={['Signer', 'Approver', 'Viewer']}>
|
||||
<Tab value="Signer">
|
||||
|
||||
Signers must complete all required fields before they can finish. For signature fields, they can:
|
||||
|
||||
- draw a signature using mouse or touchscreen
|
||||
- type their name and select a font style
|
||||
- upload an image of their existing signature
|
||||
|
||||
After completing all fields, the signer clicks a button to submit. They receive a confirmation and can download a copy of the document showing their completed fields.
|
||||
|
||||
</Tab>
|
||||
<Tab value="Approver">
|
||||
|
||||
Approvers review the document and must explicitly approve it. If signature fields are assigned, they can optionally sign.
|
||||
|
||||
The document cannot proceed until all approvers have given approval.
|
||||
|
||||
</Tab>
|
||||
<Tab value="Viewer">
|
||||
|
||||
Viewers see the full document and must confirm they have viewed it. They cannot add signatures or modify any content.
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
**Authentication**
|
||||
|
||||
You can require recipients to verify their identity before signing through:
|
||||
|
||||
- email verification (confirm access to the email address)
|
||||
- access code (enter a code you provide separately)
|
||||
- passkey (authenticate with a hardware or software passkey)
|
||||
|
||||
</Step>
|
||||
|
||||
<Step>
|
||||
### Document is completed
|
||||
|
||||
Once all recipients with required actions have completed them, the document is finalized.
|
||||
|
||||
| Aspect | Description |
|
||||
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Sealing** | The completed document is sealed with a digital certificate that cryptographically signs the PDF, prevents modification without detection, and provides proof of authenticity. |
|
||||
| **Audit trail** | An audit log is generated and can be attached to the document. It records when the document was created and sent, when each recipient viewed and signed, IP addresses and timestamps for each action, and any authentication methods used. |
|
||||
| **Distribution** | All parties receive the completed document: signers, approvers, and viewers receive their copy via email; CC recipients receive their first notification with the completed document; the document owner can download the signed PDF from their dashboard. |
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Workflow Variations
|
||||
|
||||
Documenso supports several workflow variations to handle different signing scenarios.
|
||||
|
||||
<Tabs items={['Sequential signing', 'Approval workflows', 'Assistants for pre-filling', 'Direct links']}>
|
||||
<Tab value="Sequential signing">
|
||||
|
||||
When recipients must sign in a specific order, enable signing order:
|
||||
|
||||
1. Assign each recipient a signing position (1, 2, 3, etc.)
|
||||
2. Recipients at position 1 sign first
|
||||
3. Recipients at position 2 are notified only after position 1 completes
|
||||
4. Multiple recipients can share the same position to sign in parallel within that step
|
||||
|
||||
Use sequential signing when later signers:
|
||||
|
||||
- need to see what earlier signers entered
|
||||
- approval must happen before final signatures
|
||||
- company policy requires a specific signing order
|
||||
|
||||
</Tab>
|
||||
<Tab value="Approval workflows">
|
||||
|
||||
Combine approver and signer roles to create approval workflows:
|
||||
|
||||
1. Add approvers at signing position 1
|
||||
2. Add signers at signing position 2
|
||||
3. Approvers review and approve first
|
||||
4. Signers are notified only after approval is complete
|
||||
|
||||
<Callout type="warn">
|
||||
If an approver rejects the document (when rejection is enabled), the workflow stops and signers
|
||||
are never notified.
|
||||
</Callout>
|
||||
|
||||
</Tab>
|
||||
<Tab value="Assistants for pre-filling">
|
||||
|
||||
Use assistants to have one person prepare the document for another:
|
||||
|
||||
1. Add an assistant at signing position 1
|
||||
2. Add the final signer at signing position 2
|
||||
3. The assistant pre-fills fields with suggested values
|
||||
4. The signer reviews and completes their signature
|
||||
|
||||
This is useful when administrative staff prepare documents for executives or when gathering information from one person while another signs.
|
||||
|
||||
<Callout type="info">
|
||||
The Assistant role is only available when sequential signing is enabled.
|
||||
</Callout>
|
||||
|
||||
</Tab>
|
||||
<Tab value="Direct links">
|
||||
|
||||
For high-volume signing scenarios, you can create direct links that allow anyone to sign without receiving an individual invitation:
|
||||
|
||||
- Generate a public signing link for a document or template
|
||||
- Share the link on your website, in emails, or through other channels
|
||||
- Each person who accesses the link creates their own signing instance
|
||||
- Useful for waivers, consent forms, and public agreements
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [Document Lifecycle](/docs/concepts/document-lifecycle) - Understanding document states from draft to completion
|
||||
- [Recipient Roles](/docs/concepts/recipient-roles) - Detailed explanation of each role type
|
||||
- [Field Types](/docs/concepts/field-types) - All available field types and their configuration options
|
||||
- [Signing Certificates](/docs/concepts/signing-certificates) - How documents are digitally sealed
|
||||
Reference in New Issue
Block a user