What Send Now Checks Before QCDS Sends Invitations

Send Now is the transaction boundary in QCDS. It performs browser preflight, server validation, local policy checks when enabled, and QuantaCade request authorization before the immutable Request is created and active signer invitations are queued.

1. Browser Preflight Runs First

Before submitting Send Now, the Request builder refuses to continue while field issues remain. It also requires a Request title, email subject, Plain Text source, and non-empty active invitation message. Check is run again against the current builder state.

2. The Server Rebuilds and Validates the Transaction

The server creates the transaction from the selected published Template plus the posted Request-specific snapshot. Its send validation checks the Request title, exact document versions, participants, at least one actionable participant, Identity Verification availability, active field types, creator-controlled text, concrete signer assignments, Signed Date links, duplicate assignment ownership, routing validity, deadline validity, and the frozen invitation subject/body.

This server validation is authoritative even when the browser Check was clean.

3. Local Max/All Access Group Limits Are Enforced When Enabled

If the optional Joomla user-group monthly Request limits are enabled for Max or All Access, QCDS locks the sender's Joomla user row and reserves the local monthly slot before creating the Request. An exhausted local group allowance stops the send before the immutable Request is created.

4. QuantaCade Authorizes the Request

QCDS synchronously asks the QuantaCade request-authorization service to authorize the stable Request identity. This is the server-authoritative Basic/Pro plan-volume check. Basic normally has 5 and Pro 25 new Requests per UTC month; Max and All Access have no plan-level numeric ceiling.

If any participant requires Identity Verification, the authorization must explicitly permit that feature. QCDS verifies the signed authorization receipt before accepting it. If central authorization cannot be confirmed, no immutable Request is created and no signer invitation is queued.

5. QCDS Freezes the Immutable Request

After validation and authorization succeed, QCDS creates the immutable Request and integrity manifest, stores the authorization receipt, binds any required Identity Verification participants, freezes protected document references, activates the root routing stage, and queues invitations for the participants who are active at that moment.

Actual email delivery happens after that transaction commits. A mail-delivery failure is therefore different from an allowance or authorization failure: the immutable Request may already exist and should usually be repaired through its delivery controls rather than recreated.

Why a Retry Should Not Consume the Same Request Twice

The send path uses idempotency plus a stable Request authorization identifier. If the immutable Request already exists for that send operation, QCDS reuses it and can retry delivery instead of creating a second transaction. Starting a genuinely new Request is different and receives its own authorization identity.

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.