tFLOW workflows

tFLOW

Workflows

A workflow is a defined set of job states and allowed transitions between states. Each workflow has an ID.

There are three configuration parameters intended to control workflows available for a particular instance:

name default value notes
tethra.defaultWorkflowId 2 This workflow is assigned by default to a newly created order, if the order is created for non-instance company.
tethra.defaultInstanceWorkflowId 2 This workflow is assigned by default to a newly created order, if the order is created for instance company.
allowedWorkflowIdsJson '[2, 8, 20]' These workflows are available for selection when creating orders. Workflows specified in tethra.devaultWorkflowId and tethra.defaultInstanceWorkflowId must be included.

Note that changing workflow for existing jobs is a non-trivial task. Generally it is not possible to automatically migrate job from one arbitrary workflow to another. That's why there is no possibility to change workflow for a job after it is created.

 

Allowed workflows

The allowed workflow values are defined internally in the tethra.php file.
Actually tFLOW supports the current workflows:

   2 - default workflow (one step approval)
   4 - automated release (automatic send to production)
   5 - no release (approval without send to production)
   8 - default workflow with two-step approval
   9 - automated release with two-step approval
   10 - no release with two-step approval
   20 - no approval auto-send
   30 - no approval

    ID of workflows allowed to use in a specific instance is defined setting this variable in the tethra.php config file:.
    // This array MUST include both defaultWorkflowId and defaultInstanceWorkflowId.
    //
    'allowedWorkflowIdsJson' => '[2, 4, 5, 8, 9, 10, 20, 30]',

 

 

 

Job states

Every job in tFLOW always belong to a state within a corresponding workflow.

 

Each job state has an internal name. The semantic of job states is the same as long as their internal names are the same. For example, job state to_upload_first means that the job is awaiting a first revision of artwork in *any* workflow.

Note that, however, not all states are defined in all workflows. For example, approved_awaiting_release is not defined in “No Release” workflow.

The tFLOW API allows to determine the state of any job at any point of time. In tFLOW API, job states are always referred by their internal names.

There is a mapping between internal state names and how they are shown in the UI:

Internal state name UI display label
approved Approved
approved_awaiting_release Queued for download
approved_step_1 Awaiting Final Approval
on_hold On Hold
on_hold_step_1 On Hold (internal)
rejected Cancelled
released Sent to Production
to_preflight Processing
to_review Awaiting Approval
to_review_step_1 Awaiting First Approval
to_upload_again Waiting for Revision
to_upload_first Waiting for Artwork

Transitions

Each transition has an internal name which is used similarly to job internal names. Each transition defines a change between one job state and another. If there is no transition between two given states defined in the workflow, then there is no possibility to change the job state in that way.

For example, the “One-step approval” workflow has no defined transition from rejected to released state, so job cannot be changed from “Cancelled” to “Sent to Production” (see the statechart below).

Each transition has a set of rules which should be passed in order to make the transition allowed for the current user. Some transitions are performing only internally by the system, others are performing by users with a special privileges.

Note that the tFLOW API is always used under some user account, according to that account's permissions. So it is possible that some transitions might not be available via the API, just because the corresponding user account does not have proper permissions.

There is a mapping between internal transition names and how they are shown in the UI:

Internal transition name UI display label Notes
accept Approve when the job is in “On Hold” state
accept_step_1 Accept First (internal) approval step for two-step approval workflows when the job is in “On Hold” state
accept_step_2 Approve Second (final) approval step for two-step approval workflows when the job is in “On Hold” state
approve Approve when the job is in “Awaiting Approval” state
approve_step_1 Approve First (internal) approval step for two-step approval workflows
approve_step_2 Approve Second (final) approval step for two-step approval workflows
auto_release   not displayed in the UI, always performed by the system in background
cancel_from_on_hold_step_1 New Revision  
checks_error   not displayed in the UI, always performed by the system in background
checks_ok   not displayed in the UI, always performed by the system in background
checks_ok_and_release   not displayed in the UI, always performed by the system in background
checks_ok_to_step_1   not displayed in the UI, always performed by the system in background
close_to_rejected Cancel  
place_on_hold   not displayed in the UI, always performed by the system in background
place_on_hold_to_step_1   not displayed in the UI, always performed by the system in background
re_release_from_released Send Again  
reject Request New Revision  
reject_from_approved Cancel when the job is in “Approved” state
reject_from_approved_step_1 Cancel when the job is in “Approved internal” state, for two-step approval workflows
reject_from_on_hold Cancel when the job is in “On Hold” state
reject_from_on_hold_step_1 Cancel  
reject_from_upload_again Cancel  
reject_from_upload_first Cancel  
release Send To Production  
repreflight_from_on_hold   not displayed in the UI, always performed by the system in background
repreflight_from_to_review   not displayed in the UI, always performed by the system in background
request_new_revision New Revision  
request_new_revision_from_approved_step_1 New Revision  
undo_accept Undo Approve when the job is in “Approved” state and moved there from “On Hold” state
undo_accept_step_1 Undo Accept (Internal)  
undo_accept_step_2 Undo Approve  
undo_approve Undo Approve when the job is in “Approved” state and moved there from “Awaiting Approval” state
undo_approve_step_1 Undo Approve when the job is in “Approved internal” state
undo_approve_step_2   when the job is in “Approved final” state
undo_cancel_from_on_hold_step_1 Undo Request New Revision  
undo_close_to_rejected Undo Cancel  
undo_reject Undo Request New Revision  
undo_reject_fom_upload_again  
undo_reject_from_approved Undo Cancel  
undo_reject_from_approved_step_1 Undo Cancel  
undo_reject_from_on_hold Undo Reject From On Hold  
undo_reject_from_on_hold_step_1 Undo Reject From On Hold  
undo_reject_from_upload_again Undo Cancel when the job is in “Cancelled” state and moved there from “Waiting for Revision” state
undo_reject_from_upload_first Undo Cancel when the job is in “Cancelled” state and moved there from “Waiting for Artwork” state
undo_request_new_revision Undo Request New Revision  
undo_request_new_revision_from_approved_step_1 Undo Request New Revision  
upload_first_revision Upload Artwork  
upload_next_revision Upload Revision  

Currently tFLOW supports several workflows described below.

One-step approval (ID = 2)

 One-step approval statechart

Automated release (ID = 4)

 "Automated release" workflow statechart

No release (ID = 5)

 "No release" workflow statechart

Two-step approval (ID = 8)

 "Two-step approval" workflow statechart

Automated release with two-step approval (ID = 9)

 "Automated release with two-step approval" workflow statechart

No release with two-step approval (ID = 10)

 "No release with two-step approval" workflow statechart

No Approval (ID = 20)

 "No Approval" workflow statechart