Types of Progression Tasks

Task Template Type Description

Available in:

ü Progression

ü Progression Lite

A single Start Task is the node where Progression starts every work item for a new process instance.  It is the only type of task that provides an Entry Point where the arrival of a new work item triggers a new process instance to begin its workflow process on its work item.

The Start Task serves as the entry point defining where work starts and where it goes after it starts the workflow for a process.

Note:  As each process definition is created, the Start Task is automatically created and placed in the Process Designer window ready for you to complete its specification. 

Note: Only One (1) Start Task is allowed per each process.

Available in:

ü Progression

ü Progression Lite

At least one Exception Handling Task is required for all process definitions.  It is a special manual-user task that defines the ‘what’ an exception-task user must do when an exception occurs somewhere in the process to resolve the problem and return the item to workflow.  One or more individual Steps may be specified in an Exception Task.

For example, when an unexpected error or problem occurs in any task, the default Exception Task can receive the work item from anywhere in its process for expert resolution and return to normal workflow once the issue is resolved.

Note:  Since an Exception Task is required when each process is defined, it is automatically created and placed in the Process Designer window ready for you to complete its specification.

Note:  Only One (1) Exception Task (i.e., the Default Exception Task) is allowed per process with Progression Lite.  However, multiple specialized Exception Tasks may be added, named and connected to specific exception paths using full Progression.

Available in:

ü Progression

ü Progression Lite

A Manual User Task is used to define some form of human interaction, such as manager signing a document or acquiring and processing additional information about a document or multiple documents in a work item binder.

Note: The visibility and accessibility of subscribing users for this task is determined by either the:

•      Assignment Tab for this Manual User Task

OR

•      Assignment Block scope in which this Manual User Task is located as defined by an Assignment Task and its corresponding End-Assignment Task.

Available in:

ü Progression

An Assignment Task defines the resources to be assigned (i.e., subscribers) to subsequent user-attended tasks within the scope of an ‘Assignment Block’, as well as determines the visibility and accessibility of the work-item task to an Individual or a Team of its subscriber set.

•      Individual Assignment Accessibility Rule:  The 1^st User to perform a work-item task within the ‘Assignment Block’ scope will continue to retain exclusive accessibility of the work-item for all Manual User tasks until the End Assignment task is reached.

§ Unless, of course, authorized reassignment overrides are performed affecting this 1^st User.

•      Team Assignment Accessibility Rule:
Any Team member is able to see and perform any of the Manual User tasks for the same work-item while in the current ‘Assignment Block’ scope.

§ However, authorized Group memberships may be changed which will only affect the accessibility of future Manual User tasks within the current ‘Assignment Block’ scope.

Available in:

ü Progression

An ‘End Assignment Task’ is used to indicate an end-point for the scope initiated by an ‘Assignment Task’.

This ‘Assignment Block’ scope established by an Assignment Task and its corresponding End-Assignment Task defines the accessibility that an individual or team will have as subscribers to all user-attended Tasks within this scope.

The End-Assignment Task is used to terminate the scope for the current ‘Assignment Block’.

Subsequent user tasks will be assigned by either:

•      The Assignment Tab for each  Manual User Task  or Exception Task

OR

•      Another Assignment Task and its corresponding  End-Assignment Task.

Available in:

ü Progression

ü Progression Lite

A Decision Task node in the workflow path is used to enforce a binary decision to determine which one of two possible workflow paths a process will follow.

For example, if an Accounts Payable Manager must make a decision in a prior manual user task, such as “Approve Invoice”, the manager may decide to “Approve” or “Deny” the payment by updating an index field with this decision. 

The Decision Task tests the index value to route the work item in one of two (2) possible path-directions in the workflow based test result for the “Approve” or “Deny” binary decision.

Note:  The Decision Task does not support Human interaction since it is an automatic task.  It is placed in the path to make automatic decisions based on information associated with current work item to decide which branch the work item must follow.

Available in:

ü Progression

ü Progression Lite

Inserts a new Split Task with the OR condition in the current workspace. The OR Split Task defines a task with multiple decision paths. The first matching decision-condition applied to the work item determines the workflow path that will be followed.

For example after indexing, where an invoice had its account information and invoice amount entered prior to entering workflow, an OR Split Task is used to enforce business policy on “Invoice Processing” which could specify different workflow paths depending whether:

§ This invoice is covered by the supplied PO number index,

•      Should have a PO number index value before proceeding to processing

•      Selection of one or more different paths based on specific invoice-amount ranges. 

The first condition in the OR Split Task that matches the work item’s index state becomes the path for the current work item.

When the last entry in an OR-Split Task condition list does not specify a condition or is simply specified as True, it becomes the default path when none of the other conditions evaluated to True.

Available in:

ü Progression

ü Progression Lite

The AND Split Task defines a set of multiple paths to be taken within a process creating parallel processing workflow paths followed concurrently for the same binder or documents.

For example while an Employment Application, Resume and Interview Notes are being reviewed as a work item by one department, the HR department may be performing background checks (using the same work item documents) to verify references and wait to receive the applicant’s college transcripts at the same time; these are concurrent paths within the New Hire Process established by the AND Split Task.

Available in:

ü Progression

ü Progression Lite

The Merge Task defines a point for parallel paths (created by an AND Split Task) to converge the parallel paths back into one serial path.

When an AND task has been used, it is required to have a corresponding Merge Task to converge all paths and ensure the process flow continues further down the workflow.

For example, the Employment Application Review path which is concurrently performed while the HR department verifies References and Transcripts are parallel paths within the New Hire Process.  These parallel paths are allowed to converge into a common path again by the Merge Task which leads to a final “Hire” or “No Hire” result for the New Hire Process.

Available in:

ü Progression

ü Progression Lite

The Wait Task is an automatic process flow-control task that suspends a work item’s progress until specified condition(s) have been met which are expressed as one or more named Wait-Task Rules.

These rules contain specific event-conditions which may cause the flow-control for a work item at the Wait Task to delay until the necessary conditions required by its Rules are met, such as any combination of the following:

•      Specified logical condition(s), created using the Expression Builder tool, are detected and satisfied by the Wait Task’s Rule(s).

Note: A rule-condition test can be applied at a specific interval of time as well as limited to a maximum number of repetitions. 

•      Designated document(s) arrive in DocuPhase or change to a required state that is expected or required to continue the process;

•      A Defined time-limit for the Wait Task is exceeded, allowing it to release its work item to flow out its ‘Timeout Path’.

For example, the HR Department needs to wait for school/college transcripts before they can verify them for an employment application – This could use a Wait Task to detect and handle this situation. 

Once the missing Transcripts arrive, the work item, which now includes the transcripts, is able to continue to the verification step and beyond in the New Hire Process workflow.  

Similarly, a workflow may wait for an External Database record to appear before continuing.

There also may be a time limit on the amount of time to wait.

Each of these types of conditions can be a Wait Task Rule with a different named continuation path to the next appropriate task in the workflow process.

Available in:

ü Progression

The Data Synchronization (Data Sync) Task defines a task to access and/or update data in one or more external data sources (e.g., databases) within DocuPhase or external to DocuPhase.

For example, a Data Sync Task can be used to synchronize the current work item’s Invoice document indexes stored in DocuPhase with information in the client’s Accounting Database. 

A typical example is where a work item’s Account ID index field contains a valid ID number which the Data Sync Task uses to lookup this ID’s account information and automatically update the associated information in other index fields for the work item.   

Similarly, it is possible for information in a client’s external database(s) to also be updated by a Data Sync Task.

 Note: There is not any human interaction with this fully automated task making it efficient plus it avoids human transcription errors.  Because the information is accurately retrieved from the actual business databases, the work item and indexes in DocuPhase and Progression are in-sync with the business.

Available in:

ü Progression

The Automatic Task is a node in a workflow path that will automatically execute an external application.  One or more Steps may be specified in an Automated Task.

For example, the Accounts Payable Process could have an automatic task that would automatically print the General Ledger transactions for month end.

Available in:

ü Progression

A Sub-Process Task is used to make a work item enter another pre-defined Process as if it was a compound task composed of many nested tasks. 

The Sub-Process Task allows you to select from other defined processes and re-use its capabilities within another process. 

For example, when the Accounts Payable Process pays a vendor invoice, a sub-process might be used to record the invoice number on the general ledger.

Available in:

ü Progression

ü Progression Lite

The Finish Task is a process end-point and at least one Finish Task is required to complete a process. 

For example, when a workflow process will end, the Finish Task is used to represent a completion point.

Note:  Although there is only one Start Task with its one Entry Point, there can be more than one Finish Task node in the design for a process to handle the potentially different ways a process may end on different paths.

Each path in a Progression workflow network must ultimately end with a Finish Task.