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