Workflow /ˈwərkflō/ (noun)

“the sequence of processes through which a piece of

work passes from initiation to completion” - dictionary.com

4
5
 “Workflow” versus
Workflow.com Building
T he word “workflow” can carry many different degrees of meaning depending on who

AWorkflow
is using it. Just about every software system these days claims they have workflow
because of the way you use that software to get things done. Workflow.com doesn’t just
participate in getting things done - it manages the entire process of work by coordinating
systems and people. Workflow.com is technology that involves people and systems, routed
by rules and published in the cloud.

Workflow.com is designed to allow business analysts to understand and change processes

- without becoming developers. This is done by graphically assembling small, prebuilt
pieces of functionality in a graphical tool. The most common structure resembles a ‘flow
chart diagram’ where the items are assembled in a sequence.

What separates Workflow.com from flow charts or other diagramming tools is that
complete workflows are able to be run - providing real automation in addition to a visual
understanding of the business flow.

Flows can start in a number of ways:

• Schedule. Workflows can run every 5 mins or on first business day of the quarter.
Scheduled workflows can be used to monitor passive systems like email servers or file
systems. Scheduled workflows can also be used for checking on events that ‘do not
happen’.
• Forms. Users can initiate a flow by filling in forms. These forms can be built in the form
designer or any other web technology. Examples of these types of interactions include
starting an approval process, submitting a request, entering data for processing or
uploading a file.
• API. Other systems can trigger workflows by starting calling events or sending a
message through a messaging infrastructure. How a system makes this call be be
done in a number of ways including REST, SOAP, WCF, Messaging Systems, HTTP and
others. For example, configuring Salesforce to trigger a workflow by calling HTTP Url
with JSON data when a new contact is created.

Once started, the workflow engine actively manages the execution of the elements of the
process. Workflows can span a long period of time - being stored off by workflow engine
and later restarted based on user interaction, schedule or other event.
 Examples
of Workflows Workflow Software: Designer, Execution and Content

All businesses run on workflows - and many of them can be automated. Here are some
common examples of some workflows:
What is most often thought of a ‘workflow’ is the design interface because its the ‘face’ of
the process. The workflow designer has a set of tools to create, configure, test and publish
workflows. When a workflow is done it is run in the workflow engine. This engine executes
the flows, manages the storage of workflow state, hosts any user interfaces that steps
produce.

• Design Document Workflow: Many companies have design documents, or contracts
that require multiple authors, editors, or approvers. Routing, gathering comments, and
approval of a document can have specific deadlines at each phase and a clear audit
history. This workflow features an iterative style with comments getting gathered and
resolved.
The bulk of what is delivered in a workflow is in the form of prebuilt steps however, without
executable content (ie, steps) the workflow designer is just a diagramming tool and the
workflow engine has nothing to do.

124
3
• Customer service for returning an order. This workflow is initiated with a customer
request, has interaction to lookup and update the order tracking system.
• Custom Sales Quoting: Gathering and approving a quote for a special service. Multiple
departments are involved in providing input and providing a quote before being routed
to customer for acceptance or rejection. Flow Step Basics
• Managing exceptions to data coming in via a service api. If incorrect data is discovered, Flow steps form up all of the actual functionality of what happens in the workflow process.
it is routed to a supervisor for review and adjustment. Given this, the contents of the step library is the largest determination of what a workflow
engine can do.

While the operation of the step might be complex, it becomes a ‘little black box’ that hides
04 the actual implementation details - making it usable by users of the graphical form builder.

03
Here are some examples of flow steps
Basic Concepts: Flows, Steps, and Paths • Sending an email
01 02
• Posting or getting a file from an FTP service
Flows are the basic structure for process automation. Flows contain executable elements • Iterating through a list of data
called Steps. • Sorting or filtering a list
• Calling a webservice
Steps are business functions, both small and large that represent the activities that need • Fetching or saving data to a database
to be taken to complete a process. The capability of what a flow is able to accomplish is • File operations (reading, saving, etc)
based on which steps are available and selected to be included in a flow. • Showing a form to a user
• Making an assignment to a user
Steps are connected together to describe the sequence of execution that the flow takes. A … and thousands more
Path connects the outcome of a step to another step. A step can have multiple incoming
Paths. Paths are not required to be linear but can loop back to enable recursive operations. In the case of the decisions platform, there are steps that range from the very small grained
(data manipulation, math operations, etc) to elements of a business process (assign task,
make system integration etc).
 Flow Step Data: Input Data and Output Scenarios/Data
To make steps reusable, they must have minimal dependence on other steps - but be
encapsulated so they can be executed in different contexts.
The workflow designer needs information on the data a step needs and produces to allow
users to configure the flow.
A step declares what data (type/name) it needs to get from the flow in order to execute.
This is called ‘Input Data’. For example, if I had a step that added two numbers together, it
would require ‘Number1’ and ‘Number2’ as input data.
A step also declares what its possible outcome scenarios are. In the case of a simple step
like an ‘add step’ the only possible outcome might be to produce a result. More complex
steps might have additional outcomes. For example, a step that gets an approval from a
user might have a different results for ‘approved’ ‘rejected’ and ‘deferred’
Each ‘Outcome Path’ can declare a different set of data that is produced. On ‘rejected’
path, a rejected reason (text) might be provided and on approved, maybe a limit (number)
might be output.
Steps manage to be loosely coupled and reusable because the flow designer allows the
tying together of the data available to the data needed by a step. The workflow designers
‘data mapping’ allows input data to come from values in the flow, be provided by user
configuring the flow, or a number of other sources.
Flow Control
Rules are used to determine which route a workflow takes in a diagram. Any step that has
more than one possible outcome can be thought of as a ‘rule’. A number of single condition
rule steps (example, ‘Text Contains’ or ‘Greater Than’) are included in platform. The Rule
Engine (see our Rule Engine papers on Decisions.com) allows more complex logic.
Branching/Merging
Flows can have parallel tracks of execution where different people/processes and external
systems are involved. An example of this might be multiple groups needing to provide
input into a proposal simultaneously. The breaking of a workflow out into more than one
concurrent work stream is called ‘branching’. The joining of these work streams back
together is called ‘merging’. To mirror real world processing, consideration also must include
multiple levels of branching/merging and canceling execution streams conditionally.
Data Structures
As a flow executes, it consumes or produces data. For instance if a flow is to track Order
- that order can be looked up in a database or other system. That order is a ‘complex type’
with multiple properties (order id, date, customer id, line items, total, etc). These values are
able to be displayed on forms, used in rules or even changed.
Data structures can come from multiple sources including:
• Webservice integration. if a webservice returns an ‘order’ the type will be a data structure
usable by flow.
• database integration. when generating against a database table, view or stored proc -
the resulting data is a data structure available to the flow designer.
• Defined in JSON, XML or XSD. these structures can be imported and data read in or
written to them
• Defined in the SDK
• Defined in the designer. The workflow design technologies include a user interface to
define data.
Data defined in the workflow designers can include complex types, mapping into databases
and/or XML/JSON structures.
 Flow Steps: Async Steps and
Long Running Workflows
Asynchronous flows run for a longer period of time and may involve assignments, user
interactions, waiting on external systems or other longer running operations.
If a process is ‘started’ to be completed at a later point of time – because of its operations,
its an Asynchronous process. While the reason for this might be waiting for a user to
approve or complete an assignment, it also might be a longer running process that is just
data manipulation that might take a while to complete (example: cleaning and processing
a file of 100k transactions).
Synchronous processes return data or ‘answers’ to the caller in the same interaction. These
processes differ little (from an api perspective) to how business rules operate. Data is provided
and data is returned. An example of a synchronous process is providing a rate quote
Flow Steps: Integrations and SDK
Integrations are the mechanism for creating additional flow steps to be used in a flow.
The Decisions Platform provides a large number of steps for integration. These include:
• Steps to manage common data structures such as Excel, Word, PDF, XML, JSON, CSV
• Steps to interact with common protocols such as IMAP, HTTP, FTP, SMTP
• Integrations with some common systems such as Salesforce, EC2 (management), Azure
(management) and Remedy
• Ability to define (in a wizard) integrations to database tables, views and stored
procedures. Supported database technologies include SQL Server, Oracle, MYSQL,
Postgres and any database that supports ODBC
• Integration with REST based services
• Integration with SOAP and WCF based services
• Integration with messaging systems such as RabbitMQ, MSMQ, MQSeries
In addition to this, any .NET method can be registered as a new step.
Additional integrations can be done using the platform SDK that allows new steps and
rules to be created and registered to be used by the designers.
Flow Steps: Tasks and Forms
Showing forms and managing tasks for users is central to human workflow. This is a big
topic and some of the common questions include:
• How is a user assigned to a task? Can I assign a task to a group? Are tasks locked when
one user in a group starts to work on it? What happens when the assigned person is on
vacation?
• When is the task due? Are there other date triggers?
• Can I expire a task? Can I configure what happens after I expire a task?
• Can forms be reused?
• Can forms built in form builder have data sent to it? Can fields be hidden/disabled
dynamically? Can forms have required fields? Is custom validation available? Is data
controls like dropdowns able to be changed out dynamically? Are forms able to be
setup to be resizable?
• What happens when a task is not done?
• How will a user be notified there is something to do?
• Where does the task list live? Can I create targeted lists of tasks by type for different
activities?
• Is task list available via api?
• Can a user respond to multiple tasks at once?
• How can a supervisor track the tasks, who is assigned, time taken, etc?
• Can users complete tasks without ever logging into the system using email?
• Can forms be tailored for mobile and tablet devices?
• Instead of using the form builder, can forms be built in ________ ? (Ruby, PHP, Javascript,
MVC.NET)
• Can tasks be completed via texting (SMS)? Can tasks be completed via Telephony?
While there is explanations to all the above questions, the simple answer is ‘Yes’. A few of
the topics bear some additional detail however.

Flow Steps: Tasks and Forms - Form Technology Choices
Workflow.com features a graphical form builder that allows end business analysts to create
dynamic forms that can be targeted at mobile and tablet devices as well as computer
based browsers. The forms are rendered in HTML5 and are dynamically resizable.
However, with the evolution to more and more tightly scripted user experience paradigms
and evolution of different user experience platforms - there is no either/or choice needed
between ‘I want to use workflow’ and ‘I want the UI to be exactly as specified or built on
____ technology’.
‘External Forms’ can be configured to be used as steps in a flow. The interaction (url to
call, what data needs to be passed, what the results are) needs to be specified. A REST
or SOAP interface is created for external forms to communicate in the running flow. The
choice of technology does not matter as long as it is able to get and send data using the
service based interactions.
Flow Steps: Tasks and Forms - Active and Dynamic Forms
The choice to use the graphical form builder does not imply that the resulting forms are
static and unresponsive. By leveraging the rule and flow engine, forms can be made active
- in the same areas that are often done by programmers:
• Hiding/Showing - Enabling/Disabling Controls. Using the Rule Engine, controls can
adjust visibility or enabling based on user interaction. Example: A user picks ‘other’ and
a text box to supply other is supplied.
• Conditional Required Fields. Every form defines one or more ‘outcomes’ (like ‘ok’ or
‘cancel’). Each data field can be configured to be required, optional or ignored on each
of these outcomes.
• Rule Based Validation. Additional validation is provided by the rule engine. This allows
validation not just if a field has been supplied but also rules to determine if the data is
appropriate or not. A couple examples of this are not allowing the name ‘John Doe’ or
making sure the number entered is able to be supplied by the warehouse (database lookup).
• Calculations/Summary Data. Forms can have data adjusted and calculated as users
interact with data on the form. For instance, if selecting options would change the order
total, that total could be calculated and updated without leaving the form.
• Rule Based Form Transitions. Using rules, a user can be automatically moved to another
form when conditions are met - like when they supply a proper answer to a question, it
will move them on to the next form.
• Adjusting of Pick List Data. A very common paradigm is to adjust the contents of control
(Acceptable answers) based on some database or service lookup. A couple examples
of this include: adjusting a drop down to select city after they have picked a state or
providing a list box of choices based on a user typing in a search term into a text box. A
flow can be used to provide this - using all the integration capability of the flow engine
to get data from databases, make service calls, calculate results, sort, filter etc.
• Auto Filling Data Fields. Using the same mechanism of adjusting pick list data, data can
be supplied to edit fields by having the flow engine provide it interactively.
Flow Steps: Tasks and Forms - Task Management
Forms can be assigned to users - called Tasks or Assignments. A user can get an assignment
either directly assigned to them or indirectly by being a member of a group or having a role
in the system. Users can opt in or out being notified by email when they have work to do.
Assignments have a lifecycle of their own. For instance, assignments can be marked as not
being available until a future point of time (this is an assignment that I want to appear on
January 1st). Dates and behavior can be established for moving an assignment through
a lifecycle of not being done when expected (late, warn) - for instance, after 2 weeks we
want to move the assignment to warn state and send a reminder email.
Users task lists - where they see what needs to be done - are able to be adjusted in the
report designer. This enables tasks to be filtered down subsets of tasks based on type, who
assigned to, dates, assignment state or any number of different data points. These task
lists can be displayed in the workflow portal, embedded in another portal or website or are
accessible via REST or Webservice API’s.
Supervisors also can get overview of task state, assignments, etc. This data can be rolled
up to summary views in graphs and matrix. Supervisors also can work tasks on behalf of
users.
Additional features include:
• Being able to be assigned to ‘non users’ or guests
• Handling of users being able to delegate tasks to other users on a time bound or
permanent basis
 Flow Steps: Tasks and Forms - Email Response Handling
Assignments can be configured to be completed without forms. Email response handling
enables tasks to be worked directly from email - either by clicking a link or responding
to the email itself. Using this functionality, users never even have to login to a system to
approve, reject or provide documents or feedback as required by the flow.
Conclusion
Software development tools can also be used to automate processes. The goals and the
resulting end user experience might be the same. Certainly there are some problems that
are best solved using more traditional software development approaches.

The approach and artifacts are going to be very different - and in most cases the amount
1 of effort taken to create and evolve are going to be different.

2 3 Flow Steps: Flows as Steps Workflow not only provides an optimized configuration timeframe, it also produces artifacts
that are understandable and even changeable by business analysts.

A flow actually may participate in another flow as a Step. Both flows and steps share a
common structural definition - what are the inputs and what are the resulting conditions
that they produce. For instance, a flow might be defined to ‘process a file’ and the results
might either be ‘success’ or ‘here are a list of error conditions’. This flow might be used in
the context of another flow as a single interaction.
The quality of a workflow technology can be seen by how closely it can keep pure to the
paradigm. How ‘black boxed’ are the pieces that are being put together? How much, if
any, scrpting/programming is needed to tie things together? Can non programmers really
understand what is happening? Furthermore, can they actually make changes or build
things? Does that pattern break down when it comes to figuring out what is wrong or the
resulting things have to be tested?

Other Topics

There are a number of other topics related to the flows that are important but beyond the
scope of this basic concept document. Below is a list of some of them.
• Flow Security: Authentication (who is user), Authorizations (what can a user do), Guest/
Non Authenticated Users, Permission Management etc
• Hosting: Azure, EC2, Other Cloud. Decisions Hosting Environment. Interacting with
onsite data/systems.
• Scalability: How does changing server resources affect performance? How is clustering
accomplished? Can servers have different roles? Can work be prioritized between
servers.
• Performance: How many transactions can be done per second? How are bottlenecks
identified?
• Monitoring: Can workflow be hooked to enterprise monitoring? What business level
reporting can be done? Can reports include data produced by process?
• High Availability/Disaster Recovery: Can it run both in active/active and active/passive
configurations? How does multi-site disaster recovery work?

Building A Workflow
Below is a step by step walkthrough of how a workflow is constructed. A video showing
the building of this workflow is available here: ….
Building A Workflow - Analysis
Before starting you must have at least a preliminary understanding of the business process
and automation goals. Some basic questions are:
• How does this process start?
• Does it involve users?
• At what points in the workflow will a user be involved?
• How will those users interact?
• How will those users be informed that their input is needed?
• Are other systems involved? What are the interfaces into these other systems?
• What data is being produced by this process? Where is this data to be stored?
• What visibility/reports are needed by this process?
• What are the business rules?
• How does the process end?
Building A Workflow - 6 Steps
Once you know what workflow you want to build, the configuration is pretty straightforward.
Workflow designers are graphical and usable by business analysts. The actual construction
of the workflow can generally be boiled down to a simple set of activities. In our example:
we are going to read an email (Sent to a request email box), route to a user for approval
and store its contents in the database. We will inform the requestor on both approval and
rejection. This flow will run every 5 mins and be triggered by the Scheduled Job Service.
1. Define Inputs/Flow Structure. Create the flow. Name it. Supply any inputs. This will
provide you a work surface in which to build your process.
In this simple process, we are going to expect the contents of the email to be passed as
input data into the flow.
This data would include:
• From
• To
• Subject
• Body
• File(s)
2. Find, Add and Configure Steps. This is the heart of building a workflow. Search or browse
for the right step. Setup its properties. Configure data coming into it or data coming out of it.
For our example we need the following steps:
• Show Form
• Store In DB
• (2) Send Email Steps
You will note that the start/end steps are always provided by flow.
3. Connect Steps
Steps are generally run in a sequence. This sequence can connect back (loop) if a step
needs to be done more than once.
4. Configure Steps
Now that your steps have been created, configuring them is important. In the case of our example,
this means arranging the form, setting up the database step and creating the text of the email.
5. Test Flow
Once a workflow has been assembled, it needs to be run to verify that it is actually solving
the problem.
6. Publish Flow
The flow is ready to run! If it is initiated by a user, a link of it needs to be distributed.
Conclusion
Software development tools can also be used to automate processes. The goals and the
resulting end user experience might be the same. Certainly there are some problems that
are best solved using more traditional software development approaches. The approach
and artifacts are going to be very different ­and in most cases the amount of effort taken
to create and evolve are going to be different. Workflow not only provides an optimized
configuration timeframe, it also produces artifacts that are understandable and even
changeable by business analysts. The quality of a workflow technology can be seen by
how closely it can keep pure to the paradigm. How ‘black boxed’ are the pieces that are
being put together? How much, if any, scripting/programming is needed to tie things
together? Can non programmers really understand what is happening? Furthermore, can
they actually make changes or build things? Does that pattern break down when it comes
to figuring out what is wrong or the resulting things have to be tested?
www.decisions.com