Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Download the form from your production account.

    Info

    frevvo recommends that customers maintain backup .zip files of production forms and workflows in their own version repository. Each time you download a workflow from production, provide it with a unique filename (i.e. MyWorkflow_flow prod YYMMDD.zip) and maintain it in your directory as a backup. In case a later development version has incompatible changes, you will be able to revert to your latest backup version.

  2. Upload the form to a new or existing project in your development environment.
  3. Make the changes.
  4. Download the updated form/workflow from your development account.
  5. Upload it to your production account. Be sure to check the Replace checkbox on the Upload screen. The XML schema checkbox will automatically be checked.
  6. The existing version in your production environment will be replaced with the modified version from the development environment. You will see it at the end of the form/workflow list.

...

Info

When a production workflow that has pending tasks associated with it is edited and replaced with an updated version, pending tasks will contain the changes the next time they are "performed" from the task list. For example, let's say you

  • Add or delete controls in a signed section and there are workflows pending (in flight) that have already been signed.
  • Add/remove a field that was used in a business rule; ex: Add/remove a column from a table that was used in a calculation.
  • Change a spreadsheet that you are reading from or writing to using the Google connector.

When you edit a workflow and change business rule rules or add/remove fields, all the pending tasks pick up the latest version of the workflow. Pending tasks for a form/workflow that integrates with a Google sheet reflects any changes made to the Google sheet while the tasks are in-flight.

When uploading a form/workflow with the same ID as an existing form/workflow, without checking Replace, a copy will be created and the designer will see an error message: "The form/workflow that was uploaded matches the id of one that already existed so a copy was made. If you intended to replace the existing form/workflow, delete the form/workflow you just uploaded and upload it again but check off the ‘Replace’ option."

When uploading a form/workflow with Replace checked that is currently being edited by another user, the designer will see this error message: "This form/workflow is currently being edited by <user@tenant>. Please try again later."

...

These changes can impact the forms form's schema and routing, and thereby may impact forms and workflows that are in - progress.

  • 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.
  • Adding, removing or changing controls inside a signed section - this will invalidate signatures on sections that have already been signed, including completed forms/workflows that are edited from the Submission repository.
  • 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.

  • 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.

...

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.

...

  • 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 not required. However, all new submissions will start on Step 1 and the control will be required. You can extend this logic to apply to your specific use case.

...

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.

...