The intention of a re-provision is to align an existing project (target) with a template (source). This could be due to updates to standard folder structures, shared files or common form definitions, as well as roles and permission models. The re-provisioning process allows for copying new data from the source project and overwriting existing data that already exists in the target project.
Important - Re-provisioning is an irreversible process and should be used with caution.
When re-provisioning form definitions, the service checks what form definitions exist and are approved/published in both the source and target projects. The re-provisioning process only copies form definitions from the source that are approved/published. Form definitions in draft or archive mode are not copied from the source to the target. Additionally, the re-provisioning process only adds new forms from the source, it does not remove forms that do not exist in the source.
If a form definition exists in the source project but not the target project, the re-provisioning process will create a new form definition in the target project to match the source. Any workflow from the source form definition will also be copied to the target project.
Each form in the target project has a property (ImportedFrom) that identifies which form it was copied/imported from. This field has a unique GUID which matches the form in the source project. By checking that property during provisioning, the service knows which form it originated from and it is updated accordingly regardless of what Status the form is in.
If this property is not present, or no matches are found – the service will check if any form definitions match the source form definition Name. If there is one (or more) form definitions where the Name matches those in the source code, then those form definitions will be updated regardless of their Status.
In the source project only forms in a Published status will be copied. Hence, if there are forms in the source project you do not wish to copy during the reprovisioning process, make sure they are in a Draft or Archived status.
Note: Previously form definitions in the target project that were in Draft status were not overwritten. This workflow has changed to now overwrite those form definitions as well.
If the source form definition design differs from the target form definition, the design of the source form definition overwrites the target form definition design to become identical.
If the source form definition does have fields and/or bindings that do not exist in the target form definition, the fields and bindings are added to the target form definition as par the source design.
If the source form definition does not have fields and/or bindings that do exist in the target form definition, the fields and bindings are removed from the target form definition.
If the source form definition workflow differs from the target form definition, the workflow in the source form definition overwrites the target form definition workflow to become identical. If the target form has no workflow, it is not updated, and the form definition will remain without a workflow even after being copied. Workflows are managed per form definition type, which means that overwriting a workflow for a single form definition will affect all form definitions of that type in the target project.
If the target form definition does not have any form instances against it, overwriting the form only affects the design, fields and bindings of form instances that are created after the re-provision.
If the target form definition does have any form instances against it, overwriting the form affects design, field and bindings of existing form instances, including the addition and removal of fields/bindings, as well as any form instances that are created after the re-provision.
As an example, a target form definition that includes a field which is later removed by re-provisioning from another source loses that field in any existing form instance. Similarly, any added field will appear in existing form instances but will be empty, even if it is required, as it was not filled out at the time of creation.
If the target form definition does have a workflow associated with it, overwriting the form will update the workflow as well. If the form definition has any form instances against it, their status must match a status that is in the updated workflow. If a form instance is in a status that is not in the workflow, it will get stuck. Best practice is to ensure that form instances in the target project match the source workflow to avoid issues. Should a form instance become stuck, a new status matching the missing one and a transition from it need to be created temporarily to make it unstuck.
Before starting the process, please ensure that all form definitions that should be copied from the source project are in Approved/Published mode, otherwise they will not be copied.
Before starting the process, please ensure that all form definitions that should be overwritten in the target project are in Approved/Published mode, otherwise a new duplicate form definition will be created instead of an overwrite of the existing one.
Q: Can I undo the re-provisioning process?
A: No, the re-provisioning process is irreversible and thus should be used with caution.
Q: My target project has a form definition that does not exist in the source, will it be deleted if I re-provision?
A: No, form definitions that exist in the target project but do not match the source are not deleted. The process is to merge form definitions from the source project to the target, either by adding new form definitions if they do not exist or by overwriting form definitions if they do exist.
Q: If my target project has form instances that have photo drop fields that already have photos uploaded, will the photos be removed?
A: No, attachments that have been uploaded to existing form instances will remain as attachments although the field disappears
Q: If my target project has form instances that have filled out fields that are removed, will that data be deleted?
A: No, but it will be hidden. The data binding and the stored data will still exist but there is no way to get to it through SYNCHRO reports. The properties can be brought back by re-adding the fields with the binding to the form definition design in the target project.
Q: Can workflows be updated in the target project if form definitions are overwritten from source?
A: Yes, if a workflow exists for both the source and the target, the re-provisioning process updates the workflow in the target project. If the form definition in the target project does not have a workflow, the workflow is not copied over from the source.
Q: Can new workflow be created in the target project if form definitions are overwritten from source?
A: No, the re-provisioning process does not create a new workflow if one does not already exist for the form definition type in the target project. It is recommended that admins set a simple workflow before initiating the re-provisioning process.
Q: Can source project and target project be hosted in different data centers?
A: No, form definitions can only be copied between projects within the same data center.
Q: Is there a way to copy only some of the form definitions from the source project?
A: Yes, the re-provisioning process only copies form definitions that are in the Approved/Published state in the source project.
Q: Can a project that is available as a template be removed from the template list?
A: No, once a project has been marked as a template it cannot be reverted.
Q: Are forms in draft and archived mode in the target project updated?
A: No, only forms in the approved/published mode in the target project are updated. Please note that this could lead to duplicates if an identical form definition from the source project is copied over and the target form definition is in draft or archived mode.