How QCDS Request Expiration and Deadlines Work

Every sent QCDS Request can carry its own expiration deadline. The workspace default seeds that date during preparation, but the final Request stores its own exact deadline and time zone so later workspace-setting changes do not silently move an already-sent transaction.

How the Default Deadline Is Created

The workspace Default expiration setting supplies the starting number of days for a new Request. In the current streamlined builder, QCDS calculates the initial expiration in the workspace time zone and seeds it for 11:59 PM on the calculated day.

Before sending, the sender can review the Expires date/time on the Request. Send Now resolves that local value to UTC and freezes the transaction timing with the Request.

The Deadline Belongs to the Request

After Send Now creates the immutable Request, its deadline is no longer just a workspace preference. QCDS stores the resolved deadline on the Request and uses it for signing access, reminders, scheduled expiration, and final server-side submission checks.

Changing the workspace Default expiration afterward affects later Request preparation, not the already-sent Request.

Signer Links Follow the Request Deadline

For a Request with a deadline, newly issued personal signer links expire at that Request deadline. If a Request has no deadline, QCDS uses a bounded default link lifetime instead.

A signer who opens the page before expiration still must get the final submission to the server on time. QCDS checks the server-received submission time against the Request deadline and rejects a final submission that arrives after the deadline.

How Automatic Expiration Happens

When a deadline is frozen, QCDS schedules an expire_request action for that exact UTC deadline. The Request Timing and Deadlines Joomla Scheduled Task processes due actions. Because Joomla tasks run on their configured cadence, processing occurs when the scheduler next runs after the action becomes due rather than through a permanently running background process.

When the due expiration action is processed, an eligible active Request becomes Expired, which is a terminal state. QCDS does not expire a Request that is already terminal.

Deadlines and Reminders Are Related but Separate

Automatic unsigned reminders stop selecting participants once the Request deadline has passed. Deadline-warning and expiration actions are separate scheduled records, and the Request's frozen reminder interval remains independent from its exact expiration time.

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.