Understanding Limited User Errors in Flows
This article identifies possible error messages limited users might see when using a Flow and the actions Admin users can take to correct them. Forgetting to give limited users the necessary permissions for all Views and Forms in a Flow is the most common reason a limited user will see an error in a Flow. The Best Practices for Building Flows article provides additional tips for building Flows that create better end user experiences and minimize errors.
For each error in this article, there’s a quick summary of the problem and its solution, followed by a detailed example to illustrate troubleshooting steps.
No Match For Your Search Term
Users will see this error when a View task in a Flow is unable to find a match for the selected variable. If your users are seeing this error, check the filters and fields on the selected View to ensure the variable you are using will display in that View. Perhaps the field that would match your variable is not included in your View, or perhaps the filter is preventing the matching record from being included in the View.
In this example, the user selects a job to begin work (item 1 above), then adds child records to that job depending on the job type selected at the Decision (item 2). After adding the child records, the Flow then needs to find the parent job (item 3) that was initially selected in order for the user to see a summary and sign off. To find that parent, the admin has selected a View (item 4) titled My Job History, and has configured the Task to search the View using a variable (item 5), and the variable is identified as the Record ID (item 6) of the form used in item 1.
The error here is that the filter for the My Job History View displays only completed jobs, meaning that the job selected in item 1, which is not currently complete, will not be included in the selected View. When TrackVia searched for the Record ID in item 1, it found no matches, because that record was not included in the selected View.
This is an example of a View being appropriately restrictive, but not matching the requirements for this stage of the Flow. To correct this error, the admin selects the My Assigned Work Orders (screenshot above), which will include the open jobs and will therefore include the Record ID for the job selected in the first Task of the Flow.
Notice that the dropdown also includes a View titled Open Jobs. Why not use that View? My Assigned Work Orders is a view filtered by the current application user, which means the number of records included will be much shorter than all open jobs, and will be only those jobs assigned to the specific user. By using this further filtered view, the user is less likely to mistakenly select another user’s open job. And if the user has only one job assigned, TrackVia will automatically open that job and the user won’t even have to make a selection for that first Task of the Flow.
You Do Not Have Permission to View the Page
Limited users will see this error when they have not been granted permission for a View or Form used in a Flow. Users may also see this error when the Form used in an Add Task of a Flow is not the selected form to create records to a table for that role.
In the screenshot above, the form assigned to create new records to the Assets table for this Role is the Add Asset Form. As you can see in the screenshot below, this is the same Form selected for the Add Task in the Flow, titled Add An Asset. If the permissions on the screenshot above were changed to select the Default Form as the form to create new records, the Flow below would not work for this role. The user would instead get the permissions error. Even if the Add An Asset Form was one of the Assigned Forms to View on the Assets table, the Flow would still result in a permissions error. A table can only have one Form assigned as the “Create” or “Add” form, and that same Form must be used on any Add Tasks in a Flow.
Forms for Views are a little more flexible than forms to create or add. In the screenshot below you can see multiple filtered Views for an Asset Maintenance table. A user must have permission to all of the Views and Forms used in a Flow, but they don’t necessarily have to match. For example, a Flow that uses the My Assigned Work Orders View (item 1 below) to find an open work order in a View Task could then use the Work Order - Technician Review & Sign-off Form (item 2 below) to edit the work order in the subsequent Edit Task. As long as the user’s role has permission to each View and edit Form in the Flow, the Flow will work correctly.
Admins and Limited Users will see this error when the criteria for a Decision in a Flow does not support whatever the user selected on the current Form. This can happen when a new option has been added to a dropdown field in a table but the criteria in the Flow Decision were not updated to accommodate the new option, or when criteria accidentally exclude an option, such as “Temperatures up to 100” and “Temperatures over 100” but not temperatures of exactly 100.
To correct this, identify the field referenced in the Decision at the point where the user received the error (note that all users will receive this error regardless of roles and permissions). Record the input the user selected for that referenced field and update the Decision criteria accordingly to include that input.
The sample Flow above was created to facilitate two audit types: a monthly visit (item 1 above) and a compliance checklist (item 2 above). The user selects the audit type on the Form used in the first task, Start Facility Audit (screenshot below).
As you can see on the Form, a third option for an OSHA audit has been added to the dropdown. An admin has updated the Audit Type field on the related table to include a new type in their business process, but has forgotten to also revise the Flow to include this audit type. If the user selects the unsupported OSHA option, he/she will still see a Next button.
After the user clicks Next, then the error message will appear. Note that the record with the unsupported option is still saved. A record with all the information entered up to the Decision in the Flow will still exist (in this case an OSHA audit for a certain location on a certain date). After the user clicks OK in the error message, the user will return to the form behind the message, but the user will no longer be in the Flow, because TrackVia does not know how to proceed.