Best Practices for Building Flows

If you are new to Flows, be sure to read Building a New Flow before reading this article. Once you have the basics down, use these tips to build Flows that create better end user experiences and minimize errors.

To identify possible solutions to specific limited user error messages in Flows, read Understanding Limited User Errors in Flows.

When to Use Flows

Renaming the Save Button

To see an example of the dynamic capabilities of the Save button in a Flow, watch this quick video of an end user completing a Flow in the web app to create a Purchase Order (PO) and add line items.

To see an example of the changing Save button in the mobile app, watch this quick video of the same Flow on mobile.

If you want the “Save” button on a form to say “Next”, or to change from “Add More” to “Complete and Submit” based on a user’s entry on a form, then you need a Flow. Renaming the Save button on a form is one of the most common reasons to use a Flow.

 

You can provide a custom label for the Save button for each Task in a Flow. The label can tell the user what to expect in the next step, such as the example below, or it can simply say Next. We recommend using something other than Save to indicate to the user there will be more steps to complete than a regular form.

Custom labels can also be created for all results of a Decision. In the screen shot below, item 1 shows the label for the “Yes” result of the Decision (item 2 below). A different label will display if the user selects the criteria for the “No” result. These custom labels within Decisions are how the end user sees the Save button change on their form depending on the data entered for specific fields.

Using custom labels that confirm the user’s selection in a Decision--such as Add Another Line Item above--helps validate the user has entered their data correctly and are proceeding to the anticipated next step. See Decisions for more on configuring Results and Result Settings.

Different Required Fields for Different Situations

Flows are best used when a user needs to create a record and then edit that record as part of a single task, particularly when the required elements for that record depend on different circumstances.

Example: A user is creating a new project. As they create the record, decision points may prompt filling in different required fields, e.g. projects in certain states requiring different certifications. This means the user will be required to complete some fields for certain states but not others. Admins can use show/hide rules on Forms to accommodate different criteria, but you cannot have a required field on a Form also be a hidden field. In this circumstance, then, a Flow is the best solution. A user can be routed to an Edit Task that uses a different Form with required fields based on the state selected in the initial Add Task.

Example: An invoice approval process prompts the user to complete additional information based on dollar thresholds for the invoice.

Whatever the process, a Flow is a great way to route users through initial record creation and then immediately walk them through subsequent steps to fill out additional data based on your business rules.

Note that splitting up data entry into multiple steps in a Flow creates a streamlined experience for users--because they only have to complete necessary fields rather than scroll through a form that contains unnecessary fields or entering things like “N/A” on forms--but it will mean more maintenance work for the Admin. The Admin must create different Views and edit Forms for each step in the process, and then make sure the user’s role has permission to each of those Views and Forms. We recommend naming Views and Forms used in Flows with distinct names indicating their position in a Flow process, such as Flow 1A: Find Open Projects, or Flow 2B: My Line Items for Today. See the section titled Creating Filtered Views for Better User Experience in this article for more on breaking Flows into many steps.

Creating a Parent Record and then Adding Children

Flows are excellent solutions for situations where you need to create a parent record and then ask the user whether they need to add child records or not.

Example: A user is creating an invoice and needs to attach images to document line items for that invoice. The number of images differs for each invoice, so you want to provide a Decision point for the user that asks “Add more images?”

Example: A user is creating a project estimate and adding time for each segment of a project. You want the user to create the parent project, add line items for each task, and then view the total estimated hours before submitting the estimate. A Flow can guide the user through adding children and then viewing the parent again to see the total displayed in calculated fields on the parent record.

Important: Avoiding a Default Add-Child Loop

Best practice: When your business process requires the user to add child records to a parent record, we recommend you ask the question in a way that assumes the user is done adding children and wants to move to the next step in the Flow, rather than assuming the user wants to add more. The screenshot below provides an example.

Item 1 shows the field that will route the user back to add more child records--in this case materials used on a job--or will allow the user to proceed to complete the daily production report. The question for the Decision is “More Material to Add?” and the default value (item 1 above) is “No." This default value ensures the Submit button (item 2 above), relabeled “Review Daily Production Report,” will take them to the next step. If the user instead selects “Yes” in the dropdown for “More Material to Add?”, the Submit button will change to “Add More Material.”

We recommend making the default choice the equivalent of the “Next” choice because sometimes users will mentally skip these questions and automatically click what they perceive to be the “Next” button, particularly when these decision criteria are presented as a checkbox. By forcing them to choose to continue adding children, you prevent a user from forgetting to select “No” and then accidentally returning to the add child task when they don’t have anything to add. In this case, the user will be stuck in your Flow and forced to add fake data or leave the Flow and lose the data they’ve entered so far, causing frustration for everyone. For this reason, it is best to default to the Decision criteria that allows users to move to the next step, rather than defaulting them into an add-child loop.

Creating Filtered Views for Better User Experience

The View option allows the Flows user to view and search for record data using any view in the app. Use View Tasks to help users find records assigned to them, find open records requiring additional information, or look up parent records to summarize child records added in the Flow.

Creating filtered Views that present fewer choices to the user during the Flow will create a more efficient experience and will also reduce errors. Presenting fewer choices reduces the chance users will select the wrong record from a view to mistakenly add information. Ideally a View will be filtered to contain only one record, because if there is only one record in the selected View for a Task in a Flow, TrackVia will automatically open that record and proceed to the next step in the Flow, without requiring the user to select from the view.

Best practice: Create Views that have restrictive filters, such as a combination of created today and by the current Application User, specifically for Flows.

Best practice: Have only a few fields in the View, such as the Record ID. That way, if using a variable to search the View, TrackVia is more likely to find only one match and will automatically open that matching record.

TrackVia searches through all fields in a View, so using filters to limit the number of records and also reducing the number of fields to be searched within those records increases the chances that TrackVia will find only one match and automatically route the user to the next step in the Flow. Carefully test your Flows, however, because if you accidentally create a View that is so restrictive it returns no records, the user will see an error. See Limited User Errors in Flows for more information.

Best practice: Use a distinctive name for each View you make specifically for Flows. Use this name to map each View to its step in the Flow process, such as Flow 1A: My Open Projects, or Flow 2B: My Line Items for Today. With a special name:

i) you will be able to find the View easily when creating your Flow

ii) you will help eliminate the possibility that the View is repurposed for a dashboard and then edited to be less restrictive, thereby eliminating the streamlined experience for the limited user in the Flow.

Build a Complete Flow Before Updating Roles and Permissions

Users must have access to every Form and View used in a Flow. While building new Flows, Admins often identify new Forms or Views needed to support the work in the Flow.

Best practice: We recommend building a Flow from start to finish--including creating new Views and Forms as you go--and then going to Roles to adjust permissions for those who will use the Flow. If you double-check permissions for each Form and View used in the Flow after it's built, you’re less likely to miss one and cause permissions errors for your limited users.

For each role, the form assigned to a table to create new records must also match the form selected for an Add Task in a Flow. In the screenshot above, the form to create new records on the Assets table is the Add Asset Form. As you can see in the screenshot below, the same Form is used to add an asset in the Add An Asset Task in the Flow. If the Form selected for an Add Task is not the form assigned to create new records for that Role on that Table, the user will see a permissions error in the Flow. See Limited User Errors in Flows for more information.

Remember, if you test the Flow as an admin, you won’t catch these permission errors for limited users.

Best practice: Put yourself in the limited user’s role and test the Flow, just to make sure you have all the permissions right.

Using Flows for One-Step Tasks

While Flows can be a great tool for walking users through complicated tasks, they are also useful for one-step tasks where the user will be creating a new record. A one-step task might include adding a new asset or material to an inventory, adding a person to an employee list, or creating a new project.

For these types of create tasks, users could access a form through a shortcut panel (item 1 below) or use a form embedded on a dashboard (item 2 below). Both of those options can clutter a dashboard however, particularly when users also need access to many other Views and Forms on their dashboard.

A Flow has the added advantage of returning users to a dashboard once the create Form has been submitted, giving the user a more streamlined experience than clicking Save on a form and remaining on the form.

Best practice: For a one-step Flow, place the configurable Flow button on the user's dashboard (item 1 below).

Configuring Variable Fields on Forms

Place Variable Fields at the Bottom of Forms

Variables are used on Forms within a Flow to carry information from one step to another, such as linking a child record to a parent, or visualize fields completed earlier in the Flow, such as a part number or temperature reading. Fields containing variables must be used on a Form, but TrackVia, not the user, populates the information. Because you don’t want the user to complete the information, we recommend placing variable fields at the bottom of a Form where they will be unobtrusive and help avoid confusion.

Example: Consider the Form below used to add line items to a work order in a Flow. In an earlier step in the Flow, the technician will have selected the Work Order Number (item 1) and Asset (item 2). At this point in the Flow, these top fields will be populated by TrackVia, and the user will need to scroll past them to access line item information (the green box in the screenshot below). For this form, scrolling isn't a significant problem on the web, but could be on a mobile device. For some Forms, you may be using more Variables and therefore have even more fields that are necessary for the Flow, but aren’t part of the task the user is completing.

In the revised example below, we have moved the variable fields to the bottom (item 1 below) and kept that section grey. We then moved the section that requires completion to the top (item 2 below) and given it a brighter color so it stands out from the passive variable fields on the bottom. These small design considerations improves the user experience within a Flow.

You can avoid confusion even further by adding a placeholder text that says "Read Only" (item 1 below) on the field itself, or adding a text Widget to the lower section that says "Read Only." Do not actually make the field read only (item 2 below), however, because fields selected as read only cannot be filled in by the Flow.

You can also collapse the section by default when the form is viewed on the web.

Use Parent Fields Instead of Relationship Fields

When using a Flow to add child records to a parent, you must include the parent field on the child Form to link the two with a variable. If you use a relationship field on the Form, the user will be able to click the arrow within the field (item 1 in screenshot below) to go up to the parent record. While this is a handy feature on Forms, it is problematic within a Flow because it will take the user out of the Flow and abort the Flow process.

Item 2 in the screenshot above is also referencing a relationship, but rather than using the actual relationship field, the Form uses the parent record ID.

Best practice: Use the associated parent record ID rather than the relationship field, so the user will see the lock icon (item 2 above) rather than the arrow to access a parent record. This tip will avert users from accidentally navigating out of a Flow.

Most Common Gotchas in Flows

Permissions

The most common error when building Flows is forgetting to include permission to a View used in the Flow. See the section titled Build a Complete Flow Before Updating Roles and Permissions in this article for tips on avoiding this mistake.

Changes to a Flow View

As discussed in this article in the section titled Creating Filtered Views for Better User Experience, creating restricted Views for use in a Flow can greatly enhance a limited user’s experience. Changes to that limited View, however--maybe a filter element is removed to expand results, or a reference field is removed--can result in errors for the user. One way to ensure users don’t change Views used in a Flow is to name them by their purpose in the Flow, such as the first three Views highlighted below. This should help eliminate the chance that those Views are used and modified by another admin.

Best practice: Eliminate the “Go to” Search Bar for limited users (item 1 below).

When this menu is present, users can search for an element within all apps available to their role, including all Views and Forms. Users must have permission to view all Views used in a Flow, so any view within a Flow will also display here in the “Go to” Search Bar.

To eliminate the chance a user finds and potentially edits Views associated with your Flows, you can select to hide the “Go to” Search Bar (item 1 below) within the role-level permissions.

Incorrect Field Selected for a Decision in a Long Flow

Flows that have many tasks and branches will also have many associated Forms and Views, which means that if you are toward the end of a Flow and selecting a field for a decision point, you will have many options in your dropdown list. When configuring conditions toward the end of a Flow, pay very careful attention to which form you are referencing. Form titles will display in bold, and all fields on the form will display in plain text beneath the bolded title.

Example: In the example below, item 1 represents a Decision asking if the user is done adding line items. Item 2 is also a Decision asking if the user is done adding line items, but is in a separate branch of the Flow. The condition for both Decisions is determined by the user selecting “Yes” for the appropriate field.

The screen shot below shows the condition where the user must select “Yes” for the field “Done Adding Work Order Line Items.” As pointed out above, the Flow has multiple branches, and different forms might be used for the two similar Decisions in each of those branches. Forms used within a Flow display in bold in the dropdown, two of which are visible in the screen shot below (Maintenance Checklist - Item 1, and Work Order - Item 2).

The Flow could easily have several similar options for users to select in each branch of the Flow (such as our similar Decisions above), so it is very important to double-check that the right Form for the right branch is selected for this condition. If a similar field on a different branch is selected, the Flow will likely result in an error.