Troubleshoot Send Now, Request Limits, and Email Delivery

A Send Now problem can occur either before QCDS creates the immutable Request or after the Request has been frozen and invitation delivery begins. That distinction determines whether you should correct the prepared send and try again or open the existing Request and repair delivery.

If Send Now Stops Before a Request Is Created

QCDS first revalidates the prepared transaction on the server. Required Request/message values, documents, participant assignments, routing, deadlines, field definitions, Signed Date links, creator text, and required Identity Verification availability must all be valid.

QCDS then enforces the applicable signing-request allowance and obtains central Request authorization. If authorization cannot be verified, the monthly allowance is exhausted, required premium/Identity Verification authorization is unavailable, or a local Max/All Access group allowance rejects the send, QCDS stops before publishing the immutable Request. Correct the reported problem and submit the same prepared transaction again.

Understand the Current Monthly Allowances

The normal plan-level allowance is 5 Requests/month on Basic and 25 Requests/month on Pro, measured on the central service's UTC month. Max and All Access do not have a plan-level numeric Request cap.

Max/All Access can optionally enable local Joomla-group monthly Request limits. When that optional policy is enabled, group resolution can produce a numeric allowance, Unlimited, or zero. A local group-limit rejection occurs before central Request authorization consumes the send.

If Premium Authorization Unexpectedly Behaves Like Basic

Open QCDS → Status and check Entitlement Automation Integrity. Premium proof is permitted only when the local entitlement state is valid and the required Entitlement Revalidation automation is structurally healthy. A missing, disabled, duplicated, unpublished, or slower-than-hourly entitlement task forces the effective send proof back to Basic until the task is repaired.

If the Request Exists but Invitations Failed

Once central authorization succeeds, QCDS freezes the immutable Request, records its authorization receipt, activates routing, and queues invitations. Email delivery then occurs as a separate step. A mail failure at this point does not mean the Request should be recreated.

Open Requests and the Request's Delivery section. You may see Sent with errors, Undeliverable, Retry, or Failed rows. Successful invitation links remain usable even when another address fails.

Repair the Delivery Layer

  • Use Correct & Send when an eligible Contact address is wrong.
  • Use Retry when the address is correct and the failure was temporary.
  • Use Stop Trying when no further attempts should be made to that address.

Common plain-language errors identify a rejected mailbox/domain, Joomla mail authentication failure, mail-server connection/timeout, or an internal QCDS data/update problem. Fix the indicated layer and retry the existing delivery rather than sending a second Request to the same signer.

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.