QCDS Field Types: Complete Current 20-Field Reference

Reference the active builder palette categories and all current types: Signature, Initials, Signed Date; Signer Information; Signer Input; Document Elements; and Request-Specific Request Text. Explicitly exclude legacy-only registry types from normal new-placement guidance.

This guide applies to All plans; sender 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

Open the current Template draft in the visual builder and confirm the PDF page you are editing is visible before placing or moving fields.
Decide which fields are signer-interactive, which are fixed creator content, and which values should be entered at Request time.
Keep assignment and required-state decisions intentional; the builder can publish reusable unassigned fields, but Send Now requires all interactive fields to resolve correctly.

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 20-Field Builder Palette

Signing

Signature: Collects the signer’s electronic signature. The signer can type or draw it; QCDS fits the result inside the placed field.
Initials: Collects initials using the signing experience. Use it where a page or clause specifically requires initials.
Signed Date: Read-only date linked to one Signature or Initials field. It fills when that exact signing field is completed.

Signer Information

Signer Name: Prefills the saved full name and can be corrected by the signer; a successful correction can update the Contact.
Signer First Name: Prefills the saved first name and can save a corrected value back to the Contact after signing.
Signer Last Name: Prefills the saved last name and can save a corrected value back to the Contact after signing.
Signer Email: Prefills the delivery/identity email and remains read-only for the signer.
Signer Phone: Prefills the saved phone and can be corrected while signing.
Signer Address: Prefills the saved consolidated address on one line and can be corrected while signing.
Signer Company: Prefills the saved company or organization and can be corrected while signing.
Signer Title / Position: Prefills the saved title or position and can be corrected while signing.

Signer Input

Single-Line Text: Collects a short one-line answer and is constrained by the physical field area.
Multi-Line Text: Collects longer text with line breaks and wrapping.
Selectable Date: Lets the signer type or choose a date with the date picker.
Checkbox: Collects a yes/no checked state and can be Required.
Dropdown: Lets the signer choose one creator-defined option; enter one option per line and provide at least two.
Document Attachment: Lets the signer upload one PNG or JPEG image. The original is protected and the completed document can show or privacy-obscure its presentation.

Document Elements

Document Text: Adds fixed creator-authored text that the signer cannot edit.
Document Image: Adds a fixed creator image such as a logo or graphic; QCDS preserves the image proportions.

Request-Specific

Request Text: Places a reusable field whose fixed value is entered by the sender for each individual Request.

The current streamlined palette contains 20 new-placement choices. Legacy registry keys such as the old generic Text, Multiline, and Date forms can remain understood for backward compatibility, but they are not the recommended palette for new Template design.

Reference the active builder palette categories and all current types:

The current visual builder uses the rendered PDF as the coordinate authority. You can move between pages, click or drag fields from the palette, select/move/resize them, use Undo/Redo, Copy/Paste, Delete, Fit Width, zoom controls, bulk assignment, and right-click Field options. Do not save placement against a blank/failed PDF preview: resolve protected-delivery/rendering errors first so coordinates are based on the actual page.

For QCDS Field Types: Complete Current 20-Field Reference, 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.

Signer Information

Signer Input

Document Elements

And Request-Specific Request Text. Explicitly exclude legacy-only registry

How This Fits into the QCDS Workflow

Field choice determines both the signer experience and the evidence rendered into the final artifact. Use the current streamlined palette for new Templates; legacy registry types may remain readable for compatibility but are not the design target for new work.

Field properties should communicate a clear signer task. Required fields should be discoverable, signer-information fields should reflect the participant snapshot, and fixed creator content should not masquerade as editable signer input.

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.
A direct follow-up test confirms the change affects future/current workflow behavior without rewriting historical sent Request evidence.

Common Mistakes to Avoid

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.
Leaving transient unsent work and expecting it to appear later as a persistent draft Request.

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 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.