Presentation 

If you have to modify a form that already possesses submissions that are of use to you, you need to set up a migration strategy. Each time you are activating a form, you are creating what we call a new version. Since that time, all the new submissions of this form are created in this version.

But what about the submissions created before this activation?

 

Strategies

Strategy 1️⃣: Migrating the previous submissions in the new version.

Presentation

The objective here is to keep consistency amongst the submission based on the same data structure. We will then migrate the previous submission to the new version. 

Pros	Cons
Homogenous & consistent database Mandatory if you want to use new fields or conditions on existing submissions.	Data from deleted fields is lost Some migration can create problems if the submissions are not valid in the new version (new mandatory field, limits on numbers...)

 

Set up

To do so, you first need to create the migration. It is directly proposed in a pop-in, right after activating the form. 

 

In the next screen (which only appears if fields were deleted), you must match the system names of the previous version with the new version, in order to keep the data of renamed fields. You then need to validate by clicking on "Save & Apply".

 

 

If no field was deleted, you can simply "Run the migration" from the pop-in.

 

❗ Warning

The above method allows you to migrate submissions on the server. However, submissions can stay in their previous state on mobile devices. If that is the case, when the mobile will send an update on the submission, it will be migrated automatically when received on the server.

 

When is this strategy recommended?

• When you are creating a form that is not yet used in real conditions.
• When you are not modifying the data structure.
• When you are adding a feature that you deem necessary on all submissions (including existing submissions or that are in progress).
  • Ex: Configuration of a representation or of a location field on a map.
  • Adding a new condition to prevent an automation to run at each update of the submission.

 

Strategy 2️⃣: Allowing submission migration.

Presentation

The strategy here is to allow submissions to be migrated to the new version, only where they are updated. 

Pros	Cons
Prevents modification of submissions in progress. Allows to monitor the cases where the migration is causing a problem, submission after submission (new mandatory field, limits on a number/date field.	All the data won't be migrated, so the data might not be consistent. Lack of visibility on migrated submissions (or not migrated)

 

Setup

The same process as previously, but do not apply the migration on the last step. You will then need to click on "Save" instead of "Save & Apply".

 

When is this strategy recommended?

• If you wish to update a report template or an automation based on a newly created field, and at the same time minimizing the impact on the work in progress of your collaborators (see below: Particular case about automations & report templates).

 

Strategy 3️⃣: Keep the submissions in their version.

Presentation

The 3rd strategy is to let the submissions in their version. 

Pros	Cons
Make sure there will be no data loss.  Prevents completely the migration problems (new mandatory field, limits on date/number fields...).	Submissions on previous versions will not benefit from updates. It is impossible to do operations like mass update on submissions that are not in the last version.

 

Set up

When activating a form, click on "Close".

❗Warning 

It will always be possible to change your mind and migrate the submissions. For that purpose, you need to click on the "Parameters" button on the form builder, then in the section "Advanced actions", click on "Migrations".

You can then create a new migration (button "New") in order to configure how to go from a version to another, and move the submissions from one version to another (button "Manual Migration").

 

When is this strategy recommended?

• If you wish to add a mandatory field, this method is mandatory. 
• When you are deleting a field in a form, and you don't want to loose data from previous submissions.
• When you are making significant changes in the form, and you are not sure of the impacts a migration could have.
• Overall, a migration can always be made later, but we can't roll back a migration that has been done. When doubtin, it is safer not to do a migration.

 

❗ Things to know

Automations trigger

Migration does not trigger automations (no matter what the trigger is).

Formulas computations.

All of the formulas are recomputed during migrations. If you do not wish to have those formulas computed again, we invite you to change them in manual formulas (untick "Auto-refresh") on them, or not to migrate.

Automations and report templates.

Only automations & report templates are not linked to versions, and based on the active version of the form. 

If you delete a field or a condition in a version of the form used by an automation or by a report template, they will not function properly for this version.

On the opposite, if you wish to update a report template or an automation, based on a new field/condition, those might not work on submission in previous versions.