Make Request-Specific Field Adjustments Without Changing the Template

Use the Request builder when one transaction needs field changes that should not become part of the reusable Template. QCDS keeps those edits in the current browser session and freezes them only into the new Request when Send Now succeeds.

Start from the Published Template

  1. Open Templates and choose Use Template for the published Template you want.
  2. Complete Request Details, then open Prepare & Send.
  3. Make the field changes needed only for this transaction.
  4. Run Check and resolve the field issues it reports.
  5. Use Send Now when the transaction-specific version is final.

What You Can Change for This Request

The streamlined Request builder uses the same PDF stage and field tools needed to prepare the transaction. You can add, remove, move, resize, or reassign fields; change field properties; adjust routing and signer order; and supply values for Request Text fields.

Request Text is intentionally transaction-specific. A reusable Template can carry the Request Text field placement without a final value. In the Request builder, enter the text that should be printed for this specific transaction before sending.

The Reusable Template Is Not Edited

These changes do not publish a new Template version and do not alter the Template that future senders will use. The Request starts from the selected published Template snapshot, but your Prepare & Send edits live in the transaction-specific builder state.

If the change should become the new standard for future Requests, edit the Template itself, validate it, and publish a successor Template version instead.

Unsent Changes Are Browser-Only

The current streamlined workflow has no ordinary persistent Request-draft library. While you are preparing this Request, the builder reports that changes are kept in this browser until sent. Leaving or reloading the page can therefore discard unsent transaction-specific work.

What Send Now Freezes

Send Now creates a short-lived compatibility draft on the server, applies the current Request builder snapshot and Request Details to it, runs the server send validation, and then creates the immutable Request. The resulting Request preserves the exact documents, fields, participant assignments, routing, timing, and message source used for that transaction.

After the immutable Request exists, QCDS retires the compatibility draft. Later Template edits do not rewrite the sent Request, and the Request-specific changes do not flow backward into the reusable Template.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.