What Happens After a Signer Completes in Sequential Routing

In Sign in order routing, one signer’s successful completion is the trigger that can close the current stage and activate the next signer. The completed signer remains complete even if the next invitation or final-PDF processing later needs a retry.

The Current Signer Completes First

In a sequential Request, each actionable signer is frozen into a separate routing stage connected to the next stage. Later signers remain pending until their predecessor stage is satisfied.

When the active signer successfully submits, QCDS records that participant as completed and evaluates the current stage’s completion rule.

QCDS Activates the Successor Stage

When the current sequential stage becomes complete, QCDS identifies the valid successor stage, activates it, and changes the next participant from pending to available. Delivery reconciliation then queues that newly available signer’s invitation.

The completed signer’s action is not dependent on the next email being delivered successfully. If invitation delivery fails, that delivery can be retried without asking the previous signer to sign again.

What Happens After the Final Required Signer

When the last required sequential stage completes, there is no successor signer to activate. QCDS recognizes that all required routing stages are terminal, moves the Request into its waiting/completion-processing state when appropriate, and attempts final completion generation.

If completed-PDF generation or completion delivery encounters a retryable problem, the final signer’s completion remains valid. Recovery uses the stored transaction evidence; it does not reopen final signer fields just to rebuild or redeliver the finished output.

Reopening a Completed Signer Link

A signer who already completed does not get a second editable signing session by reopening the original invitation. QCDS checks participant completion before later token lifecycle states and returns a truthful already-signed message, including the completion date/time when available.

That remains true while other signers are still working or while final completion processing is still underway. Participant completion and Request-wide finalization are related but separate states.

What the Sender Should Verify

• The completed participant is shown as completed.
• The previous routing stage is complete.
• The next sequential participant becomes available and receives/queues an invitation when another stage remains.
• After the final stage, the Request proceeds toward completed output rather than activating another signer.
• Any delivery or completion error is handled as retryable processing instead of by altering prior signing evidence.

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.