Every donation form question needs a next action

Before adding donation form custom fields, name who will use each answer and what action it will change. Keep a field when that contract is real, show it only to relevant donors when your platform supports conditional logic, and remove it when nobody owns the result.

This test is more useful than asking whether a field might be valuable someday. A donation form is an intake point, not a storage unit for questions your team has not decided how to use.

Write the field contract first

Give every proposed field a four-part contract:

• Owner: the person or automation responsible for the answer;
• Action: the task, message, receipt, fulfillment step, or routing choice the answer changes;
• Record: where the answer will live after submission;
• Review: when you will check whether the field is still used.

Suppose a campaign manager wants to ask, “Would you like information about volunteering?” The answer has a job only if a yes creates a visible follow-up for a named person or automation. It also needs a destination that staff can find later. If the answer lands in a spreadsheet nobody reviews, the field has no operational owner.

The same test works for a fund designation, tribute message, event detail, or source question. Write the action in plain language: “If the donor selects the school-supplies fund, attach that designation to the gift record and route it to the campaign report.” If you cannot finish that sentence, remove the question until the workflow exists.

This is separate from choosing suggested donation amounts. Amount buttons help a donor choose a gift. Custom fields ask for information your team must carry somewhere after the gift.

Choose required, optional, conditional, or removed

Once the contract is written, choose the lightest field state that can complete the job.

Require only what blocks completion

Make a field required when the gift or its promised fulfillment cannot be completed without the answer. An engraving line for a selected brick or a shirt size for a purchased event package can meet that test. A volunteer-interest question usually does not block the donation.

Do not make a field required merely because a report looks tidier when every row is filled. Before turning the setting on, confirm whether the rule applies to this form, every form, one campaign, or one record type.

Use optional when silence is a valid answer

An optional field works when an answer can trigger useful work but a blank needs no follow-up. Give the donor enough context to decide. “How did you hear about us?” is vague if your team does not define how the answer changes attribution or campaign decisions. A question like “May we contact you about volunteering?” has a clearer consequence, but it still needs a channel, owner, and follow-up rule.

Use conditional when relevance has a trigger

Conditional logic is useful when only a known subset of donors needs the question. Qgiv's current guide documents fields that appear after a qualifying answer or amount, with examples such as engraving details and team-member information. Check your own platform's behavior; field types, triggers, and record mapping differ.

The trigger should be observable. Show tribute-notification details after the donor selects a tribute option. Show fulfillment details after the donor selects the item that requires them. Do not use conditional logic to hide a question whose purpose is still unclear.

Remove fields with no downstream job

Delete the field when no owner reads it, no action changes, or the same fact already exists in a trusted record. Moving an unused question behind a condition does not fix the workflow. It only makes the waste less visible.

Map the answer before the form goes live

A successful submission is not the end of the test. Send a sample gift through the same path a donor will use, then inspect the resulting contact, gift, receipt, export, and staff task.

Check five things:

1. The answer lands on the intended record, not only in an email notification.
2. Staff can tell which form and field produced it.
3. A blank, false, or “other” answer does not create a misleading value.
4. The owner receives one usable task rather than a buried note.
5. Exports and integrations preserve the label and value without manual remapping.

Use a specific label on the form and in the record. The W3C Web Accessibility Initiative says form controls need labels that describe their purpose and are associated with the control; it also notes that many users prefer or need visible labels. Internal shorthand such as “Program code 4B” may map cleanly for staff while leaving a donor unsure what they are choosing.

If you are still deciding between a hosted page and an embed, settle that form-location decision before relying on a field rule. The available controls, integrations, and testing path may differ.

Review the first 30 completed gifts

After 30 completed gifts, inspect the field instead of trusting the setup screen. This is a review batch, not a performance benchmark.

For each field, ask:

• How many answers produced the promised action?
• Did the owner complete those actions?
• Did donors use the answer choices as expected?
• Did blank or “other” values create manual cleanup?
• Would removing the field lose information your team actually used?

Keep the field when the contract is working. Change its label, options, or trigger when the answer is useful but confusing. Remove it when the team has collected data without acting on it.

CharityStack's current site describes fundraising forms and connected gift records spanning contacts, receipts, outreach, and payouts. Whatever platform you use, that connection is the standard to test: a form answer should arrive where the next person can act on it.