QC Digital Signature Glossary and Current Terminology

Plain-language definitions for Template, Request, workspace, sender, signer, Contact, Signed Date, Identity Verification, Authorized Domain, Base/Effective tier, Completed PDF, Completed Package, Audit Trail, and other current terms; exclude obsolete UI terminology.

This guide applies to All plans; reference and follows the accepted QC Digital Signature 2.0.7 implementation. Where older walkthrough language differs from the current interface or source behavior, use the current QCDS state as the authority.

Before You Begin

Work on the current QCDS 2.0.7 installation and confirm you have the Joomla permissions required for the action.
Read the current QCDS Status page before changing licensing, tasks, or other global settings so you preserve the original diagnostic state.
Use HTTPS and verify Joomla mail independently when the workflow depends on signer or completion email.

Step-by-Step Workflow

Open the QCDS screen or record that owns the topic so you are reading the current state rather than an old screenshot or memory.
Compare the visible state with the current 2.0.7 rules described in this guide.
Identify whether the value belongs to global installation settings, one sender workspace, a reusable Template, or one immutable/sent Request.
Make changes only at the layer that owns the behavior.
Verify the result with a safe test and preserve historical Requests/evidence.

Current QCDS Terminology

Workspace: The private QCDS frontend area automatically provisioned for an eligible Joomla user.
Sender: The signed-in QCDS workspace user creating and managing Requests.
Contact: Reusable signer identity/contact information stored inside one sender workspace.
Template: A reusable protected PDF and its field layout. Publishing a new Template version affects future Requests, not already-sent transactions.
Request: One specific signature transaction created from a published Template and frozen when Send Now succeeds.
Signer: A participant who uses a personal secure link to complete assigned fields; a Joomla login is not normally required.
Routing: Whether signers can act in parallel (Everyone at once) or activate one after another (Sign in order).
Signed Date: A read-only date linked to a specific Signature or Initials field and populated when that field is completed.
Identity Verification: Optional provider-backed Level 2 identity assurance available on eligible paid plans; current providers are Didit and Shufti.
Authorized Domain: A domain recorded in the QuantaCade account and used by current keyless paid entitlement.
Base tier: The underlying product entitlement such as Basic, Pro, or Max before temporary/elevating sources are applied.
Effective tier: The feature level QCDS may use now after considering the base tier, All Access, or an active Max Preview.
Completed PDF: The finalized signed source pages, attachment presentation pages when applicable, and the appended Audit Trail.
Completed Package: A protected ZIP containing the current Completed PDF plus original signer attachment files when Document Attachment fields were used.
Audit Trail: The appended transaction record describing participants, delivery/view/signing events, hashes, attachments, Identity Verification evidence, and integrity context.

Avoid older wording that implies current key entry, automatic preview consumption, persistent draft Requests, or customer-facing Team/Assets/Variables navigation. Those descriptions do not match the accepted 2.0.7 workflow.

Plain-language definitions for Template, Request, workspace, sender,

Current QCDS paid entitlement is keyless: the installation resolves paid access from the domain authorized in the QuantaCade account rather than asking the customer to paste a current license key into Joomla. Basic remains usable without a paid domain claim; Pro/Max/All Access resolution, domain limits, and any paid-claim/grace behavior are determined by the current QuantaCade entitlement service. Treat a saved old key only as legacy compatibility state, not as the normal activation path for QCDS 2.0.7.

For QC Digital Signature Glossary and Current Terminology, verify this behavior using the actual object involved rather than a generic assumption. A global administrator setting, a sender-workspace preference, a reusable Template, and a sent Request have different ownership and history rules. QCDS is intentionally designed so changes for future work do not silently rewrite the evidence of an already-sent transaction.

Exclude obsolete UI terminology

How This Fits into the QCDS Workflow

These settings form the installation foundation. Entitlement, Joomla access, mail, language defaults, and automation health can change which controls are available without changing the historical integrity of Requests already sent.

Keep administrator changes narrow and reversible where possible. QCDS is designed to preserve saved higher-tier settings and historical data even when access changes, so loss of current feature access is not a reason to delete configuration.

Verify the Result

The Template validates and a new test Request renders the expected field/content behavior without changing older Requests.
Request Details shows the expected lifecycle, participant, Timeline, and delivery state after the action.
Provider Test Connection succeeds and a representative Level 2 test follows the expected provider flow.
The Completed PDF/Package opens, preserves the signed source and evidence, and the Audit Trail remains readable.
Status shows the expected Base and Effective tier and no unresolved entitlement-task integrity warning.

Common Mistakes to Avoid

Following old instructions that require entering a current license key instead of using Authorized Domains.
Starting the one-time Max Preview merely to inspect a feature before you are ready to evaluate it.
Publishing before running Validate and resolving actual configuration problems.
Assuming a later Template edit will update a Request that was already sent.
Cancelling/recreating an otherwise valid Request just to repair one failed email address.

Troubleshooting

If the PDF preview or completed artifact fails, reproduce with a small known-good PDF and check QCDS Status/Scheduled Task health before changing field data.
If Level 2 verification fails, use the provider Test Connection and inspect provider/profile/callback configuration; ordinary Level 1 signing and historical evidence should not be reset.
If the Request is partly successful, preserve it and repair the failed participant/delivery step. Successful links and recorded history should remain usable.

Operational Best Practice

Test meaningful changes with controlled data before relying on them in production. Keep QCDS, Joomla mail, Scheduled Tasks, and entitlement health observable; preserve successful Requests and completed evidence; and make the smallest change that solves the actual problem. For handoff or support, record the QCDS version, relevant Request/Template reference, the exact action taken, and the visible result without including secrets.

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.