The symptom was a blocked journey
Users relied on the portal to sign in and resume work. An invalid-link error interrupted that process, so the useful test was the complete journey rather than the form in isolation.
The visible form settings did not reveal an obvious explanation. We traced what happened as information moved from the form into the redirect and the next page.
The identifiers did not match
The redirect logic referenced field identifiers from a different form. The project history suggested a form had been duplicated and changed without all the connected references being updated.
A form can look correct to a visitor while custom logic still points at an earlier version. Labels on screen and identifiers used behind the scenes serve different purposes.
Correct the connection, then retest
We aligned the references with the active form and tested the login and redirect sequence. The expected journey worked in those tests.
That result belongs to this case. Other invalid-link errors can have different causes, so copying an identifier change from another project is not a diagnosis.
What to check after duplicating a form
Treat a duplicated form as a connected part of a workflow. Review notifications, redirects, conditional logic and any custom code that depends on its fields. Use fictional test details while checking the process.
Keep a record of what was changed and which journeys were tested. When a problem returns later, that record is more useful than knowing only that the form worked once.
For a support enquiry, include the page where the error appears, the expected next step and the point where the journey stops. Do not send login credentials in the enquiry itself.
Need a hand with something similar?
Tell us what you are trying to achieve or what is not working. We will help you work out the next step.
Explore the service Contact us

