Signatures
This page is generated from the in-app guide content — edit
featureToggleGuidesand runpnpm gen:feature-toggle-docs.
Automatic reminders
Automatically remind pending signers before a request expires.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.auto_reminder_enabled | On | /settings/others-configuration | — |
How it works
A scheduled job looks for requests still waiting on signers that expire in about 3 days or about 1 day, and reminds those signers.
When ON
Pending internal signers get an in-app notification; external signers of internal e-sign requests get an email with their link.
When OFF
No automatic reminders are sent for this company.
Screens, documents and reports affected
Signatures; notifications and email to signers.
Caveats
On by default. Manual “Remind” on a request still works when off. Requests without an expiry date are never auto-reminded. Expiring overdue requests happens regardless of this switch.
Confirmation E-Sign Policy
Control whether e-sign appears on order detail pages and whether a completed signature is required before confirm/send.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.confirmation_policies | — | /signatures/settings | — |
How it works
Per document type (sales order, purchase order, service order) choose Hidden, Optional or Required for the e-signature section on its detail page.
When ON
Required: the e-signature must be completed before Confirm (sales order, service order) or Send (purchase order) is allowed.
When OFF
Hidden removes the e-signature section from the page; Optional (default) shows it without blocking anything.
Screens, documents and reports affected
Sales orders, Purchase orders, Service Management service orders → detail page and Confirm/Send.
Caveats
Orders created while the policy is Required always start as drafts (also when created from a quotation or another order), so they reach Confirmed only through the signed Confirm step; direct Approve checks the signature too. Purchase orders: only Send is gated — an approved PO can still be received.
Decline requires reason
Require a reason when a signer declines a request.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.decline_requires_reason | Off | /settings/others-configuration | — |
How it works
Checked when a signer declines — from the signing link (external signers) or from the in-app inbox.
When ON
Declining without a reason is rejected; the signer must type one.
When OFF
A signer can decline without giving a reason.
Screens, documents and reports affected
Signing portal, Signatures inbox → Decline.
Caveats
Applies to the internal e-sign provider only; declines at an external provider follow that provider’s rules.
Enforce expiry
Block sending a signature request once it is past its expiry date.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.expiry_enforcement | On | /settings/others-configuration | — |
How it works
Checked when a draft signature request is sent.
When ON
A draft whose expiry date has already passed cannot be sent; the sender is told to change the expiry date first.
When OFF
The draft is sent anyway.
Screens, documents and reports affected
Signatures → Send request.
Caveats
On by default. Expiry itself does not depend on this switch: signing links always stop working at the expiry date and a daily job marks overdue sent requests as expired — so with the switch off, a past-due draft goes out with links that are already dead.
Internal e-signature
Let staff sign documents inside XBuddy instead of using an external provider.
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.internal_esign_enabled | On | /settings/others-configuration | — |
How it works
Checked when a signature request using the internal (XBuddy) provider is sent.
When ON
Requests with the internal provider can be sent and signed inside XBuddy.
When OFF
Sending a request with the internal provider is rejected; only external providers can be used.
Screens, documents and reports affected
Signatures → Send request.
Caveats
On by default. Only sending is blocked: drafts can still be created, and requests already sent before switching off can still be signed, resent and reminded.
Signer access control
Restrict request visibility to the creator and assigned signers (combine with Data Scope).
| Code | Default | Switch at | Turn on first |
|---|---|---|---|
signatures.signer_access_control | Off | /settings/others-configuration | — |
How it works
Added to the visibility check of every signature request read (list, detail, audit trail, evidence, certificate) and write (send, resend, remind, cancel, edit).
When ON
Besides Data Scope, a user sees and acts on a request only if they created it or are one of its signers.
When OFF
Visibility follows Data Scope only (signers still always see requests assigned to them).
Screens, documents and reports affected
Signatures → list, detail, audit trail, certificate; write actions.
Caveats
Super-admins and users with signatures:manage are not restricted. Tightens Data Scope — it never widens it.