QCDS Contacts: What They Store and Why They Matter

A QCDS Contact is reusable participant data stored inside the current workspace. Contacts make it faster to assign real people to signing Requests while keeping reusable address-book data separate from the immutable evidence of a Request that has already been sent.

What the Current Contact Screen Stores

The current QCDS Contact editor can maintain:

• First name and Last name.
• Preferred name.
• Company and Title.
• Preferred language.
• One or more Email address(es).
• Phone.
• A consolidated Address.
• Notes.

The underlying Contact record is workspace-scoped. In current Private / Organization Mode, eligible users in the primary organization workspace are working with that shared workspace Contact data rather than maintaining isolated personal address books.

Preferred Language Has Real Workflow Meaning

An explicit Contact Preferred language is used for that Contact's participant-facing emails and secure signer pages. If it is left on Use frontend default, QCDS keeps the Contact preference blank so later workspace frontend-language changes can continue to flow through.

This is different from copying the current workspace language permanently into every Contact.

Multiple Email Addresses

The compact Contact editor accepts multiple email addresses separated by commas or semicolons. QCDS validates each address, removes duplicate canonical addresses, and stores the first active address as the primary email for the Contact record.

A Contact can exist without an email address, but an email-based signing invitation needs a valid recipient address when that Contact is used as a signer.

Reusable Contact vs. Frozen Request Participant

The Contact is reusable data. A sent Request is historical transaction evidence. When a Request is sent, QCDS freezes participant information into the Request so a later Contact edit does not silently rewrite who received or completed an earlier transaction.

Where a signing field explicitly allows a signer-confirmed profile correction, QCDS can update the saved Contact after successful signing while still preserving the immutable participant snapshot for the Request that produced the correction.

Why Contacts Matter

• They reduce repeated typing when the same participant signs more than once.
• They provide a stable place for participant language and delivery details used when preparing future Requests.
• They let you correct reusable information for future work without changing older signed evidence.
• They keep participant data scoped to the QCDS workspace rather than mixing it into Joomla user accounts.

Deleting a Contact Does Not Delete Signed History

The Contacts screen explicitly preserves existing signed-Request history when a Contact is deleted. Treat Contact lifecycle changes as address-book maintenance; do not expect them to erase or rewrite completed Request 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.