Draft conditional forms from approved questions

Practice relevance

Cross-practice idea · A general operational method. Review the stated tool and jurisdiction limits before use.

The problem

Map the firm’s approved questions and branches to a reviewable form specification.

Why it matters: An unclear branch can hide a required question or treat an unknown answer as no. A specification based only on approved questions lets the firm check each path before putting a form in front of prospective clients.

Sources & evidence

Proposed / not tested. The public source describes the problem. Documentation supports only the stated method components; no result from this recipe has been verified.

What’s been verified

Source methods and reported problems have been reviewed. We have not run the adapted workflow. The sample below describes expected behavior on synthetic data, not a customer result.

What to measure: In a synthetic pilot, count correctly found exceptions, false alarms, and unresolved inputs. No time or cost saving is assumed.

Pain evidence: Public discussion ↗author comment 2026-09-30. The growing, multi-practice firm expressly requests conditional intake forms as part of escaping manual work.
Method: Lawmatics form objects and conditional blocks ↗The guides describe field objects, reusable blocks, and conditional logic. General or form-only fields do not persist as reusable CRM fields.
Method: Lawmatics form objects and conditional blocks · supporting guide 2 ↗Additional official capability reference. The complete adapted recipe has not been tested.

Source checked: October 15, 2026. Pain accounts are self-reported. Documentation supports components; this adapted recipe and prompt have not been tested. Several CRM jobs come from the same firm discussion, not independent firms. We wrote these prompts. The adapted workflow hasn’t been tested.

Suggested approach

Start when: Attorney-approved intake script changes

map only approved questions and branching conditions to persistent fields or form-only fields
Keep source references and report unknowns instead of filling gaps.
The responsible reviewer checks the report before any separately approved action.

Limits and review

The assistant drafts or reports only. Check source records and review the output before a human performs any separately approved send or change. No automatic legal decision, money movement, account connection or publication is included.

Who reviews it: Do not collect identification, health or financial details prematurely; avoid unknown-to-false coercion; provide a human assistance path and lawyer-reviewed relationship disclaimer.

What you need

Your firm-approved AI assistant · prepared files

Existing authorized access to the correct source account and records; no new login, credentials, installation or permission grant is included.
Responsible lawyer/operations reviewer approves scope, definitions and any later action.
AI optional; use only approved minimized data and retain originals separately.
Use synthetic inputs first. Keep real data in firm-approved accounts and processing, with appropriate access, confidentiality and retention controls. Aliases alone do not anonymize records. Never paste credentials, API keys or unnecessary client details.

How to use

Documentation-checked component path; proposed workflow, not tested

Before you start

Native form logic is documented; this workflow drafts a spec, not a generated/importable form.

Check access and setup

The live account, entitlement, exact headers, records and field coverage have not been observed.

Read the existing question and field map
Lawmatics · Docs & Forms > Custom Forms > selected form > field settings; Settings > Custom Field Settings
Capture only attorney-approved questions, answer options, field type, required flag and CRM destination. Use the actual existing form or approved question document. Do not edit or Save Form during evidence gathering.
Expected output
Question inventory with source question IDs and mappings.
Next step
Paste the approved, nonconfidential specification into the drafting workspace.
Check before continuing
General/Form Only fields do not store in CRM, appear in reports or sync to case management. Changing a label does not change its mapped field.
Step documentation 1 ↗Step documentation 2 ↗
Draft from the approved source packet
Acrobat PDF Spaces / AI Assistant, optional · Acrobat home > PDF Spaces > Create a PDF Space > Paste copied text > Add to PDF Space > chat
Paste only the approved nonconfidential packet, source IDs and full Scope note. Paste the exact prompt into the Space chat. Do not upload raw client records; this is a downstream drafting assistant, not an AI in the source application.
Acrobat PDF Spaces / AI Assistant, optional promptUsing only Questions and Scope, draft a Lawmatics form specification. For each question give approved question_id, exact or approved simplified wording, field type, CRM mapping, required flag, controller question and explicit show-if answer. Conditional controllers must be true/false, picklist or multi-picklist; do not derive branches from free text. Include unanswered, every allowed answer, hidden-required and contradictory-answer test cases. Flag any unsupported control or missing CRM mapping. Do not add eligibility scoring, legal advice or sensitive questions; do not edit or publish the form.
Expected output
Question-by-question branch specification and synthetic test matrix.
Next step
Copy reviewed output into an internal review document or the named downstream tool, preserving evidence IDs.
Check before continuing
A required hidden question, unmapped Form Only value or unsupported free-text controller is blocked.
Step documentation 1 ↗Step documentation 2 ↗
Translate the checked branch spec into a build handoff
Form owner, no execution in this research · Lawmatics form editor > select dependent field/block > right sidebar Conditional Logic > controller field > answer that shows the field
Reviewer maps each approved spec line to these documented controls. Blocks may carry section conditions. Record unsupported compound requirements for manual resolution rather than inventing controls.
Expected output
Implementation-ready spec or a list of unsupported conditions.
Next step
A separately authorized form editor can build a non-live copy and use synthetic test cases before any publishing/embedding.
Check before continuing
Set logic on the dependent question, not the controlling question. Saving changes is outside this read-only verification.
Step documentation 1 ↗
Human review and final action
Final human review
Responsible firm reviewer · Internal Review worksheet / review document
Attorney approves data minimization, questions and branching. Form owner checks every synthetic branch and CRM mapping before enabling any client-facing use.
Expected output
Approved specification and test checklist; untested implementation.
Next step
Human builder receives the spec and question-ID map.
Check before continuing
No real intake submission, customer data or automatic case decision.
Step documentation 1 ↗Step documentation 2 ↗

What you’ll get

form-spec.csv: question_id, exact_wording, field_id, field_type, required, branch_rule, persistence; branch-tests.csv: test_id, input_answer, expected_path, unresolved_rule

Inputs and a sample test Synthetic example · not a measured result

Input files

approved-script.csv: question_id, exact_wording, answer_type, required, approved_branch_rule, practice_area
field-dictionary.csv: field_id, type, persist_in_crm, allowed_values; policy.txt: unknown handling, help route, approved disclaimer

Synthetic example

P1: yes answer follows approved branch
P2: no answer skips the branch
P3: unknown answer has no approved branch

Expected output

P1/P2: prescribed paths only
P3: unresolved branch question
No new screening question or rejection

Test a failure

Do not collect identification, health or financial details prematurely; avoid unknown-to-false coercion; provide a human assistance path and lawyer-reviewed relationship disclaimer.

Try with the sample files

Follow the tool steps above and use the inputs named in each step. Where provided, native-* files are blank scaffolds and NATIVE-INPUT-MAPPING explains their fields. Original examples and the optional full review prompt use a separate prepared-input schema. Keep them separate unless the mapping explicitly connects them. Downloading a kit does not connect accounts or prove the workflow works.

Download inputs and checklist 18 files

Instructions, blank templates and separate synthetic examples; these files do not install an automation. Blank templates still need verified source data.

Download starter kit All inputs, synthetic examples and review notes in one ZIP. No automation is installed.
Start here: get the sources and prepare the review Documentation-checked acquisition, explicit manual mapping, exact prompts and human review limits
Input template: approved-script.csv Header-only input template; preserve exact names and order
Synthetic input: approved-script.csv Fabricated sample rows for an offline manual trial
Input template: field-dictionary.csv Header-only input template; preserve exact names and order
Synthetic input: field-dictionary.csv Fabricated sample rows for an offline manual trial
Output template: form-spec.csv Header-only output template; preserve exact names and order
Expected output: form-spec.csv Hand-authored synthetic expected result; not an executed workflow result
Output template: branch-tests.csv Header-only output template; preserve exact names and order
Expected output: branch-tests.csv Hand-authored synthetic expected result; not an executed workflow result
Policy/input template: policy.txt Required source/policy preparation scaffold; not populated with firm instructions
Synthetic policy/input: policy.txt Fixture-only context; not an approved production policy
Synthetic fixture expectations Acceptance targets and failure checks; no claim of workflow execution
Review prompt Copyable offline review prompt; no executable automation
Setup and prerequisites Recipe-specific setup, evidence sources and usage boundaries
Native input scaffold: Questions Empty editorial table for Questions; populate from verified source evidence after reviewed mapping; not a native export
Native input scaffold: Scope Approved text input for Scope; complete from verified evidence and include in the AI-visible packet
Native input mapping and scope guide Old-file-to-native-input compatibility map, acquisition requirements, privacy and blocking gates

Optional full review prompt for prepared inputs

Prepared-input review prompt with Your firm-approved AI assistant · prepared files

Convert this approved intake script into a conditional-form specification. List question, exact approved wording, field type, required status, branch rule and whether it must persist in the CRM. Flag unclear or contradictory branches. Generate synthetic test cases covering yes, no, unknown and skipped answers. Do not invent legal screening questions or reject a prospect.

INPUTS
approved-script.csv: question_id, exact_wording, answer_type, required, approved_branch_rule, practice_area
field-dictionary.csv: field_id, type, persist_in_crm, allowed_values; policy.txt: unknown handling, help route, approved disclaimer

OUTPUT
form-spec.csv: question_id, exact_wording, field_id, field_type, required, branch_rule, persistence; branch-tests.csv: test_id, input_answer, expected_path, unresolved_rule

Use only these synthetic or firm-approved inputs and preserve source row/page IDs. Keep missing or conflicting evidence unresolved. Return a draft for the named reviewer. Do not send messages, connect accounts, change records or permissions, move money, or make legal decisions. Keep source files unchanged. List missing prerequisites before continuing.

Proposed / not tested · editorial prompt. This prompt uses the original prepared-input schema shown in the sample test. Step prompts may use different tables. Follow NATIVE-INPUT-MAPPING where supplied; do not mix the original examples with native-step inputs without mapping and checking every field.

Read original method Read pain evidence