Skip to main content

​
Prepare templates for e-signing

Odella lets your AI Employees prepare documents for signature from templates. Your worker fills in the business information; each assigned person provides their own signature and any answers reserved for them. You review the prepared request before invitations are sent.

​
Configure a PDF template

Start with an approved PDF template and open its editor.
1

Add or select a field in Variables

Review the field’s name, description, type, and placement on the PDF. A blank signature field is not automatically an e-signing field: select Use for e-signing to enable it.
2

Choose the field's purpose and owner

For compatible fields, use Field purpose to choose a signing value such as initials, signer name, or date signed. For ordinary answers, use Filled in by to choose Your AI employee or The assigned person.
3

Assign the signing party

Choose the Signer or Assigned party for each signing field. Use clear roles, such as Customer or Company representative. Every signing field must have a party before publishing.
4

Choose where signed copies go

In E-signing, select a signing store under Where signed copies go, or select Create a signing store if you have permission. Review who can access the store before publishing.
5

Select a signing policy

Choose the available Signing policy appropriate for your process. Review the displayed signature meaning and record class. A policy is required before publishing.
6

Test and publish

Check field placement, required answers, party assignments, the destination store, and policy. You can save an incomplete draft, but resolve missing settings before publishing.
You cannot change the signing store after publishing. Signed copies and their audit trails cannot be edited or deleted. Check the destination and its access settings carefully.

​
Understand signing fields

Only purposes compatible with the selected field type are offered. Keep ordinary business values assigned to the AI Employee and reserve signing fields for the appropriate person.
A DOCX placeholder named “signature” is still an ordinary placeholder, not a signing field. The positional field setup above applies to PDF templates. DOCX-based signing requires a populated document converted to a final PDF and a checked signing layout; do not treat Word placeholders or preview positions as signature placements.

​
Ask an AI Employee to prepare a request

Assign the published template to the worker, then provide:
  • The template to use and the source information for business fields.
  • The name and email of the person filling each signing-party role.
  • Any delivery instructions or people who should receive a copy.
  • A clear requirement to review the request before sending.
For example:
Prepare the customer agreement using the approved template and attached terms. Assign the Customer role to Alex Chen at alex@example.com. Show me the final document and recipients for review before sending invitations.
The worker prepares the signing draft. Populating or downloading a template alone does not send a signing invitation.

​
Review and approve invitations

Open the signing review presented with the worker’s approval request. Check:
  • The final document, including names, amounts, dates, and page layout.
  • Each recipient’s name, email address, and assigned role.
  • Which fields each person must complete.
  • The signing policy and destination for completed records.
Sending requires a one-time human approval for the reviewed request. If the document, recipients, or fields change, review the updated draft rather than relying on the earlier approval.
Your AI Employee can prepare and send an approved request, but cannot provide a person’s signature on their behalf.

​
What recipients do

Each recipient receives their own invitation link. They sign in before signing, review the document and signing policy, and complete the fields assigned to them. Their signature and automatically recorded values are applied when they finish signing. Treat invitation links as private. If a recipient cannot proceed, check that they are using the intended invitation and account rather than forwarding another person’s link.

​
Track requests and completed copies

Open Documents → Signing requests to review prepared requests, outstanding signatures, and completed records. Request details show recipients and their progress, including whether they have opened, signed, or declined. Once everyone has signed, the signed copy and its audit trail are filed in the template’s signing store. Access to those records follows the store’s permissions. Changes to a template’s signing policy do not change invitations already sent: those requests keep the policy they were sent with.

​
Saved signatures and recipient recovery

Recipients can manage their personal saved signature under Account → Profile. A saved signature does not sign automatically or authorize a worker to sign for them. Removing it does not alter completed documents.

​
Protected records and archiving

Completed records belong in a dedicated signing store, not an ordinary editable knowledge store. They include the signed PDF, completion certificate, audit trail, and evidence. Archiving the store stops new requests from using it but does not prevent already-sent requests from completing. Records remain available to authorized users. Restoring the store allows new requests again. Changing access affects past records too; archiving is not deletion or automatic disposal. See Signing-record stores for restrictions and access guidance.

​
Send-time billing and uncertain results

Sending requires active billing, sufficient credit, and compliance with spend limits after human approval and validation. The signing-send charge is per envelope, not per signer. Completing or archiving the request does not create another signing-send charge. A timeout can occur after payment but before sending is confirmed. Check the current state and retry the same request where appropriate; do not create replacement drafts blindly or assume a refund. See Billing and credits.

​
Resolve setup problems

  • No signing settings appear: Add a signing field from Variables. A normal answer or blank signature widget alone does not configure e-signing.
  • A signing field has no person assigned: Select its signing party before publishing, then identify the actual recipient when preparing the request.
  • No signing store is available: Create one if permitted, or ask an administrator to share an appropriate signing store. You can still save the draft.
  • The selected store is unavailable: Choose an available destination before publishing. For an already published template, ask your administrator to review the destination’s status and access.
  • The request needs review again: Reopen the current draft and check its latest document, recipients, and fields before approving.
Apply your organization’s legal, compliance, and recordkeeping requirements when choosing templates and signing policies. E-signing does not establish whether the document itself is appropriate for your transaction.