What to Include in a QCDS Support Request

A focused support request is much faster to diagnose than a large data dump. Include enough information to identify the installation, affected Request, failing layer, and exact time of the problem—while leaving out passwords, provider secrets, raw signer links, and unnecessary private evidence.

Start with the Built-In Support Information

In Joomla Administrator, open QC Digital Signature → Support. The Support Information card provides the product, installed version, product code, domain, masked legacy-key state, license/status context, Effective tier, and Installation UUID. Include this information when it is relevant to the case.

Identify the Exact Operation That Failed

State what you were doing and where—for example:

  • publishing a Template or preparing PDF pages;
  • clicking Send Now;
  • opening a signer invitation;
  • starting/completing Identity Verification;
  • submitting the signer form;
  • generating/retrying a Completed PDF; or
  • delivering/resending an invitation or completed document.

Include the exact visible error text and the approximate timestamp/time zone. If the UI supplies a reference/error identifier, include it unchanged.

For a Request Problem, Include Request Identity

Provide the Request number and, when visible/appropriate, the Request public ID. State the current Request status and whether the problem affects one signer/address or the whole Request. For delivery problems, include the Delivery status/error text and the affected address only when support genuinely needs it.

Do not send the signer's raw invitation URL/token as a diagnostic identifier.

Include the Health Information for the Failing Layer

  • Entitlement: Status message, Base/Effective tier, Authorized Domain state, Entitlement Automation Integrity, and last task result.
  • Automation: Scheduled Task name, enabled/published state, Last execution, Last exit code, Next execution, and whether the Joomla scheduler runner is operating.
  • Storage/PDF: latest Storage Health or document-safety result, whether the file was rejected/held, and whether PDF page preparation completed.
  • Mail: Delivery error details plus whether ordinary Joomla mail works.
  • Identity Verification: provider (Didit/Shufti), Global or account scope, test/production mode, displayed verification state, and provider reference when safe to share.

Describe What Changed

Mention recent QCDS/Joomla/PHP updates, domain moves, mail-server changes, storage-path changes, user-group/plan changes, provider credential changes, or Template/document replacements when they happened close to the failure.

Do Not Put Secrets or Private Evidence in the Ticket Body

Do not paste passwords, API keys, Shufti Secret Keys, Didit webhook secrets/API keys, entitlement tokens, raw signer/session links, private identity images/video, or entire protected Completed Packages into a normal ticket. If support specifically needs a private artifact, use the secure method requested by support.

When possible, reproduce the issue with a small test PDF and test Contact. That gives support a clean reproduction without exposing production customer 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.