Managing form changes through URL management
Submitted by andyp on Wed, 03/25/2015 - 07:51
If your forms use Custom Validation routines or Integrated Components that you have developed in house, then these should be kept in sync where you maintain multiple environments or else you can introduce problems when moving exporting/importing forms between them due to the references not being kept synchronised. This can result in your form questions being linked to different validation routine because they weren't setup in the same order on all environments for example.
If the deployment processes are controlled and scripted, then keeping all environments in sync so that you can export and import forms freely between environments with no impact is possible, and allows you to promote your forms effectively through DEV, TEST, PROD etc as needed.
An alternative I often get asked about though is offered below which can be useful when either the above is not true, you don't have the time for the above given an urgent change requirement, or you simply don't have that level of infrastructure in place. This approach can also be particularly useful when you are dealing with changes to forms that have a high traffic throughput, or you need to be certain that the organisation knows that a form submission applies to which version of your form based upon recent legislative or rule changes for example.
In such circumstances, most organisations will choose to implement a strict business change management control procedure in order to be fully aware of what version of a form an end user may have completed.
Through XFP, a form can simply be copied and saved as a new version (through the Blue action button). In it's simplest sense, the copied form version can then be amended and brought into existence through URL management, such as Friendly URLs within the Utilities module of the Jadu platform. An existing content link to this form is re-pointed from the old to the new form version. This will allow new site visitors to move straight into the latter version of your form, whilst allowing users already within the earlier form version to have a period of grace / opportunity to complete their form under the older version (as they may have saved it on their account or may be midway through a larger form and so you do not wish to disrupt them). Then later on you make the earlier version "Not live", process the remaining data and archive the old version of the form for good.
So for example, rather than linking form within your web content direct to a form url e.g.
You could link to a friendly url in your content such as:
This friendly url is initially setup to point users towards that original form url.
You later decide that changes are required to the form, so copy save it as a new form, this reproduces the form within the same environment but under a new form identifier such as the below, but is made "Not live" from the process of copy saving automatically so that it is not available for use at this time.
You proceed to make the necessary changes in this new form version, preview it to test validations etc, make it live (but still invisible) to further test your integrations and styling in context etc, then when you're happy simply repoint your friendly url from the old form to this new form url and users will begin to filter int your new form.
At this time you may choose to put a simple notice message within the instructions of the old form as well to alert anyone still in it that it will be turned off soon - or alert anyone new that is finding it from automatically created system links (like the forms listing pages for instance). To avoid confusion here, I would only normally have one of the form versions set to "Visible" at any one time (so that they don't see two forms of the same name next to each other and cause confusion). Leave it a month or whatever is reasonable then go make the first form version not live as well, process any remaining data through workflow and archive the form out of harms way.
This will segregate submitted data into different form data pots per say, and so this would need to be accounted for in any reporting or statistics that you provide about numbers of submissions then moving forward when you are in an interim period of those reports, but various tools in the system can help produce those numbers with you.
I hope these concepts help you all out a bit, and would be interested to hear if anyone has approached this in a different way at all.