| Section | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Changing a control Name or a selection control Option Value when that control is referenced in business rules, preconditions, and/or task assignments.
- For example, let's say you change a control name and then perform a pending task for that workflow from your task list. The data entered into the workflow on the prior form version will not display in the task with the renamed control.
- Move a control inside a section, repeat or table.
- Similar to the above example, data from tasks performed before the change may not appear on tasks performed after the change.
- Making a control required that was previously optional.
- Adding steps with required fields.
Update the database (or google sheet, or 3rd party system) supplying data for dynamic select control options on form.[load,activate]. Any task performed from the task list that had an option set that was deleted or changed (for example, to fix a typo) from the database displays the control as blank again and required if that was the default. If you're on a workflow step where these fields are now disabled, such as an approval step, you need to reject back to the user of that prior task to re-enter the data.
This same behavior occurs if you change selection control option values.
Updating a Workflow with In-flight Tasks
Modify Tasks
...
- Adding or changing a precondition; for example if a step is assigned and you add a precondition that resolves to false for that step (so it should be skipped) the user may not be able to perform it.
- Changing a single field to a repeat, or vice versa.
- PDF Mapping - if you update the template, field mapping may be impacted.
Updating a Workflow with In-flight Tasks
Modify Tasks
Let's say you have a Purchase Order workflow in production that is used frequently by your sales team. You have been working on some major updates to the workflow in a development project, and you are ready to update the production workflow. However, you know there are some "breaking" changes that will cause in flight tasks to render in error. For example, you've changed a control in a required signed section, and there is a Client Approval task assigned to a client's email (anonymous user) waiting to be signed. If you update the production workflow, that user may click on their task notification email and see an error message.
...
After enough time has passed that all of your existing tasks from Version 1 of the Leave Request have been completed, you can upload/replace it with a development version (Version 3) that has the controls deleted, the dropdown option removed, and the required controls always required. Since in Version 2, the deleted control was disabled, the deleted option not allowed, and the required control required, workflow interviews started on Version 2, but still pending, will be compatible with Version 3.
Make a Copy of the Form/Workflow
In some cases when you need to make major, or potentially breaking, changes to a form/workflow, you might choose to simply duplicate the form/workflow, start using the copy with the changes implemented and stop using the original/old form. When you do this, the old and new forms/workflows are completely separate - they will have separate submissions repositories, and you will need to update embedding, share links and/or spaces where users access the form/workflow. However, you will not have to use either of the above methods so the development-to-production process is far simpler. This is a good option if you already save all submissions to a google sheet, google drive, database or filesystem instead of using the frevvo submissions repository, or if you don't mind looking in different submissions repositories before/after your new production date (perhaps for a form that changes year-to-year).
One example is a customer who had a production workflow but wanted to update it to use the frevvo Database Connector. Instead of updating the production workflow, they duplicated it and made the changes on the copy. Then, on the original workflow they restricted the Who Can Start the Workflow to designer/owner only, and updated their Space links with the new workflow. Those users who were still in progress on the old flow were still able to perform their tasks and never knew there was a difference, while any new users started on the new workflow.
Form/Workflow designer edit ACL
The Access Control feature in allows the designer to assign other users permission to make changes to forms and workflows.
| Warning |
|---|
The ability to edit a form/workflow should not be given to other users if the form/workflow is in production. Giving this permission would enable those users to edit your production forms directly thereby subverting the best practices described in this guide. |
Multi-Tenant Scenario
Development Tenant
...