Document Execution

The Document Execution module manages formal actions that a person or organization must complete against approved content. It is used for signatures, initials, stamps, acknowledgements, and attestations.

Document execution is separate from editing, approval, and PDF generation. DMS or Forms own the source content. Review-Approval owns approval decisions. Renditions generate controlled output. Document Execution owns the execution package, participant tasks, completion proof, and execution evidence.

When you would use it

Use document execution when you need to:

send an approved NDA, contract, policy, procedure, form response, or controlled PDF for signature
ask a person to acknowledge or attest to a policy, procedure, or statement
collect initials or a company stamp where the document policy requires it
coordinate several participants in parallel or in a defined order
keep execution proof that can later be shown in audit, DMS, or governance records
allow an external recipient to complete an execution task through public access without making them a workspace member

Execution packages and tasks

An execution package groups the formal execution work for one source context. The source can come from DMS, Forms, a controlled rendition, document governance, or another governed module.

Each package contains one or more execution tasks. A task describes what the participant must do, such as sign, initial, stamp, acknowledge, or attest. The task also keeps a snapshot of the participant context, role label, capture requirements, proof policy, and completion evidence.

Packages can be created directly, or by another workflow that needs formal execution as one of its steps.

Standalone and workflow-driven execution

Document execution supports two patterns.

Standalone dispatch is used when a user sends an approved document or controlled output directly to a recipient. For example, an administrator can send an approved NDA for signature or a policy for acknowledgement.

Workflow-driven dispatch is used when another process owns the reason for the execution. For example, an onboarding lifecycle can require an NDA signature before the next step, or a vendor engagement can require a right-to-audit acknowledgement. The workflow owns the process step, while Document Execution owns the execution proof.

Participant roles

Participant roles are configurable descriptors, not fixed product roles. This keeps execution usable for employees, contractors, vendors, witnesses, guardians, directors, external reviewers, and other party types without hardcoding those meanings.

Examples of role descriptors include:

counterparty signer
organization authorized signer
witness
policy acknowledger
external reviewer

The source module or workflow resolves those descriptors to the actual member, party, or public recipient when creating the package.

Placement strategies

Document execution supports two placement approaches.

Overlay or certificate placement is the default for policies, procedures, acknowledgements, attestations, and generic controlled outputs. The source document does not need manually placed signature fields. The final output can include a controlled signature section, acknowledgement table, execution certificate, or evidence summary.

Template anchor or placeholder placement is used when exact placement matters, such as contracts, NDAs, offer letters, multi-party agreements, or initials required on specific pages. Anchors describe where a participant must complete an action and which trusted values can be prefilled.

Prefill and recipient capture

Document execution distinguishes trusted prefill from recipient capture.

Prefill values are supplied by trusted source modules before sending, such as party name, organization name, document number, effective date, or policy version.

Capture values are completed by the participant, such as a signature, initials, acknowledgement checkbox, attestation confirmation, typed title, or permitted stamp.

This distinction helps users understand which values came from Novantra records and which values the participant completed during execution.

Public recipients

External recipients complete execution tasks through Public Access. They do not become workspace members, and they are not treated as internal resource-access subjects.

Public access is suitable for recipients such as contractors, suppliers, customers, partners, and other people who only need to complete the scoped task they received.

Evidence

Document execution evidence records the completion meaning. A signature, acknowledgement, stamp, initials, and attestation are not interchangeable. Each one produces evidence according to its own task type and proof policy.

Evidence can include the task outcome, participant snapshot, proof context, captured values, related artifact references, timestamps, and source context. It is meant for later review, audit, document history, and controlled output rendering.

Evidence export is policy-gated. When a package policy allows export, authorized users can export sanitized package, task, and evidence snapshots with a recorded reason. Exports do not expose raw signatures, stamp images, one-time passcodes, tokens, storage keys, or private artifact paths.

Catalog agreement templates

Reviewed catalog agreement templates can be adopted into Document Execution as local execution packages. Adoption creates the package and participant tasks from the reviewed template payload, stores catalog source context in encrypted snapshots, and records catalog lineage. Link-existing adoption decisions only record lineage against the selected package.

Renditions - generates controlled outputs and can render execution evidence snapshots.
Document Governance - governs policy and procedure posture around DMS documents.
Forms - can hand formal execution needs to Document Execution while keeping form template and response truth.
Public Access - hosts external participant sessions for scoped tasks.