+8
Qualified

Workflow Designer: Convert Top Attachment Version to New Attachment Type Automatically

Matt Chabot 9 months ago in Productivity Management updated 8 months ago 3

One of the problems that any admin runs into with having iterating processes is that you cannot require a user to upload a new Attachment Type on a potentially iterating step. You need to have a final review step in many Subworkflow where a decision needs to be made whether to move things forward and transition to the next phase of the workflow or send it back for another round in the same subworkflow.

To avoid requiring users to have to upload multiple times on the final review step of the subworkflow you another transition step is required after confirmation the current phase/Subworkflow is complete. The transition step requires users to upload a clean version of the attachment they just approved in the previous step.

**Note: This is especially apparent in highly regulated industries where too many version is a compliance risk, and more inherently more confusing for no QC specific users.

    The most consistent example would be uploading a finalized file/finished piece at the end of a process where users manually take the top version of the previous attachment type (i.e. Design/Production Proof, Document(s) for Compliance Review, Printer’s Proof, etc.) and are required to upload it as a new attachment type in a different task to start the next phase of the workflow.

    For our firm, this transition step happens at multiple points in our overall workflow. Whether it be two or ten compliance rounds with ten different versions, the Requester/Project Manager/Owner/Administrator takes the top approved version and has an unavoidable step where they are required to upload that file as Final File.

    As an admin, I want the ability to set an output port status action to automatically take the top version of the approved attachment types and convert it to the original file (1st version) of a new attachment type for the next stages of the process.

    This way you can have an iterating final approval step at the end of a workflow/subworkflow that eliminates the need for an additional transition step.

    I think the all or none setup would work fine. The admin would just have to set up their attachment types to be more specific rather than just having general catch alls.

    I think the workflow should simply ignore it if there aren't any attachments of that type. Since this situation typically occurs during a transition step from the end of one subworkflow to the start of a different one, that first step is typically going to be a review step where the reviewer is going to have the option to reject if the correct materials aren't there. Also, in my experience having the workflow fail causes much more disruption to our operations than allowing users to just reject.

    Qualified

    If this is done through status actions it would have to do an all or none kind of operation.  Meaning you setup an action that says "Duplicate Attachments" and you select an originating attachment type and a destination attachment type and then the system would make a copy of the latest version nevery attachment of the originating type and set the copy to the destination type.

    Also, what would you expect it do to if there are no attachments of that type on the step?  Simply ignore it and move on or should the workflow fail at that point?

    I think the all or none setup would work fine.  The admin would just have to set up their attachment types to be more specific rather than just having general catch alls.  

    I think the workflow should simply ignore it if there aren't any attachments of that type.  Since this situation typically occurs during a transition step from the end of one subworkflow to the start of a different one, that first step is typically going to be a review step where the reviewer is going to have the option to reject if the correct materials aren't there.  Also, in my experience having the workflow fail causes much more disruption to our operations than allowing users to just reject.