Sometimes a Standard Operating Procedure needs to be followed with all related tasks performed in a rigid sequence. Other times the order of operations is less important - and it's even beneficial - for multiple tasks to be performed in parallel or asynchronously as long as the end outcome is the completion of a prescribed set of task items. Navgar's Flow module allows you all of these options for building the right steps within your own organization's Flows.

The process of setting up a Flow in Navgar is straightforward and the time investment made is small, relative to the ongoing benefits you and your organization will yield from using the module to your company's needs. To get started:

1. Navigate to the Flow Templates module of Navgar.

2. You may either initiate the creation of your Flow by either:

3. Enter the name of the Flow you want to create and press enter or click Add.

4. The Flow Settings screen will appear, allowing you to:

5. Add Tasks to your Flow. These are defaulted as Human Tasks which you can either manually enter yourself or use NavgarAI to assist you with building by clicking Get steps suggestions based on the description to either augment your existing Flow steps or to replace the existing ones with one that is AI generated. (Note: Besides Human Tasks, you may also create a Mail Task (via dropdown or typing .M (This means you need to type both the period and the M at the same time)) or a Subflow (via dropdown or typing .S (This means you need to type both the period and the S at the same time)). For now we'll stick to human tasks but you can learn more about Mail Tasks and Subflows elsewhere in our support articles.

In the example above, I've populated my Handling Customer Orders Flow with tasks to be carried out sequentially and some descriptions for them, which can be expanded or contracted as needed. You are also able to toggle between Highlight Issues or not, which informs you of any issues that would prevent successful launch of your Flow. The recurring issue illustrated here is that the tasks are present but none have been assigned owners for carrying them out. As you assign owners for the tasks you've created for your Flow, the issues highlighted disappear and once all issues are corrected, your simple Flow can be launched.

You are also able to set Delays for task visibility to respective owners from this setup screen via the

icon. This allows you to determine the period between the launch of the flow and the first task being visible to its owner. Once the first task is marked "Done", the delay set on the second task starts until it is shown to its owner. The delays can be set quickly to 6 Hours, 12 Hours, 1 Day, 2 Day, 3 Day, 7 Day increments but you are able to customize this to any number of Hours, Days, Weeks, or Months that you want to.

Just as important as the Delays you set for tasks being "served" to their owners are the deadlines you set for each task in the sequence via the

icon . Because Flows are set to be recurring, it is impractical to use a Date and Time format as a Due Date without a great deal of manual configuration. Instead Navgar Flows use the same countdown format and increments as Delays until a task is due and start counting down from the moment a task is made visible to its owner.

Once you are satisfied with the Flow Tasks and their sequence in your Flow, their Owners, the Delay before each Flow Task is shown relative to the completion of the predecessor activity, the time until each task is due, then a Flow is ready to be launched. See Launching Flows in Navgar for instructions on how to do so.

Let's say you're planning a birthday party and also baking a cake for it. For the birthday party, you need to send out invitations, buy decorations, and set up the venue—each step needs to be completed one after the other. This is a standard flow, where tasks are done in a specific order.

Now, consider baking the cake. You can mix the batter while preheating the oven, and while the cake is baking, you can prepare the frosting. These tasks can be done at the same time, which has parallel tasks in the Flow.

Understanding the difference between these two types of step relationship flows—sequential and parallel - allows you to design Flows that are relevant for the workflow you have in mind.

Going back to my Handling Customer Orders Flow, I had a step called 'Order tracking and communication', which is really two different things so I split it up into 'Order Tracking' and 'Customer Communication' but these tasks - and as many others as you would like - can be assigned for completion in parallel.

To configure your Flow to recognize this, hover over the Flow Step you want to serve in parallel with another one and click on the drag and drop function (six dots that look like a dice)

Move it to the Flow step you want it to be in parallel with to the blue field that populates with the text 'Simultaneous start. Drop a task here to be grouped as simultaneous'

When completed, the two Flow steps will show that they are 'joined' by a blue field surrounding both steps on your template. When the Flow is launched both Flow tasks will be assigned simultaneously to their respective owners.

Sometimes Flows — and life — can be more complicated than linear or parallel pathways can provide. We may know that A-B-C need to happen reliably in sequence and perhaps even that D-E can be done in tandem, but sometimes at point F we need to decide between G and H.

In keeping with the Customer Order example theme, let's consider an order fulfillment flow with a stock availability decision. The first steps resemble prior use cases, but inventory checks can introduce alternate pathways that must be managed differently.

Decision step types allow you to select alternative Subflow options reflective of the branch you need to consider. These outcomes are not limited to a strict binary; they can include multiple tailored responses, each mapped to trigger different Subflows or progressions within the main Flow.

When a flow reaches a Decision step, the assignee selects from the outcome options, each guiding the workflow in a direction that matches the chosen logic. Some options might lead to launching a new Subflow, while others simply move the process forward to the next task. A particularly useful outcome type allows for an early return to the main flow: “Complete flow.”

In a regular Subflow, users are given the option (via pop-up) to either complete just the task at hand or complete the entire Subflow, thereby returning to the parent Flow. This same functionality can be embedded directly into Decision step outcomes. For example, in a quote follow-up workflow where the main flow consists of two steps—Contact Patient and Book Appointment—the first step is itself a Subflow. Within it, a Decision step may present outcomes like “Call Later,” “No Answer,” or “Accept Quote.” If the outcome selected is “Accept Quote,” continuing through the rest of the Subflow (e.g., calling the patient again) would be unnecessary. Instead, selecting “Complete flow” would appropriately close out the Subflow and resume the main flow at Book Appointment.

The available Decision step outcomes now include:

This provides more precise control for workflows where a task’s outcome determines not just what comes next, but whether the current flow itself should end.