Troubleshooting
Multi-Step and Conditional Forms
Multi-step forms (also called wizard forms or conditional forms) split a long form into multiple steps or pages. SourceTag works with these, but where you place the hidden fields matters.
The key principle
Hidden fields should be in the step that actually submits the data. This is usually the final step.
When a multi-step form submits, it sends all the fields from the step that contains the submit action. If the hidden fields are in step 1 but the form submits from step 3, the hidden field values might not be included in the submission.
How different form builders handle steps
Single form element with step visibility
Most WordPress form builders (Gravity Forms, WPForms, Fluent Forms, Formidable Forms) use a single <form> element and show/hide steps using CSS or JavaScript. All fields exist in the same form element, regardless of which step is visible.
In this case, it doesn’t matter which step you place the hidden fields in. They’re all part of the same <form> element and will be submitted together. SourceTag processes the entire form on page load and populates all hidden fields at once.
Recommended: Add the hidden fields to the first or last step. Either works. Putting them in the last step keeps them grouped together and out of the way.
Separate form elements per step
Some form builders create a new <form> element for each step. Each step is essentially a separate form that submits independently (often via AJAX) before moving to the next.
In this case, the hidden fields need to be in the specific <form> element whose submission you want the attribution data attached to. This is usually the final step, since that’s typically where the lead is created in your CRM or email notification.
Recommended: Add the hidden fields to the last step’s form. If you need attribution data at every step (uncommon), add the hidden fields to each step’s form.
Dynamically generated steps
Some form builders dynamically add and remove step HTML from the DOM as the user progresses. The MutationObserver in SourceTag watches for new forms added to the page, so if a new <form> element appears when the user moves to a new step, SourceTag will detect and process it.
However, there’s a timing consideration. If the new <form> element is added and the user submits it very quickly, there might be a brief window where the hidden fields haven’t been populated yet. In practice, this is rare because the MutationObserver fires almost instantly.
Popular form builders
Gravity Forms multi-page forms
Gravity Forms uses a single <form> element with “pages” shown/hidden via JavaScript. Hidden fields exist in the same form regardless of which page they’re on. Place them on any page.
WPForms multi-page forms
Same as Gravity Forms. Single <form> element. Place hidden fields on any page.
Typeform
Typeform renders inside an iframe, so SourceTag cannot directly inject hidden fields. Use Typeform’s hidden fields feature instead. See Add Hidden Fields to Typeform.
Elementor Forms multi-step
Elementor Forms uses a single <form> element with steps controlled by JavaScript. Place hidden fields on any step.
Formidable Forms multi-page forms
Single <form> element. Place hidden fields on any page.
JotForm
JotForm’s multi-page forms also use a single form element. Hidden fields can go on any page.
Custom JavaScript multi-step forms
If you’ve built a custom multi-step form, the approach depends on your implementation:
- Single
<form>, showing/hiding steps with JS: Put hidden fields anywhere in the form. SourceTag handles it automatically. - Multiple
<form>elements, one per step: Put hidden fields in the form that submits to your backend or CRM. - No
<form>element, JavaScript-only submission: Use the JavaScript API to read attribution data and include it in your submission payload.
Conditional logic (show/hide fields)
Some forms use conditional logic to show or hide fields based on user input. For example, selecting “Phone” as a preferred contact method might reveal a phone number field.
This doesn’t affect SourceTag. The hidden fields are always present in the form HTML, regardless of whether conditional logic is active. They don’t depend on user input and aren’t affected by show/hide rules.
Testing multi-step forms
- Visit your site with UTM parameters:
?utm_source=test&utm_medium=cpc&utm_campaign=multistep-test - Open the browser developer tools
- Navigate to the page with the multi-step form
- Before interacting with the form, inspect the
<form>element in the Elements panel - Verify that the hidden
st_fields are present and have values - Progress through the steps and submit the form
- Check the form submission (email, CRM, form builder entries) for the attribution data
If the hidden fields are present in step 1 but missing from the submission, the form builder is likely using separate form elements per step. Move the hidden fields to the final step.
Further reading
- Troubleshooting for other common issues
- Captured Fields for the list of available hidden fields