Skip to main content
Mitratech Success Center

Workflow Step Task Types

Users are assigned a task when they are added to a workflow step. A context sensitive web page or eForm is displayed that is specific to the task type when the user selects the entry in their Task List, or the link in their email notification.

Workflow Step Task Types

Each task type defines a set of functions or actions that can be performed, as well as custom instructions for the participants. The workflow engine embedded within Process Director supports the following tasks:

User Task

The user task is any actionable item assigned to a user. If a user task has been assigned to a user, a Task will appear in their Task List. They must complete the task before it can be removed from the task list. A user who is assigned a task will be automatically given permission to any object in the workflow package so they may complete the task. Examples of this task can be an approval task or update task.

When a Workflow Step is assigned to a user with an invalid UID or user ID, Process Director will immediately stop the process, and place the Workflow Step into an error state. This is also true for anonymous user assignments if the email address is not a valid format (Process Director cannot validate the email address itself, only the format).


A user step in the workflow can have participants assigned to it. Some workflow steps can run without any users (e.g. eForm Actions, Parallel Tasks, Sub Workflow, etc.).



A user step can assign participants by user, group, From eForm Field, Business Rule Value, and the Workflow Initiator. Any number of users can be assigned to a task.


Due Date

Each step in the workflow can have unique time limit/due date options. Process Director runs as a virtual directory in IIS and processes all time related events like due dates when activity is present on the system (e.g. a login). To force this activity checking more often, you can schedule a command in the bputil.exe utility.


Task is Due Within

This specifies a due date for this step. The step due date is optional. If a step does not complete by the due date specified it can automatically transition to the next step in the workflow. The due date can also be used to prioritize items in a user’s Task List.


Set Due Date to Form Field

This will allow the user to specify a due date on the form using a Date Picker for that step in the workflow process

If Time Limit Expires

If the time limit (due date) passes before this step is complete these are the actions that can be taken.



Leave Step Running

This lets the step continue running.

Cancel Step

This will cancel the step and automatically advance to the next step in the workflow.

Add These Users from Business Rule

This will add users identified in the Business Rule.

Replace with These Users from Business Rule

This will add the user from the Business Rule and cancel any running users.

Jump to Workflow Step

This will cancel the step and automatically jump to the step Name that is specified



Each step in the workflow can have unique notification options.


Notify Participants When Step Starts

This will allow the workflow to notify all users that have been assigned from the Participants tab.


This will allow you to select a user or users from various places in the workflow and form to notify in that current step. Once you have made your selection you will have to select from the Choose Notification Time. You have up to three selections to notify.

You can tell the step how to determine what users to notify with the following options:

Notification Time

  • When step starts.
  • When step completes.
  • When users complete: You can choose specific users or groups whom you wish to complete the task prior to notification.
  • When step is past due date.

You may also choose various reminder times, to send notifications a varying number of days before or after a task is due. Sending these reminders are useful for creating escalation notifications, or notifying managers that tasks are slipping past due dates.

Notify Type

  • All Active Users in Step: this will send a notification to all users who have yet to complete a user step
  • All Users in Step: this will notify all the users involved in this User step.
  • Users: this allows you to select specific users to notify.
  • Groups: this will notify all users in a specific group.
  • Business Rule Value: this will notify the user result of a Business Rule.
  • Workflow Initiator: this will notify the initiator of this workflow instance.
  • From eForm Field: this will notify a User specified by a form on the container eForm.
  • External Users: this will send a notification to a specified email address.

Using Email Template

This is an optional email template to use when sending email notifications to users in this step. If this is not specified, the default email template will be used that is shipped with Process Director. For more information on email templates refer to the section named Using Email Templates in this guide.

Advanced Options

Depending on the task type for the step different options will be available. Some of these options will appear under the Advanced Options tab, others will appear under a tab that is unique to the task type.


Use eForm in this Step

This will allow you to specify an eForm to use in this step. This controls the form displayed when a user opens their Task List.

Step is Complete When

This will allow you to select when the step is complete. You can choose when “All Users Have Completed”, “First User Completes Task”, or “When any branch condition is met”.

Restart Users

This option determines how participants are assigned to the step when it must be restarted. This is particularly relevant when an implementer changes the participants assigned to an activity in the Workflow definition. An existing instance may have been created when different participants were configured to participate in the task. This option enables you to determine how to handle user assignments when the configured users have changed.

The following options are available:



Start only configured task participants

This option will assign the task to the currently configured users, irrespective of which users may have been previously assigned to the activity.

Start configured and users all previously run in this task.

By choosing this option, you ensure that both the currently configured users, as well as any users who were previously assigned the task, are assigned the task.

Start only users that previously completed this task

This option will assign the task only to users who completed the task when it was previously run for this instance. Those users will be re-assigned the task irrespective of whoever is currently configured for task assignment in the Workflow definition.

Start from last completed user

If multiple users are assigned to the activity instance, this option will re-assign the activity to the last user who completed it when it was initially run.

Start users that did not complete previously

If multiple users are assigned to the activity instance, this option will assign the task to users who did not previously complete it. For instance, if the activity uses a round- robin assignment, the activity will be assigned to one of the users who were not assigned it on the initial run.

Restart all users when

This option enabled you to define a condition, or set of conditions under which all users in this task will be reassigned.

After a user completes this task

This option determines how a user's tasks are displayed when a user is assigned two sequential tasks in a process. The default in Process Director is to automatically show the user's next task if it is in the current process.

For example, if a user completes a task in an eForm, and is also assigned the next task in the sequence, once the user clicks the OK or other task completion button on the eForm, the eForm will not close, but will simply redisplay itself to allow the user to complete the next task in the sequence. For various reasons, you may wish

to override this behavior, in which case the eForm will close once the first task has been completed, and the user will have to re-open the eForm to complete the next task in the sequence.

You have the following options for configuring the behavior of Process Director:



Automatically show user's next task if it is in this process

This is the default behavior, and will automatically redisplay the eForm once the user completes the first task in the sequence.

Automatically show user's next task if it is for this step in a different process

This selection will automatically show the user's next task if the user is assigned a task in another process. For instance, if the current task starts a subprocess, and the user is assigned a task in the subprocess, the subprocess task will automatically be displayed.

Do not show the user's next task

Once a user completes the task, the eForm will close, and the user must reopen the eForm from the task list to begin performing the next task.

Re-authenticate users

This indicates that the participants must re-enter their User ID and password when attempting to complete their task. This is provided for regulatory compliance when an electronic signature is required for non- repudiation. This feature is not available for “External User” authentication.

Prompt for Signature Comments

This indicates that the participants will receive a prompt to provide signature comments when the task is completed. The prompt will appear as a dialog box when the user attempts to complete the task in the eForm without providing signature comments.

Allow task to be completed from email

Checking this box will allow users to complete a task by responding to the email notification sent by the user step.

Assign users to this task

This option enables you to select how wish to assign a task when multiple users are associated with the same task. You have the following options:



All in parallel

All users will be assigned the task at the same time, and will complete their actions at the same time as the other users.

All in series

Each user will be assigned the task individually, and each user must complete the assigned action before the task is assigned to the next user. The process will continue until all users have completed their actions.

One (Round Robin)

Only one user will be assigned the task each time an instance of the timeline is run. Each time an instance is run, a different user will be assigned the task until all users have been assigned an instance of the process. This will divide the assignments equally among all assigned users.

One (fewest tasks in this process)

Only one user will be assigned the task each time an instance of the timeline is run. Process Director will assign the task to the user who has the fewest number of active tasks pending in this process. This method assigns the task to the user who has the smallest workload in this process.

One (fewest tasks overall)

Only one user will be assigned the task each time an instance of the timeline is run. Process Director will assign the task to the user who has the fewest number of active tasks in their task list. This method assigns the task to the user who has the smallest overall workload.

Enable email invitations

By checking this box, a user will be able to invite another user to a task be forwarding the notification email to him. The receiver of the forwarded email will then be able to follow a link and accept or decline the invitation.

Require at least one user to be assigned

Depending on how the task assignment is configured, it's possible that no users will be assigned to the task. For instance, if a task restarts after all users have completed their assignment, and the assignment is set to "Start users that did not complete previously" there will be no available user to which the task can be re- assigned. Checking this option will assign the task to one of the previously completed users.

Assign task to first user to accept

This satisfies a scenario in which multiple users are configured for the task, but only one user is required to complete the task. This option will notify all of the step users that a task is pending, and then assign the task to the first user who accepts it.


This field contains an optional color of this step. This can be used by the workflow builder to document help visualize the workflow process.

Decision Task

The Decision Step is used to take a single branch coming out of this step. Assign conditions on the actual branches (use right-click Properties on the actual branches). Only a single branch can be taken. You can designate a single branch to be the default if (Default Branch property of the branch) the conditions of multiple branches could evaluate to true.


eForm Actions

The eForm Options task allows the workflow package to control which eForm will be the default when multiple forms are contained within the workflow and allows new forms to be attached.


Parallel Tasks

This allows you to run your steps in parallel. The Parallel Task Step will start all branches coming out of this step at once. You can optionally add conditions to any branches. The Wait step can be used to wait for all parallel branches to complete.




The Process step requires that a Workflow or Process Timeline definition be configured. The configured process will be started as a subprocess (child process) of the main (parent) Workflow. A subprocess can consist of a Workflow or a Process Timeline. You may copy objects from the parent process to the child process and vice versa.

When a subprocess contains an End Process step, it will return the name of the End Process step as a result for the parent Process activity. Process Timelines and Workflows use the End Process function differently, so the results can be slightly different depending on the type of subprocess that is called by the Process step.



In the example above, the workflow End Process step is named completed. If this Workflow runs as a subprocess, then, when the process reaches this step and completes, the name "Complete" will be passed to the parent workflow as the result of the Process step that started the sub-process.

Workflows do NOT automatically end when an End process step is reached. Workflows end when all of the required steps in a Workflow have completed. This enables you to have two Workflow paths running concurrently, or in parallel, each of which may have its own End Process step. If a Workflow contains two parallel paths that each have a different End Process step, then, when the subprocess completes, it will return a comma-separated string containing the names of BOTH end process steps. In the parent Workflow, the returned string will then be set as the result of the Process step that started the subprocess.



Unlike the End Process step in the Workflow, the End Process activity in a Process Timeline stops the running of the Process Timeline immediately. As such, the End process activity can only run once in a Process Timeline. So, if you have parallel activities running in a Process Timeline, all of the parallel steps must complete before the End Process activity is reached. Process Timelines with multiple End Process activities will need to have conditions set on each End Process activity to ensure that only one of the End Process Activities runs. When the subprocess completes, the name of the End Process activity that was run will be returned to the parent process as the result of the Process step that started the subprocess.


This task type is only for documenting the workflow. It allows text to be entered that can be used to describe the workflow process.



The Script task supports the ability to call custom script functions. For more information on the custom scripts refer to the Scripting section of this guide.


Meta Data

The purpose of this task is to assign Meta Data to the workflow objects. The Meta Data is extracted from the default form instance, and can be applied to all workflow objects, or to objects in a specific group.



This task will wait for certain conditions before completing (e.g. Parallel Tasks to complete, Sub-Workflows to complete, etc.). This can also be used for workflow synchronization to synchronize events between different processes.


For the wait step to be satisfied these conditions must be true:

If Wait for Parallel Steps to Complete is checked, all parallel tasks complete.

If Wait for Sub Processes to Complete is checked, all child sub-processes (or a specific sub-process) must be complete.

If Wait for event string to be posted is checked it will wait until that event is posted (from an external source or process).
The Stop Waiting When Any Branch Condition Is Met is checked, and the condition on any branch leaving the wait task is satisfied (note: if no conditions are specified on the branch, this will cause the wait task to complete immediately).
If the Set maximum date to wait from form field occurs before the wait event is satisfied the step will be cancelled and it will automatically advance to the next step in the workflow.
If the time the step has waited exceeded the result of the value specified in the Set maximum date to wait from system variable field, the step will be cancelled and the Workflow will automatically advance to the next step.

Workflow Package

When a workflow process is started, a Workflow Package is created. This is what is routed to the participants of the workflow. The Workflow Package contains the routing slip, the workflow objects (documents, eForms, etc.), optional references, and administrative controls. The Workflow Package can be viewed by authorized users for running and completed workflows.

Routing Slip

Authorized users have access to the routing slip in the Workflow Package by clicking on the Workflow Package Tab. This page displays a routing slip that shows the progress of the workflow process. It displays all users that are participating in this workflow and how far it has progressed in the routing process, including all iterations of a step.


This routing slip is very similar to the routing slip control that is displayed on eForms.

Signature Comments

Administrators can choose to require and display comments on the routing slip. Checking the “Prompt for Signature Comments” checkbox in the Advanced Options tab of a User control will automatically put a Signature Comments control at the bottom of the eForm for users completing that task.


Simply checking this checkbox will not require that the user enter comments, it will only prompt them to. To require that the user enter comments, check the “Require Signature Comments” checkbox in the Options tab of Branch settings. This way, you can configure it such that users only need enter comments when one branch is chosen and not another.


You can also prompt users to enter signature comments in a Process Timeline task. See the Process Timeline section for instructions.

Graphical Administration

Only authorized users will see this button displayed. The user must have Modify permission for the running workflow or have Modify Children permission for the workflow definition. The Administration button in the Workflow Package allows users to modify the running workflow. From this screen, authorized users can change the running workflow by adding users to a step, removing them from a step, or jumping to a new step.


Administering Tasks

From the Graphical Administration screen, you can double-click on a task to open the administration screen for that task.


You have a number of options to choose when administering a task.



Cancel Step

Cancels this step in the workflow.

Restart Step

Restarts this step in the workflow. User, Wait, Custom Task, or Script steps may all be restarted.

Cancel Workflow

Cancels the entire running workflow instance.

Add User(s)

Adds additional users to the workflow step.

Add Me to This Task

Adds you to the workflow step as a participant.

Cancel User

Cancels the user's participation in the task.

Complete User Task

Sets the user's task as complete.

Remove User

Remove the user from the task.

Reassign User

Assign a different user to the task.

Workflow Items

The Workflow Items page is what is presented to users that are participating in a workflow step. This page displays all of the objects being routed in this workflow (e.g. documents, eForms, etc.). A Workflow Package can contain multiple objects of any type. If the eForm has an attach button, users in that step will be able to add objects to the Workflow Package. Each new object added is added to the Workflow Items page. If a user has Delete permission to the running workflow they will be able to remove objects from the workflow package.


Related Workflows

This page in the Workflow Package will only appear if the workflow process is related to any other workflow processes. If this workflow is a parent or child process of another workflow then the Related Workflows button is automatically displayed. This displays the relationship between the workflows allowing users to click on the different workflow entries and view the status (i.e. Workflow Package) for each of the other workflows.

Workflows in the Content List

Workflow definitions are stored in the content list just like any other object in the database. When a workflow is started, an entry will be created under the workflow definition in the Content List as a child object. The entry will remain there even after the workflow has completed. To view the running and completed workflows for a workflow definition, users can click on the “Active Workflows” or Complete Workflows” icons next to the workflow definition name in the content list.


Viewing Running and Completed Workflows

If users have View Children permission to the workflow definition, they will automatically be given View permission to any running and completed workflows for that definition. The running and completed workflows are displayed in the content list swing status, what step is running and the user that initiated the workflow.

Users can view the Workflow Package for any of the running or completed workflows by clicking on the name or the icon in the content list. To view the objects that are part of a Workflow Package, click on the icon ( for the appropriate workflow name.


Running and completed workflows can also be made available to users through a Knowledge View. For example, if users have a need to see only certain types of running workflows, a Knowledge View filter can show a list of the workflows making the actual location of them in the content list transparent.

Attaching New Workflow Objects

A running workflow can allow users to add new objects (e.g. documents, eForms). If a user has an attach button on an eForm they will be able to add new objects to the running workflow.


When a new document is added under the Workflow Package it will only be contained under the workflow. The document will not exist anywhere else in the Content List.

When a reference (e.g. shortcut) to an existing object in the database is added, only a reference to the object will be created in the workflow. A reference, or shortcut, is a symbolic link to the original object. Any changes made to the reference will also update the object it is pointing to, except in the case of an eForm. If a reference to an eForm is added to the running workflow, an instance of the eForm will be created and placed under the Workflow Items button.

Automatic Workflows for Folders

The Process Director workflow engine supports the ability to automatically start workflows for certain document events within a folder. Automatic workflow definitions can be specified for any folder. A workflow definition can be associated with one of the following document actions:

  • When a new document is added to a folder;
  • When a document in a folder is updated and checked in;
  • When a document is moved into a folder.

If one of these conditions is met, the appropriate workflow will automatically be started against that document.

To set workflows to start automatically, click on the “properties” icon for the folder to open the folder's properties screen.


Use the Pick List [. . .] buttons to select a workflow from the content list that you want to start under the given conditions.

Running Workflows

A workflow can be started by selecting one or more objects in the Content List and choosing the Start Workflow link. This will display a popup with a list of workflow definitions the user has permission to start. Changes to the workflow definition will affect all running workflows.

Task Lists (To Do Lists)

Task lists are fundamental to workflow management systems. The Process Director workflow engine supports an integrated Task List that provides each user with a list of their assigned tasks, according to priority and due date. As a user completes an assigned task, the item is automatically removed from their Task List.

Tasks List Knowledge Views with a “Complete Task” column allow the user to complete the task from the task list. A column will appear in the task list with icons representing every option the user can choose. Clicking the icon will complete the user’s task.

Permissions and Running Workflows

A running workflow will temporarily override the permissions for any object (document, eForm, etc.) contained within it, giving the user the necessary access to perform the requested task. When users are assigned to a workflow task, they will automatically be given Modify permission to the objects until their task is completed. This prevents the object permissions from effecting running workflows.

Advanced eForm Options in the Workflow Package

When an eForm is attached to a workflow (via the eForm Actions) it creates a new form data instance in the workflow package. The workflow package may contain multiple forms attached to it. When using multiple forms in a workflow package, you can control which form is the default that will be displayed to the user when they click on the entry in their task list or their email notification.

In Process Director, the eForm is the viewer which controls how information is displayed to the user and the form instance contains the actual form data. This means that you can use different eForms to view the same form data. This is controlled through the workflow processing, allowing you to present a user with a different eForm, but still have it associated with and displaying the same form instance data.

Choosing the Current Form Instance

When multiple form instances are attached to a workflow package, you can select the instance that should be used as the current or default form instance for the workflow. This is performed in the eForm Actions workflow task. If a current form instance is not set using this task, the first form instance that was attached to the workflow will remain the current form instance. In the eForm Actions task, you can choose the default form instance by selecting the actual eForm Definition that was used to create or view the form data and check the “Set this as the default eForm Instance for the workflow” box. The running workflow will determine the appropriate form instance to use based on the “Set this as the default eForm Instance for the workflow Form Instance” field below.


Running a Workflow from a URL

Workflows can be run manually, or scheduled to perform an automatic actions. To schedule these Workflows, a web page (a Web Service web page) is executed to run a specific Workflow definition.

Ensure you have enabled Web Services on the Installation Settings page. You can optionally enable security restrictions and authentication. If you pass credentials on the URL, you will need to set fWebServiceAllowCredentialsURL to true in the custom vars file.

Manual Workflow

Execute the following URL from a browser on the server that has Process Director: http://localhost/services/wsWorkflow...sword=PASSWORD The wsWorkflow.asmx command can take the following parameters on the QueryString URL:

  • wfid: The WFID of the Workflow Definition to run;
  • userid: A Process Director user ID with permission to run the Workflow Definition;
  • password: A Process Director password with permission to run the Workflow Definition;

Scheduled Workflow

You may want to automatically schedule the Workflow to run at regular intervals (for example, every night at midnight). To do this, use the bputil.exe utility. This utility enables you to schedule and test commands executed on a regular basis.

Do not schedule IEXPLORE.EXE because the web browser will never close. Rather, use the bputil.exe command to run the web page. For example, enter this command in the “Run” dialog box to schedule the synchronization:

"PATH\bputil.exe" SU http://localhost/services/wsWorkflow...rid=USERID&password=PASSWORD

(Where PATH is the installation directory for Process Director, e.g. c:\Program Files\BP Logix\Process Director\). Enter the appropriate credentials in the Windows Scheduler when prompted. Use the “Schedule” tab to set the times to run the command. Consult the Microsoft help for more information on this utility.

Process Timelines

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 an eForm 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. Process Timeline enables organizations to build robust, executable process models within Process Director. Business users design Process Timelines by answering two questions as they add each step to the process:

  • What conditions must be met before this step can begin?
  • How long will this step take to complete?

We refer to these, respectively, as the dependence and duration questions. Each activity will begin as soon as its prerequisites, if any, are complete. 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 cannot 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 three tasks, or activities. The Timeline column of the Process Timeline shows the number of days planned for each activity. Initial Approval is scheduled to take three workdays, Finance Approval is expected to take two workdays, and the Submitter's Notification will take 0 workdays, as it is an automated process that will be performed by Process Director. The Finance Approval activity is dependent on the Initial Approval. The Submitter's Notification, in turn, is dependent on Finance Approval.


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.


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.




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 does not 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 dependence: 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.


Properties: Click this icon to open the activity's properties on the Start When tab.

The properties for each activity are presented in a tabbed interface. Each tab groups similar properties together.




This tab enables the user to select the Activity Type, such as a User, Custom Task, eForm 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 is not completed by the due date.


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.

Creating Process Timeline Definitions

Process Timeline Definitions can be created and modified by the business users. Use the Content List entry in the Process Director navigation bar to view the content list screen. You must have Modify permission in the folder you are viewing to be able to create a new Process Timeline Definition. Use the Create New menu item and select Process Timeline Definition from the list.


Process Timeline Definitions can be stored anywhere in the content list, under any folder structure.

Process Timeline Options

To configure the Process Timeline Definition settings, click on the Options icon when viewing the Process Timeline Definition. This will display a dialog that allows the Process Timeline options to be set.


Process Timeline Name and Description

The Process Timeline Definition name and description are important because this is what a user will see when selecting a Process Timeline to run. The description should describe why and when this Process Timeline Definition should be run.

Copy Objects in Process Timeline Package to Parent

If checked, this option will copy objects in this Process Timeline package to the package’s parent. You can optionally limit the objects copied by group. The parent process may be either a Workflow or a Process Timeline.

Copy Objects from Parent Process to this Process Timeline

If checked, this option will copy objects from this Process Timeline’s parent process to this Process Timeline. You can optionally limit the objects copied by group. The parent process may be either a Workflow or a Process Timeline.


The Process Timeline priority is used to show participants the importance. The higher priority items are displayed first in a user’s Task List. The Process Timeline priority can be overridden by the user that is starting the Process Timeline.

After a user submits a form which runs this process

In some cases, a user may be assigned to two or more activities in a row. The default behavior for Process Director is to immediately display the eForm to the user to perform the second task once the first task is completed. This may be confusing, as the user generally expects the eForm to close when a task is completed. This property enables you to change the default behavior so that, if a user is assigned to two activities in a row, the eForm will not immediately reload to complete the second task. To perform the second task, the user will have to manually re-open the form from the task list.

Show Columns

This allows you to display the Index, Activity, Participants, and/or the Process Timeline columns of the Process Timeline Definition.

Process Timeline Icon

A custom icon can also be configured for this Process Timeline Definition. This icon will be displayed for all running Process Timelines for this definition (e.g. task list, Content List, Knowledge View, etc.). To change the icon used for this Process Timeline Definition, click on the image icon.

Instantiated Name

This field contains an optional name that should be used when a Process Timeline is started (i.e. instantiated). The default name of a running Process Timeline is the same name as the Process Timeline Definition. This name can contain system variables using the {sysvar} tag. This allows the running Process Timeline names to contain more meaningful information (e.g. “PR Review – started by {CURR_USER}). The running Process Timeline name is re-evaluated after each Process Timeline activity completes allowing variable data (e.g. eForms field values) to be used to construct the name. Refer to the section named System Variables in this document for more information.

eForm for Process Timeline

You can optionally link a Process Timeline to a specific eForm definition in the Content List. When this is configured you can choose a form field from a dropdown list of all fields in that form instead of choosing a form then a form field.

Default Email Template in this Process Timeline

This is an optional default email template to use when sending email notifications to users in an activity. If an email template is not specified in an activity, this default email template will be used. If no default email template is assigned, the system default email template will be used that was shipped with Process Director. For more information on email templates refer to the section named Using Email Templates in this document. Email Templates are stored in the Content List as an eForm uploaded as an Email Template eForm.

Display Process Timeline in

This option allows you to display the Process Timeline in minutes, hours, days or weeks. You may also specify the default activity duration.

  • Was this article helpful?