Process Timelines

For Process Director v6.0.300, the look and feel of the Process Timeline has been refreshed with a more modern design. These changes are largely visual, and the fundamental operation of the object is unchanged.

Process Timeline is the automation of a business process in which documents, information or tasks are passed from one participant(s) to another for action. A Process Timeline is made up of many functions and activities such as a review process, Task Lists, notifications, alerts/triggers, reminders, context sensitive tasks, an approval process, status/tracking, due dates and reporting.

What is a Process Timeline Definition?

Process Timeline Definitions in Process Director are a series of logical activities, each with a specific task and assigned participants. The Process Timeline defines the path or route that a Form or document must take. Each Activity in the Process Timeline path defines the task type, the participants, and the rules that govern how the Process Timeline will advance or transition to the next Activity.

The Process Timeline may look familiar to you, because it is presented in Gantt chart format. The Gantt chart is a type of chart that places each Activity in a process on a single line that is horizontally marked in some increment of time, usually days. Each Activity is marked with a bar that whose left end begins at the task's start date, and ends at the task's end date. This type of chart is widely used in project management.

Process Director uses this generic Gantt chart format for the Process Timeline, and adds additional functionality for use in modeling and managing business processes. BP Logix developed the Process Timeline to address the need to measure and predict process execution times.

Time isn't a process driver for a flowchart-based workflow process. Indeed, looking at a traditional process diagram gives you no sense of how long completing the process, or any process task, will take. The Process Timeline, on the other hand, shows you immediately and graphically how much time your process, and each Process Activity, should take. Because the Process Timeline incorporates time explicitly as a process driver, and records the process times for each Timeline instance, Process Director can, using historical data, predict how long each Activity and process will take, and compare that prediction to your configured times. For instance, with the Process Timeline, Process Director can use historical data to predict whether an Activity will be early or fail to meet its configured due date, often well in advance of the Activity starting. This predictive ability enables Process Director, using the Process Timeline model, to provide you with the earliest possible notification of slippages in the process' scheduled run time.

Another important difference between traditional process workflows and Process Timelines is that Timelines are constraint-driven. In a traditional process, tasks don't start until they are prompted to begin when the process follows a specific branch. In a Process Timeline, however, all Timeline activities want to run all the time. The designer's job with a Process Timeline is to apply constraints to each Activity to prevent it from running immediately. By default, this makes Process Timelines implicitly parallel. If you add two activities to a new Process Timeline, but don't configure any restraints, then both activities will run immediately, and in parallel, as soon as the Process Timeline instance starts. Conversely, in a flowchart-based process model, you must explicitly specify when two steps must run in parallel.

Business users design Process Timelines by answering three questions that define the Activity's constraints, as they add each step to the process:

• What activities must complete before this Activity begins? We call this the "dependency question". For each Timeline Activity, you can specify what other Activity, or activities, must complete, before this Activity can begin. Process Director constantly evaluates this question, so that activities can start as soon as their dependencies are satisfied. Dependencies are configured on the Start When tab of a Timeline Activity.
• What conditions must apply before this Activity can begin? We call this the "eligibility question". You can create a Start When condition or conditions that must be true before the Activity can begin, even if the dependencies are complete. This question is also constantly evaluated, in conjunction with the dependency question. The eligibility conditions, or "start when" conditions, are also configured on the Start When tab of a Timeline Activity.
• Is this Activity needed? We call this the "necessity question". If both the dependency and eligibility questions are satisfied, Process Director evaluates this Needed When condition, or conditions, once, when the Activity begins. If the Activity isn't needed, Process Director will skip the Activity, and automatically move to the next Activity. The necessity conditions are configured on the Needed When tab of a Timeline Activity.

The Process Timeline's constraint-driven model enables organizations to build robust, complex executable process models within Process Director much more easily than the flowchart-based model can allow. The result is a solution with many valuable features:

• Modeling is greatly simplified. Project owners list each Activity, estimate its duration, and then drag-and-drop it onto the Activity or activities that must complete before it can begin.
• As many of the activities as possible will run at the same time, without the need to explicitly configure parallel behavior.
• The status of the process can be determined at a glance.
• At any point—even the moment the process is launched—the system can determine which future activities, if any, may not be complete by their due date.
• The system records actual versus predicted execution times each time the process is run, and adjusts its time estimates accordingly.

Most activities have a dependence on one or more other activities. Dependence refers to the requirement that an Activity can't begin until a predecessor Activity, or activities, ends. This type of relationship (often referred to by project managers as finish-to-start) represents the most fundamental starting condition for any Activity.

Below is a sample Process Timeline, consisting of several activities.  The Timeline column of the Process Timeline shows the number of days planned for each Activity. Faculty Advisor Approval is scheduled to take two workdays, Department Approval is expected to take three workdays, and so forth. All of the activities will be tracked for start times and due dates, and successor, or dependent, activities will begin as soon as their predecessor activities end, via the automated process that's governed by Process Director. The Registrar Change of Major Activity is dependent on the Dean's Office Approval. The New Department Advisor Assignment Activity, in turn, is dependent on Registrar Change of Major.

An Activity may also be a parent or child Activity. A parent Activity is a container for other, subordinate activities, each of which is referred to as a child Activity. Child activities have an implied dependence on their parent, so, absent any additional conditions, the child activities begin when the parent Activity begins. Once all of the child activities are complete, the parent is complete.

Activity Types

Each Activity in the Process Timeline has a Type column that displays an icon to identify the activity type. Each activity type displays a unique icon. In the example above, the Department Approval Activity's Type icon indicates that the Activity is a User Activity Type that is assigned to a Group of users, While the Registrar Change of Major Activity's icon indicates the activity is a user activity assigned to a single user. We'll discuss each Activity Type in detail in the documentation topic for each type, but the available icons you might see in this column are shown below.

ICON	Type
	Parent Activity without Looping Conditions
	Parent Activity with Looping Conditions
	User Activity - Single User
	User Activity - Group of Users
	User Activity - Chosen from Form Field
	User Activity - Chosen via System Variable
	User Activity - Chosen via Business Rule
	User Activity - Timeline Initiator
	Notify Activity
	Process Activity
	Script Activity
	Form Actions Activity
	Branch Activity
	End Process Activity
	Wait Activity
	Case Activity

An additional Activity Type, the Custom Task Activity, does not have a specific display icon. Instead, this Activity type will display an icon in the Type column that is specific to the Custom Task that's configured to run in the activity.

Activity Actions

Similarly, each Activity in the Process Timeline has an Actions column with four icons, each of which enable you to modify one of the Activity's properties.

ICON	ACTION
	Drag to move under another parent: Drag the Activity to a parent Activity. The Activity you drag will become a child of that parent.
	Drag to move order: Change where the Activity appears in the Process Timeline. Note: changing the location of the Activity doesn't change the behavior of the Process Timeline, which is strictly governed by the rules of dependence and other Activity starting conditions.
	Drag to add a Depends On: Drag and drop an Activity onto another to make the dragged Activity dependent upon the target.
	Conditions: Click this icon to open the Activity's properties on the Needed When tab. If there are no conditions, this icon will display in a lighter gray color.

The properties for the Activity can be accessed via the Properties menu on the hamburger menu at the right side of each activity. The Needed When Condition(s) can also be accessed from this menu.

An Activity can be added to the Process Timeline by clicking the Create Activity action link. When a new Activity is added to the Timeline, it will be automatically selected and highlighted. Once an Activity has been added, the properties for each Activity are presented in a tabbed interface that can be accessed by double-clicking on the Activity name, or clicking on the Properties icon for the Activity. Each tab in the interface groups similar properties together.

TAB	DESCRIPTION
Activity	This tab enables the user to select the Activity Type, such as a User, Custom Task, Form Action, etc. It also contains other general Activity settings.
Activity type	This tab will show specific properties that pertain to the Activity Type you select. The tab's label will change to reflect the selected Activity Type.
Start When	This tab enables you to inspect and modify the dependencies and conditions that determine when the Activity will start.
Completed When	This tab enables you to inspect and modify the conditions that determine when the Activity will complete. Rarely used, as most activities complete organically (such as when a user submits a form, or an automated task completes).
Needed When	This tab enables you to inspect and modify the conditions that determine if an Activity will be run once its start conditions have been met. These conditions will be evaluated once when the Activity becomes eligible to start.
Due Date	This tab enables you to inspect and modify the due date for the Activity, and the actions to take when the Activity isn't completed by the due date.
Notifications	This tab enables you to configure who is notified about the Activity and when notifications should be sent.
Advanced Options	This tab enables you to configure advanced properties, such as how the Activity is assigned to user, what steps to take when a user completes the Activity, etc.

Processes and Subprocesses #

A business process may occasionally need to invoke a separate process as a subprocess, or child process, of the main process. This subprocess may need to run synchronously or asynchronously with the main, or parent, process.

A synchronous subprocess pauses the parent process while it is running. Once the subprocess completes, the parent process continues from the point where the synchronous subprocess began. The parent process can't continue until the subprocess is complete.

An asynchronous subprocess, on the other hand, does not pause the main process while subprocess runs. Instead, both processes will run in parallel, and both will complete independently of each other.

To invoke a subprocess to run synchronously, you can use the Process Activity Type. To invoke a subprocess to run asynchronously, you can use the Custom Task Activity Type, and use the Run Process Custom Task to start the desired subprocess.

As an example, a Process Timeline that runs a Process activity, or which calls the Run Process custom Task, becomes the parent Timeline, while the Timeline that is invoked by one of these two methods becomes the child timeline.

Documentation Examples #

The examples below use software simulation to walk through the process of creating a synchronous or asynchronous subprocess.

Background Operations #

A Timeline Activity of the Custom Task, Script or Process types can be configured to run in the background by checking the Run this Activity in the background (if unsure, leave this box unchecked) check box in the Advanced Options tab. Setting the operation to run in the background can be used to prevent a long-running, machine-centric Activity in the Process Timeline from hanging a user session while the processing occurs. The Activity will be run in a different context from the current user's, even inf the user invoked the transition of the Activity. Additionally, if you have a Rendering Server enabled, the background processing will be conducted by the Rendering Server when the option is checked.

Please note that, when this option is selected, if the user's task is followed (after one or more intervening "background" tasks) by another task assigned to the same user, the current behavior in which the window remains open and is refreshed with the Form for the subsequent task will no longer be seen. Instead, the Form will close, and the user will have to click the appropriate link in their Task List or email notification to open the for to complete the new task.

On some systems, when starting a subprocess using the asynchronous option, the system can mark the calling task as complete before the called subprocess completes. This may be especially true if the subprocess contains complex rendering operations. To avoid this, a wait time, in seconds, can be set using the nAsyncSubProcessWaitSecs variable in the Custom Vars file. The default setting for this variable is 5 seconds.

Other Process Timeline Topics

To see other Process Timeline topics, you can use the Table of Contents displayed on the upper right corner of the page, or use one of the links below.

Process Timeline Definitions: General Properties for configuring a Process Timeline.

Process Timeline Activities: Properties for configuring Timeline activities.

Managing Process Timeline Instances: Information about how to perform administrative actions on Timeline instances.