User Tools

Site Tools


api:workflows

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.

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

api/workflows.txt · Last modified: 2018-04-20 12:44 (external edit)