Skip to content

Friday Feature – Workflow Overview

Share article

Now, I have written a few Friday Features about workflows in Escape Online (see below) but I have never really explained how workflows are setup and how they work. Let’s start that process today, and spend the next six weeks covering such topics as document types, leveling, requiring all approvers to approve or not, notifications in general and notifying users specifically. In other words, let’s talk workflows!

First things first. We really need to define what the term workflow means in Escape Online. In a nutshell, workflows are used to define the progression of a document through its life cycle, defining approvals and notifications sent to users when certain events occur.

Oh, now that was tricky. I introduced two more terms: document and event. For Escape Online, a “document” is a record that is processed, generally with approvals along the way. This means that the term “document” refers to requisitions, payments, HRAs (human resource authorizations), journal entries and work orders. (Next week, we will explore document types in depth, like which types support workflow definitions and what can you do with them.)

An “event” is “anything that triggers a history record.” This means that submitting a document, changing a status, even changing a field in a document can be an event.

Let’s look at an example from one of our customers.

Workflow Overview

Workflow Overview

For their vendor requisitions, they have specified that certain things should happen when an event occurs. So, using our definition of event above, when a requisition (document type) is submitted (an event), then it will be electronically routed for approvals to a site user (principal), a program manager, the assistant supervisor and the purchasing agent.

Then, when the requisition is approved, Escape Online will assign a buyer for the items in the requisition and it will send a notification to the budget director.

If someone changes the requisition, resulting in a change order, then all of the people in the purchasing group get a notification.

If someone denies the requisition, then the person who originated the document (the requisitioner) will be notified and so will all of the people who gave their approval.

Finally, when the requisition is complete, the requisitioner gets a notification. The requisitioner also gets a notification if the requisition is cancelled.

Cool! It seems pretty clear that workflows can engage the intricacies of a document winding its way from Open to Complete.