Best Practices

Best Practices

Below are a list of Best Practices associated with the utilization of the HighOrbit Workflow Automation System.  We have conveniently split them into the following categories…

  1. Your Trial Account – What to know before you get started
  2. The Basics – What every workflow should include
  3. Process & Workflow Design – Other considerations to include
  4. Enhance the User Experience
  5. A Bit More Technical

Your Trial Account – What to know before you get started

Though it is not necessary, it is best to spend a minimal amount of time documenting your process/workflow before you start to design.  The complexity of the process may dictate the level of detail.  However, there are essentially only three basic pieces of information needed…

  • List of Data Elements
  • List of Process Participants
  • Workflow Description
Data Elements

Generally, these are the fields on the forms, but they may also include data captured by the process for other purposes (i.e. performance reporting).  Simply list the names of the data elements and their type.  For example:

  • Request Date: Date Type
  • Requested By: Assignment Type
  • Request ID: Numeric Type
  • Company Name: String Type
  • Request Justification: Memo Type

A more detailed list could include which task/form the data displays at and whether they required valid entry chosen from a dropdown, radio button, or checklist.


Listing participants is a two step procedure.  The first step is to list the participant names and whether they are a HighOrbit user or not.  Non HighOrbit users may initiate a process via the WebAPI, but cannot be assigned tasks.  Their participation within any given process instance is limited to email actions, such as status notifications.  The second step is to list the “roles” used within the process and which participants are in that role.  By listing the roles you are defining what groups/roles will need to be created and which users to place in that role; essentially documenting the assignment for each task within the workflow design.

Workflow Description

It does not matter what you use to document the workflow.  It can be a Visio flowchart, swim lanes, or just typed into Word.  You can even hand write it on a legal pad.  The application used is not important.  The workflow description is what truly matters.

At a minimum, the workflow description should include the following items:

  • How the process is started and by which participants
  • The tasks titles and assignee (user/role)
  • Task instructions
  • Task actions (i.e. approve, reject, return to requester)
  • Task due date/time and whether and how overdue tasks are escalated
  • Routing description associated with the workflow, including any business rules (i.e. PO over 5K routes to CFO)

As always, feel free to contact your Process Specialist with any questions.  HighOrbit also offers professional services and can document your processes either remotely or on-site.


Trial Accounts!  If you have not done so, we want to remind you of your assigned Process Specialist.  They are here to assist in any fashion and their services are available at no cost during the trial period.  We highly recommend and urge you to take advantage of these free services, which can include…

  1. Analysis of your Workflow Automation requirements to determine whether the HighOrbitBPM system is a valid solution.
  2. Collaborative process design whether it takes 1 or a series of on-line meetings.
  3. Process review and best practices analysis of any workflow designed.
  4. Troubleshooting or Q&A sessions.
  5. Testing.
  6. Also, if you have a process documented, you can even have your Process Specialist design and deploy it.  Upon completion they will contact you to schedule an on-line meeting for your review and approval.


A common mistake of first time users of the Process Designer is to leave little space between design actions (Icons). This is usually due to an intent to view as much of their design as possible on a single screen/view. Certainly understandable, but it can lead to a variety of problems. There are two main issues that can result in poor spacing or a “cramped” design. First, the graphic display within the search details is rendered from your design. A cramped design makes it difficult to render; causing text and design actions to overlay each other. Second, future changes to the design (especially design action additions) can be very difficult and time consuming. A simple calculate design action addition at the beginning of a process may require moving all subsequent design actions to make room. We highly recommend you leave plenty of space at the beginning of the design and between each design action.

HighOrbit Best Pratices: Recommended Design Spacing

Example: Proper Spacing of Workflow Design

The Basics – What every workflow should include

Although the system automatically captures a process initiator (user that starts the process), a standard best practice is to capture the initiator in a separate Assignment type data element. One reason to do so, is related to tasks list views physically displaying an assigned task “assigned to” as “initiator” instead of the user’s name. Using the assignment data element allows a task’s “assign to” to display the user’s name not only in a task list, but also on any task/form. This practice also makes possible performance reporting much simpler, since the field is now stored along with all process instance data.

HighOrbit Best Practices: Capture Process Initiator

Example: Capture the Process Initiator


First, create an Assignment type data element giving it a descriptive name (i.e. Requestor). In the process design, then use a Calculate action to set the Requester to the Initiator. This is accomplished by using the expression initiatorId().




NOTE:  This best practice has become less critical, since the system was enhanced to capture this detail in process history and the performance metric reports were released in mid 2013.  It is still of value for clients that wish to export this type of date to an external datasource for their own reporting needs.

Although the system transaction log tracks the start and completion date/time of every process instance, that data is not readily readable or easy to access for reporting needs.  For that reason, we recommend you capture the the Start date, Completion Date and Process Duration within your process design. All three of these items can be captured using Calculate actions and simple expressions.

The first step is to create the necessary data elements.  You will need two Date type data elements (i.e. Start Date & Completion Date).  You will also need one Numeric type data element (i.e. Process Duration).  Use a Calculate action to set the Start Date at the beginning of your process and another Calculate action at the end of the process to set the Completion Date.  Both can be set using the now() expression. After the Completion Date Calculate action, place another Calculate action to set the Process Duration.  The expression to calculate the duration would be subtracting one date type data element from another.  In our example here, it would look like %completion_date% – %start-date% and would return a number.

Detailed information regarding these and all other standard HighOrbitBPM expressions can be found in the Technical Information page of our online Resource Center.


The data elements “Status” and “Priority” are system assigned.  You will noticed they are automatically generated when you create a new process design.  When used within a process, they will automatically display in the Status & Priority fields of either the Single or Multi-Line Line Full Tasks Lists.   This is very helpful in determining the status or priority of a individual process instance by simply viewing the task list.  It eliminates the need to search and drill down into the process instance details to determine the same information.

HighOrbit Best Pratices: Task Dashboard Status & Priority

Example: Utilizing Status & Priority

HighOrbit Best Pratices: Setting Status with Calculate Actions

Example: Setting Status & Priority


The Priority of a process instance is generally determined by user input.  In contrast, Status is generally determined by action buttons (i.e. Approved or Rejected) or the physical direction of the workflow and should be set within the process design.  This is accomplished by using a Calculate design action to “set” the status at given points within the workflow.  You can “set” the status within the properties of the Calculate action.



It is necessary to use process instance data within a task’s subject.  This is a must use practice and would be the only way to differentiate one process instance from another. Without it, every task of a specific process or workflow would appear the same to the users.  The trick is to use process instance data that is unique.  An example may be an ID (i.e. Requisition #, Support Ticket #), a brief description, or the requesters name.  It can really be any data that helps distinguish one process instance from another.  It is important to note that the Task Subject can consist of more than one data element plus any literal content entered into the subject field.  Also, each task within a process can have different subject content.

HighOrbit Best Pratices: Task Subject in Task Dashboard

Example: Using Process Data in your Task Subject

HighOrbit Best Pratices: Using Process Data in Task Subject

Example: Subject Configuration in Task/Form Properties



To configure a task’s subject; In an open process in the Process designer double-click on the task/form to enter its properties.  You will see the subject field and it’s wizard button.   Click on the wizard button, which will open a common expression window where you can enter your subject using data elements of your process.






HighOrbit Best Pratices: Using Task Colors in Task Dashboard

Example: Task Colors

When is comes to utilizing colors for tasks two main schools of thought exist.  One is to use the same color for all tasks of of process.  For example, all New Customer process tasks are light blue while all Requisition Request process tasks are a dark grey.  The alternative is to make task colors department or role specific.  For example, no matter which process….any Accounting type task is green while all IT related tasks are yellow.  In either case users will automatically begin to associate task colors with processes and/or role assignments.


HighOrbit Best Pratices: Setting Task & Text Colors in Task Properties

Example: Setting Task Color


Another benefit is task views of multiple processes or roles will display their distinct colors, making a task list view easier to read.

To set a task’s color, choose it from the color wizard palette within the task/form properties.   If you choose the darker Task colors, make sure to use a light Text color since Text defaults to black. Dark Task colors with black Text is difficult to read.



This is one of the most important steps when creating the workflow design and the most common to be forgotten.  Process properties determine the Instance Description, Process Data Expiration (default setting is 1 year) and a variety of security settings.  Essentially, the Process Properties determine how long data is maintained, which users can run searches and what process information a user can view. Without proper configuration, searches that return multiple instances would be impossible to identify, process data would be automatically purged after 1 year and security access to process information is likely to be inaccurate.  Configuration is based upon your specific needs and subject to change from process to process.  It would be difficult to describe all the possibilities here, since the correct settings are unique to your implementation, processes, and users.

HighOrbit Best Pratices: Configuring Process Properties

Process Properties


You can read more about setting process properties in the Process Designer Guide  (found under the Help menu).  However, it would be best to simply contact your Process Specialist.  They can review your requirements and make the proper recommendation.  You can view the process properties dialog box by right-clicking in any white space of an open process design and choosing properties.





The standard calendar included with the system does not contain “non-working” days and is set as 365 days a year and 24 hours per day. It is the default calendar for any task due date/time and delay related expressions. As you can imagine, this could cause tasks to become overdue at date/times outside standard business days/hours. It can also result in a variety of workflow delays that appear logically correct, but do not provide the desired time line results.  We can create a calendar based on your standard work week and hours of operation. This would ensure that due dates based on this calendar would always fall within your standard business hours.

To request a company calendar, call or email your Process Specialist with your standard work week and business hours of operation (i.e. M-F, 9:00-17:00).  Be sure to include your preferred time zone.  Your Company calendar will include all standard holidays.  If you have a Cloud-based account, we will create the calendar and add it to your account.  On ON-premise or “Self-Hosted” systems, we will require system access in order to create the calendar. If you prefer to create the calendar yourself, detailed instructions can be provided.

Once the company calendar is available, it can be utilized for Task Due Dates and Delay Action related expressions. Task with existing process/workflow designs will need to be edited to use the new calendar.


An external datasource is not necessary, but it can be quite beneficial.  That is especially true for Cloud-based  accounts on shared servers, since for obvious security reasons no direct access to system tables are provided.  Self-Hosted implementations do have direct table access (schema is provided), but it should be noted that the HighOrbit table structure is very complex and optimized for Business Process Management and Workflow Automation.  Storing process data in an external table would simplify accessibility.

Whether cloud-based or on-premise, an external datasource can be utilized for dynamically populating data elements (drop-down, check box, radio buttons, or auto-suggest). This is very useful for controlling and validating data entry while enhancing the user experience.  Data entry can also be minimized by retrieving associated data from an external table.  For example, the user may choose a customer account number from a drop-down.  The associated table data (i.e. address, contact info, etc…) can then be retrieved via a DB Lookup design action.  Writing pertinent process data into an external table can provide easier accessibility, especially for reporting. The standard Update DB design action writes process data to an external table.

Hosted accounts can lease a secured instance of MySQL from HighOrbit for a low monthly fee.  Please contact your assigned Process Specialist to discuss your specific database integration needs.

Process & Workflow Design – Other considerations to include

There a two ways to require a users data entry on a standard HighOrbit form.


HighOrbit Best Pratices: Task Required Data Entry

Setting Required Data Entry


This is maintained within the properties of a task/form design action under the Data Elements tab.  By simply checking the Required check-box of a data element, submission of the form will be prohibited unless that field is completed.  Required fields on the form are displayed in red as a visual signal to the user.

Please note that required entry will be necessary for ALL action buttons of that task and therefore is not considered a best practice for Tasks with multiple action button.

Required by Action Button:

HighOrbit Best Pratices: Required by Action Button Properties

Setting Required Data by Action Button


This is the preferred practice, especially when you have a task with multiple action buttons that  each have a unique set of required data entry?  To configure Required by Action Button, right-click on the Task/Form design action and choose Action Buttons. The Task Action dialog box will display and will list the action button titles of that Task/Form.


HighOrbit Best Pratices: Data Required By Action Button


Highlight the action button name and click the Properties button.  From here you can select the required data elements for this button.


When completed, click Close.  Make sure you save your process and changes.  Data elements required by action button do not display in red on the form.  However, the user will get an error, if they attempt to submit the form without completing the required fields.





Each Task/Form has both an Action and Overdue design option.  The Action option is required and you must have at least one defined action.  Overdue is optional.  It is not necessary to design a workflow (escalation) associated with an overdue task.

HighOrbit Best Pratices: Overdue Task Due Date Turns Red

Visual Indication Task is Overdue


If no overdue workflow is designed, by default the due date of an overdue task will display as red in the Task List Dashboard.



If a specific task of your process does require an overdue escalation, there are no workflow design limitations.  You can design nearly any type of escalation you feel necessary.  They can be as passive or aggressive as required.  Whatever you design, it will automatically execute the moment the task due date/time is past. Two of the most common escalation design are…

HighOrbit Best Pratices: Overdue Task Escalation - Email Notification

Overdue Task – Email Reminder

1. Email Reminder:  Use an Email design action to notify the assignee to complete the overdue task.  You can copy process participants.  The most common practice is to copy the Task assignee’s superior on the overdue email notification.





HighOrbit Best Pratices: Overdue Task Escalation - Assign to Supervisor

Overdue Task – Escalation

2. Task Escalation:  Escalate the overdue task to a different task & assignee.  In many cases, this could be a department head or even the original assignee’s immediate supervisor.  It can also be escalated to a task with the same assignee, but with a lesser due date/time.




Please contact your Process Specialist to discuss any unique task escalation needs.  They can provide design guidance.


There are numerous reason to capture the user that physically completes a task assigned to a group.  The two most obvious reasons are for tracking personnel performance or for subsequent task assignment.  It also comes in handy when researching historical inquiries regarding specific process instances.

To help explain this best practice we will use the following example.  A task is assigned to the “IT Group”, which has four members. By default, the system will alert all four members of a task assigned to the IT Group. You want to know which “IT Technician” took ownership and completed the task.

Capturing the user is handled by using a Calculate action with the LastTaskCompletedBy() expression.

HighOrbit Best Pratices: Capturing User That Completes a Group Assigned Task

Example: Capture User that Completes a Group Task


The first step is to create an Assignment data element for capturing the user that completes the group task.  In our example we have created an assignment data element titled IT Technician.  In your workflow design, place a Calculate action (one for each task action button) that sets your assignment data element with the LastTaskCompletedBy() expression.




Only use a Numeric type data element for items that truly represent numbers, such as prices, quantity, or numbers that might be calculated. Zip codes, part numbers, phone numbers, SSN, etc. are really just identifiers that should be stored in a String Data element.

Rule of thumb, if it will not be used in a numeric calculation, it should be stored as a string type. String Data Elements give a lot more flexibility in formatting, Validation, searches, etc.


Enhance the User Experience

You will notice data elements are ordered in the same sequence in which they are created.  That default order is how they display in the Process Designer, properties of the Task/Form, and the data element section of a process instance’s search details.  It is likely you prefer a different order.  The ability to re-order a processes data elements either alphabetically or by a user-definable order. A user-definable order can be based on data relations, task/form completion, or any other type of grouping logic. Once the data’s order logic is determined and set, choosing or finding data elements becomes simpler and quicker.

How do I reorder?

In the Process Designer, open any process. Right-Click in the Data Elements section and Choose “Reorder Data Elements”. A dialog box will display. From there you can reorder the entire list of data elements alphabetically. If you prefer a more user-definable order, you can move one of more (ctrl or shift selections) data elements. Highlight the data element(s) and click the To Top, To Bottom, Up, or Down buttons to move them to their desired placement. Click the OK button to save your changes.


Creating custom task list views is a great tool for managing processes, tasks and users. They can provide a quick snapshot of important information. Although views are simple to create, the number and combination of set-up options makes it impossible to provide any detailed instructions in this brief format. However, we do want to convey its general capabilities.

Views have five (5) main configuration options once you create a view description.

  1. Assignment: Create views based on a specific user, group, or the system setting; my subordinates.
  2. Dates: Create views based on create or due dates and whether they are on, before, or after a specified number of days.
  3. Match: Create a view based on a specific process or task title.
  4. Priority: Create a view based on a numeric value associated with priority.
  5. Sorting: Determine the primary, secondary, and tertiary sorting. Sorting options include priority, status, due date, create date, process name, task title, assign to, and assign from.

HighOrbit Best Pratices: Task List Views Page

Preferences Menu


Single or any combination of the options listed above can be used to create a specific view.  The Views page can be found under the Preferences menu. We highly recommend you contact your Process Specialist for guidance.



Important Note: The properties (access security) of a process take precedent with relation to views. A view will only display tasks that the user is defined to have access to.


A Bit More Technical

When using Decision Actions, sometimes it is helpful to combine multiple “if” statements into one expression. This allows you to perform multiple checks (AND / OR scenarios) in one Decision step rather than spreading them out into multiple and similar Decision Actions.

For example, let’s say you want to see if an order amount is greater than $1000, AND the shipping method is FedEx. In this example, the two Data Elements we will reference are called “total_order_amount” and “shipping_method”.

We can combine this check into one expression and put it into a Decision Step. It will follow the Yes direction if both criteria are met, and to the No direction otherwise.

Note that when combining multiple expressions, each single/sub expression must be enclosed in a set of parenthesis, and the entire expression must be in yet another set of parenthesis.

In this example, the expression would be (extra spaces added for clarity):

( ( %total_order_amount% > 1000 ) & ( %shipping_method% = “FedEx”)  )

Additional criteria can be added by enclosing in yet another set of parenthesis.  Let’s say we also want to include that the Shipping State (shipping_state) is not Alaska.  This would be added as follows:

( ( ( %total_order_amount% > 1000 ) & ( %shipping_method% = “FedEx”)  ) & ( %shipping_state% != “AK” ) )

A good rule of thumb to keep in mind is that at each inner set of parenthesis, only one simple expression should be evaluated. Also, the total number of open parenthesis should match exactly the total number of close parenthesis. Our system will start working from the inner expressions, and continue evaluation to the outer sets of expressions.

It helps to build each sub-expression one at a time, and save/validate the expression at each step. Adding one at at time can help you keep track of the number of parenthesis and locations of the expressions.


Though it is unlikely you will ever need a process design file, it is still a best practice to export the design for safe keeping.  This is not for disaster recovery.  HighOrbit servers are configured to respond to any disaster and we assume self-hosted clients have similar disaster recovery plans in place.

For free trial users, there are a couple of reasons to export and save your process files.  If no decision or purchase is eminent, these files can be saved and re-imported at a later date (new trial) for final evaluation.  You are essentially saving your investment in upfront process design work.  If you option for the On-Premise system, the exported design files can be imported once the system is installed in-house.  The import routine also automatically creates any Groups utilized in the process.

Exports during key points during development are another reason.  It provides the option to “go back” to an earlier version in the event the evolution of the design becomes unusable or unnecessarily complex.  It also provides a safeguard if you were to accidentally delete the process.  We know nobody thinks they would delete a process, but it has happened and more than once.  Deleting a process under development is not as catastrophic as deleting a live process, though neither is easily, quickly, or inexpensively recoverable.  Importing the save process file is a quick resolution, especially for designs still in the development stage since there is no associated historical data or live instances.

Copy a Process Design

Quite often and existing design can be used as the base design for another process.  There is no real “copy” process function in HighOrbit. Copies of a process are created through the standard export & import features.

To export a process design file, first open the design in the Process Designer.  Under the File menu, choose Export.  A dialog box will display where you can name, choose the location and save the file.

To import a process design file, under the File menu, choose Import.  A dialog box will appear where you can locate or browse to find the correct file.  The imported file will be placed at the “Processes” root.  From there you can rename and move the file to the desired location.

Contact your assigned Process Specialist, if you need assistance.