Skip to main content
Skip table of contents

Introduction to the Workflow Builder

The Workflow Builder is the Discover component for constructing sets of instructions (or workflows) that execute on the data that Discover is configured to manage. Workflows might perform such functions as reporting on empty file paths, identifying emails that have exceeded a certain age, or identifying attachments over a certain size. In addition to reporting, workflows can also be designed to move, copy, or delete data. Workflows are completely customizable. Combined with Policies (which assign workflows to specific managed people or servers, and set the schedules for when they execute), workflows allow you to define the business logic behind a Discover policy. Creating your own Workflows does not require extensive expertise in developing computer code, although some basic understanding of logic and programming is helpful.

The Workflow Builder is installed locally on a computer within your organization and used to create or modify workflows. Workflows constructed with the Workflow Builder can be stored locally (as files) or on the web site. Workflows can be designed to act upon a single data store (such as a Mailbox, Archive, File path, or PST file) or across different data store types. Since workflows are maintained separately from policies, a single workflow can be used by multiple policies to perform actions that help manage your electronic data.


Processing Content With Workflows

Workflows are instructions on how to report on or manage content. There are several types of items that a workflow can target. These include:

  • People

  • Servers

  • File Paths

  • PST Files

  • Mailboxes

  • SharePoint Sites

  • OneDrive for Business

  • And a number of others

Each of these items contain their own unique set of options and sub-layers allowing finer and more granular attributes. A workflow is constructed of two basic building blocks: sequences and steps. A sequence is a series of steps within the same context. For example a "PST File Size" decision step only makes sense within the context of a "PST File". Similarly it would not make sense to add a "Delete Message" action step to a sequence with a "PST File" context.

The Workflow Builder, and workflows in general are designed to logically break down your effort of finding and manipulating specific pieces of electronic information into smaller more manageable tasks (sequences). An analogy might be how a postal service delivers mail. In order for a letter to be delivered properly, it needs to have more than just a name and street address on the envelope. The postal service looks first at higher level aspects of the address, such as country, postal code, or state or province. Next might follow city or municipality, before we’ve finally reached a specific house on a given street. Amy Brown (looking from the bottom up) knows her street address, city, zip code, country, etc. At the country level, though, “United States of America” by itself doesn’t contain enough information for the letter to reach Amy Brown. We require a geographic hierarchy to pinpoint her location.

Using this example, suppose you wanted to locate specific attachments in some of your mailboxes. You would naturally start by asking which mailboxes might contain the attachments. That would be your first sequence of steps; to examine your mailboxes and select those that you wish to process further. Your next sequence might evaluate the folders of each mailbox or it may jump right to examining each message in the mailbox depending on your needs. In either case you are breaking your search down into smaller steps, each with a specific context.


Workflow Steps

Within each workflow sequence you define the steps you which to take when processing data in that context. Steps at this level can be thought of as a kind of flow diagram. From a starting point, you follow the steps until you reach an end point. Some steps may provide alternate branches (paths) while others may loop over additional data types. In each case the logic of your task is captured using the available steps.

There are 8 different types of steps you can choose from when building a sequence. These include:

  • Start - Although technically not an actual step, the start is always the first "node" in each sequence and represents the starting point of that sequence.

  • End - The end step is used to indicate the end of a sequence. When the logic reaches this step, the sequence execution is done. You cannot directly add an end step. They are automatically added for you to terminate each path. You can only add steps between the start and end steps.

  • Decision - A decision step evaluates some sort of condition. Depending on the result of the evaluation, the flow of execution continues down one of two paths (True or False).

  • Action - An action step does something meaningful, typically within the context of that sequence

  • Goto - Execution jumps to a sequence with the same context. Once the execution of the called sequence is complete, the flow of execution within this sequence will continue. This step is used primarily to group a similar set of logic so that it can be re-used.

  • Loop - Similar to the goto step, execution jumps to a sequence with the same context. Once the execution returns a decision is used to determine whether to call the sequence again or to continue the flow of execution within this sequence.

  • Process Each - This step enumerates a list of items and for each item in the list, will call a sequence with the appropriate context to process it. The items may be processed in parallel or in series depending on the component doing the work.

  • Process Each Item in a List - when using Advanced Reporting, this workflow step is designed to process items that have been labeled in an Discover report.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.