Page Comparison

...

• 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

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.

Follow these steps to identify and modify tasks that may be impacted before you update the production workflow.

1. Optional: Set the Who can start the workflow? permission to "Designer/Owner Only" to prevent new submissions while you take the following steps.
2. Search the Task List (as Workflow or Tenant Admin) for Pending tasks in this workflow. You can also filter by date, user, etc.
   1. You may also want to search the Submissions Repository for tasks that are pending. Tasks that are pending, but the "Locked By" column is empty, are pending for an email/anonymous user.
   2. Review the audit trail of each task to see how far along it is in the workflow.
      1. Tasks that are near the end may be able to be pushed through to completion (by communicating with, or logging in as, their assigned user.)
      2. For tasks that are pending for an email or earlier in the workflow, you may choose to modify the task and reset it back to Step 1. Tasks on Step 1 can be edited by the Step 1 user to ensure they meet the updated workflow's validation (required controls, etc.), and that user can click Continue to send it forward as usual.
3. Once all pending tasks have either been completed or returned to Step 1, you can upload/replace your development workflow into the production project.
4. If you changed the workflow permissions, change them back to their original state.
5. Follow up with the users of modified tasks and/or login as those users to resubmit the existing tasks. You may also need to communicate with email users and ask them to perform their most recent task notification and ignore the prior one.

Update in Stages

The Modify Tasks option may sound daunting if you have hundreds or even dozens of pending tasks. Another option some customers choose is to update the form in stages. Let's say you're updating a Leave Request workflow, and you will be removing some controls, removing a dropdown option, and adding some required controls.

Stage 1

Make these interim changes on a development Version 2 of your Leave Request workflow, then upload/replace the existing production versions (Version 1) with Version 2.

• For the controls you intend to remove, make them disabled instead. They will still be visible on existing submissions, and will not cause in-flight flows to break.
• For the dropdown option you intend to remove, change the label to something like "not available" and add a business rule that sets the control to invalid and provide a helpful error message if that option is selected on the first step. Again, this will allow existing submissions with that option selected to function, but will prevent users from selecting it on a new workflow interview.
• For the controls you intend to make required, use a business rule to set them as required only on step 1. Existing tasks and submissions will be past step 1, so they will see this control as required. You can extend this logic to apply to your specific use case.

Stage 2

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.

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.

Multi-Tenant Scenario

Development Tenant

...