What you're actually building here
Patient Form Templates is where you design the forms your clinic sends to patients or fills in on their behalf — intake questionnaires, consent forms, outcome measures, screening checklists, anything structured enough to benefit from a fixed set of questions rather than a free-text note. You build each template with a drag-and-drop form builder: a template is made of one or more sections, and each section holds one or more fields.
This is the single richest builder in ClinyPal's settings, both because forms genuinely have a lot of moving parts (section descriptions, eight field types, default answers, answer options, archiving) and because the same builder engine is reused in two other places in the product. Understanding it well here pays off across the whole system.
- Building and reordering sections and fields with drag-and-drop
- Every field type available and what each is actually for
- Default answers for text fields, and answer options for choice fields
- Body chart fields — why the diagram itself isn't picked here
- The archive-vs-delete distinction, and why it depends on save status
- Previewing a form before you commit to it
- What validation blocks a save, and how errors are shown
- The other two places this exact builder shows up
- Practical form-design advice: length, field-type choice, and Required
Building sections
A form is organized into sections. Each section has its own title, an optional description, and a set of fields underneath it. Sections are also the natural unit for grouping related questions — for example, splitting an intake form into Contact Details, Medical History, and Consent rather than one long undifferentiated list of fields, so a patient filling it in can see their progress and isn't confronted with everything at once.
Add a section
Click <strong>Add section</strong> to create a new section. The page auto-scrolls to the new section and briefly highlights it so you can see where it landed.
Name the section
Type directly into the section's title field — this is inline editing, there's no separate rename dialog.
Add a description (optional)
Click <strong>+ Add description</strong> to reveal a description textarea under the title. Use it for instructions or context aimed at whoever fills the form in — for example, clarifying that a pain scale runs 0 to 10, or that a question refers to the last 30 days.
- Click <strong>— Remove description</strong> to clear the text and hide the textarea again.
Reorder sections
Each section has a drag handle (a dotted grip icon). Press and drag it up or down to change the section's position relative to the others. This works with a mouse on desktop and with touch-drag on a phone or tablet.
Adding fields to a section
Fields are the individual questions inside a section. Add as many as the section needs, in any order, and rearrange them at any time.
Add a field
Click <strong>Add field</strong> within a section to append a new question. The page auto-scrolls to the new field and briefly highlights it, the same behavior as adding a section.
Choose the field type
Use the type dropdown on the field row to pick what kind of answer you're collecting. See the field types table below for what each one is for.
Set the label
Type the question or label text into the field's text input — this is what the person filling in the form will actually read.
Mark it required, if applicable
Tick the <strong>Required</strong> checkbox if the field must be answered before the form can be submitted. This checkbox is hidden entirely for <strong>Check boxes</strong> and <strong>Body chart</strong> fields, since "required" doesn't map cleanly onto either — a checkbox list can legitimately have zero selections, and a body chart's content is determined at fill-time, not at the field-definition stage.
Reorder fields
Each field has its own drag handle, independent from the section's handle. Drag a field up or down to reorder it within its current section, or drag it across into a different section entirely — the builder doesn't restrict fields to the section they started in.
| Field type | Use for | Required checkbox shown? |
|---|---|---|
| Single line | Short text answers — a name, a medication, a one-line response | Yes |
| Paragraph | Longer free-text answers — history, a description of symptoms | Yes |
| Multiple choice | Selecting exactly one option from a list | Yes |
| Check boxes | Selecting zero or more options from a list | No — hidden |
| Date | Date values, such as date of birth or date of injury | Yes |
| Attachment | Uploading a file, such as a referral letter or scan | Yes |
| Body chart | Marking locations on a body diagram — the diagram itself is chosen when the form is filled in, not here | No — hidden |
| Signature | Capturing a signature, typically for consent | Yes |
Default answers for text fields
For Single line and Paragraph fields, click + Add default answer to reveal a textarea where you can set a pre-filled value. This is useful for fields that usually have the same answer for most patients — a standard consent statement, a clinic-specific instruction, or a typical response that only occasionally needs changing. Whoever fills in the form sees the default already in place and only edits it when their situation differs, rather than typing the common case from scratch every time.
Answer options for choice fields
For Multiple choice and Check boxes fields, click Add option to append an answer choice. Each option row has its own drag handle for reordering, a text input for the option's label, and an archive/delete action of its own — options follow the exact same archive-vs-delete rule described below as sections and fields do.
Order options thoughtfully: put the most common answer first for a long list, and keep related options grouped together rather than in a random order, since patients scan a short list top to bottom.
Body chart fields
Adding a Body chart field to a form doesn't ask you to pick a diagram here in the builder — you'll just see a placeholder note confirming the field exists. The actual choice of which body diagram to annotate (front view, back view, a specific joint, and so on) happens later, when someone fills the form in for a real patient, and the mark-up itself uses the full annotation tool palette, not anything in this builder.
Archiving vs. deleting — the distinction that trips people up
Every section, field, and option has a remove button, but that button doesn't always do the same thing — and the difference matters if you've ever wondered why an item you removed came back, or why another one didn't.
In practice this means: removing something you just added a moment ago in this editing session is safe to do casually, since it's gone for good either way and nothing was ever persisted. Removing something that's been part of the template for a while is also safe, but for a different reason — it's recoverable.
- Archived items are hidden from the live form by default, but not permanently gone — the data and configuration are still stored.
- A <strong>Show archived</strong> toggle in the builder's header reveals archived sections, fields, and options, letting you either restore one back into active use or permanently remove it from there.
- This same rule applies uniformly to sections, fields, and individual answer options — not just top-level items.
Previewing before you commit
Click Preview to open a read-only modal showing the form exactly as an end user — a patient or a staff member filling it in — would see and interact with it. This renders the live layout, not a mockup, so section descriptions, required-field markers, and choice options all appear as they really will.
What blocks a save
A small number of structural rules are enforced when you try to save a template, aimed at preventing a form that looks complete in the editor but is actually broken for whoever has to fill it in:
- Every section needs at least one <strong>active</strong> (non-archived) field — an empty section with everything archived can't be saved as-is.
- Every choice-type field (<strong>Multiple choice</strong> or <strong>Check boxes</strong>) needs at least one active option — a choice question with no choices can't be saved.
The same builder, two other places
Everything covered above — sections, field types, drag handles, archive-vs-delete, validation — is one shared builder engine, not something unique to Patient Form Templates. It shows up in two other contexts:
Because it's shared, everything you learn here about how sections, fields, and archiving behave carries over directly to Custom Patient Fields — you're not learning a second system.
Designing forms patients will actually finish
Having every field type available doesn't mean a good form uses all of them. The templates that work best in practice tend to follow a few consistent habits:
Keep it short enough to finish. A patient filling in an intake form on their phone in a waiting room will abandon a long, densely worded form, or rush through it and give unreliable answers. Every field you add should earn its place — if you wouldn't ask the question out loud during a consultation, think carefully about whether it belongs on the form. Splitting a long form into clearly named sections at least lets a patient see how much is left, which measurably reduces abandonment even when the total length doesn't change.
Multiple choice vs. Check boxes — pick based on whether more than one answer can be true. Use Multiple choice when exactly one answer applies (a yes/no/unsure question, a single severity rating). Use Check boxes when several answers can genuinely all be true at once (which of these symptoms apply to you, which of these medications are you currently taking). Using Multiple choice for a question that really has multiple valid answers forces patients to under-report; using Check boxes for a strictly one-of-many question invites accidental multi-selection.
Use Required sparingly. Marking too many fields Required turns a form into an obstacle course and increases the chance a patient gets stuck and abandons it entirely rather than submitting something with a gap. Reserve Required for fields you genuinely cannot proceed without — a signature on a consent section, a name, a date of birth — and leave optional the fields that are useful-but-not-essential. A form with three Required fields that are truly essential is more trustworthy, and more likely to get finished, than one with twenty Required fields where most are convenience rather than necessity.