Delete a QCDS Contact Without Damaging Existing Requests

Deleting a QCDS Contact removes it from normal future use without rewriting Requests that already captured that participant. QCDS uses a lifecycle delete rather than erasing the Contact row and explicitly preserves existing signed-Request history.

Delete the Contact

  1. Open the QCDS frontend workspace and choose Contacts.
  2. Locate the Contact you no longer want available for future work.
  3. Click the Delete action.
  4. Confirm the prompt: Delete this contact? Existing signed-request history will remain unchanged.

QCDS records the Contact lifecycle as deleted, stores the deletion time/reason, and removes it from the normal active Contacts list. New Request participant selection requires an active Contact, so the deleted Contact is no longer available as a normal reusable participant.

Why Existing Requests Survive

A sent Request does not depend on continually reading the current Contact row for its core transaction evidence. At Request creation/send time, QCDS freezes participant information into the Request snapshot, including the participant identity and ordered delivery addresses used by that transaction.

Deleting the reusable Contact therefore does not erase the Request snapshot, signer field values, timeline/history, completed PDF, or existing delivery records. The delete action itself is designed around that preservation boundary.

What Deletion Does Not Do

  • It does not cancel an active Request.
  • It does not retract an invitation already created for a sent Request.
  • It does not remove a completed PDF or audit evidence.
  • It does not rewrite participant information already frozen into historical Requests.

Before You Delete

If the Contact only has outdated reusable information, editing it may be more appropriate than deleting it. If the problem is a failed address on an already-sent Request, use the Request's Delivery correction controls instead. Delete the Contact when you actually want it removed from normal future Contact selection.

Verify the Result

  • The Contact no longer appears in the normal active Contacts list.
  • An older sent Request still opens with its participant and timeline intact.
  • A completed Request still exposes its completed document/evidence normally.
  • Delivery history for the older Request remains available.

Concurrent-Change Protection

QCDS checks the Contact's lock version when deleting it. If another change was saved after the page loaded, QCDS can reject the stale delete instead of silently overwriting the newer lifecycle state.

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.