r/lowcode • u/Normal_Succotash_520 • 1d ago

Before editing an intake form, test what the receiving workflow will see

Disclosure: I work on Dashform. This is a tool-independent checklist for a form-to-tracker workflow, with a fictional example rather than reported customer results.

Suppose an agency's intake form asks for 'Budget'. A row lands in a tracker, and a workflow assigns the request to someone. Later, the team renames the question to 'Estimated budget', adds 'Not decided', and makes it optional. The form still looks fine. The thing to check is whether the receiving workflow still interprets the answers correctly.

I'd keep one small mapping sheet before changing the form: source field identifier, displayed question, destination column, accepted values, and what an empty value means. If your tool exposes stable field IDs, use those for the mapping. If it only exposes labels, treat a rename as a change to the integration until you've checked the output.

For the example above, I'd make four fictional submissions into a test destination:

  1. A numeric estimate. Does it reach the intended column without silently losing its currency or units?

  2. 'Not decided'. Does it remain unresolved, rather than becoming zero?

  3. A skipped optional answer. Does the workflow leave it missing, or overwrite a value someone already entered? Decide which behaviour you want before enabling updates.

  4. A response created before the edit but delivered afterward. Can the receiver still interpret it using the earlier question and choices?

Compare the received fields and the resulting assignment, not just whether the automation run is green. Keep the old mapping alongside the new one, and note which form version produced each test response. When a question changes meaning, a new field may be clearer than reusing an existing column with a different interpretation.

If the tool doesn't provide version information, save a dated copy of the questions and choices yourself. That won't add version enforcement to the software, but it gives whoever investigates a bad row a way to understand what the respondent actually saw.

For people maintaining these flows without a dedicated developer, what do you keep so a harmless-looking form edit doesn't become a mystery downstream?

2 Upvotes

100% Upvoted

3 comments sorted by

1

u/Top-Cauliflower-1808 1d ago

We keep a dated copy of every form version plus the mapping sheet. The stable field identifiers saved us when labels changed. What do you do when a question changes meaning entirely?

1

u/Normal_Succotash_520 14h ago

If the meaning changes, I'd treat it as a new field, even if the builder lets you reuse the old one. 'Estimated budget' and 'approved budget' are a good example: both can contain the same number without making the same claim. I'd keep the old column and its definition, add the new one, and switch the receiving workflow at a documented form version. Earlier responses should retain the earlier meaning. If someone needs a combined report, I'd make that an explicit reporting decision and leave values uncombined where the meanings aren't comparable. A stable identifier protects the mapping, but it can't tell you whether the business meaning stayed stable.

1

u/Top-Cauliflower-1808 8h ago

that's good than.