FSL Mobile Flows – Compared to Screen Flows

This post was originally featured on forcePanda by Narender Singh.

The FSL Mobile Application is a Salesforce app used in the Field Service Lightning product. This is a powerful and extensible out of the box application that enables our field organization to perform activities from an iOS or Android device.

This post is part of a series focusing on building and providing an enterprise-scale service solution using the default FSL Mobile application. Field Service Mobile Flows offer a flexible tool to surface business logic within the app, but these Flow types are significantly different than what we are used to with web-based Flows! Not to worry as we will walk through some of the differences and illustrate a few ways to account for them.

What we will build over the next few posts….

An FSL Mobile Flow for placing a Product Request!

Comparison of Screen Flow vs. FSL Mobile Flow Capabilities:

FSL Mobile flows share many of the capabilities of your standard Screen Flow, but there are significant differences that must be considered.  A brief comparison is provided below.

Main Areas ScreenFSL Mobile
Lightning ComponentSupportedNot Supported **See Lightning Components
LC Based Flow ElementsSupportedNot Supported **See Lightning Components
Actions with OutputsSupportedNot Supported
Invocable MethodsSupportedNot Supported
Paused FlowsSupportedNot Supported
Flow Builder DebugAccurateLimited Accuracy **See Debug Mode
Conditional DisplaySupportedNot Supported
Rich Text (Errors, Text, etc.)SupportedNot Supported
Fault HandlingSupportedNot Supported
FormulasFull SupportLimited **See Formulas
Parent/Child RelationshipsNo DMLDML Required **See Parent/Child
Conditional Display of FlowSupportedNot Supported.  **See Conditional Display
Input Default VariablerecordIdId

Let us take a brief look at the areas of particular interest…

Lightning Components:

  • Embedded Lightning Components and Lightning Component based elements are not supported, which will have the largest impact on how we work with FSL Mobile Flows.
  • For advanced Lightning Flow users, you will have become accustomed to providing Flow solutions with built-in custom Lightning Components. Unfortunately these are not yet supported in FSL Mobile.
  • Examples of LC-based elements would be the Dependent Picklist or Lookup Components now provides out of the box. Due to these differences, there will need to be alternative solutions developed.
  • If we see ‘This screen includes screen components that require Lightning runtime’ upon saving our flow, this is an indication it will not work as an FSL Mobile flow (except for Upload File).
  • Please see and vote for this Idea ????!

Debug Mode:

  • The ‘Debug’ mode for Screen Flows is a critical feature in tracking steps, variables, etc. to test flows during build and prior to deployment or activation.
  • The Debug works for FSL Mobile flows, but the results do not emulate running the flow from the Mobile App itself. As a result, it is required to Activate and test from a mobile device before finalizing FSL Mobile Flows.
  • Please see and vote for this idea ????!

Formulas:

  • Formulas are heavily used in Screen Flows for setting default values, populating variables, validating entries, governing branching logic and similar approaches.
  • The most glaring omission that will cause us difficultly is the lack of the IF() logical operator. This necessitates more liberal use of branching in FSL Mobile Flows in order to compensate.
  • Please see and vote for this idea ????!

Parent/Child:

  • In Screen Flows we can create an Assignment for a new Parent record, and then reference that SObject Variable Id in the assignment of Children to that Parent. Provided we have done the DML for the Parent prior to assignment to Child, we can then insert the Children in succession without the need to query for the newly created Parent Record Id to use in our Child SObject assignment.
  • In FSL Mobile flows, this approach does not work. Instead you must insert the Parent and then fetch the newly created Id to use in the assignment elements of your Child records. To give time for the sync and DML of that Parent record, an interim/delay screen will often be used to prevent orphaned children from being inadvertently created, or failure during sync and DML of the child records.
  • Please see and vote for this idea ????!

Conditional Display of Flow:

  • This is in reference to showing/hiding the Flow itself. In the Lightning Record Page you can conditionally show/hide the flow. In FSL Mobile, the Field Service Settings assigned by Profile will determine what the user sees, and there are no conditional displays allowed.
  • This requires that for any flows that are displayed for selection but not applicable, we will have to conditionally intercept the user in early steps of Flow. This allows us to prevent errant entries and to provide a reason to the user as to why the Flow is not accessible.
  • Please see and vote for this idea ????!

Sooooo…. What’s Next?

The key to a successful and full-featured FSL Mobile implementation is understanding these limitations, while employing strategies to leverage what is possible.  While daunting at first, a heavy dose of creative thinking, paired with understanding the limitations, will allow you to deliver an excellent solution for even the most complex business scenarios. 

The upcoming posts in this series will go over some of the different strategies for adapting Screen Flow concepts to work with FSL Mobile flows. 

We will only scratch the surface of the topic, but hopefully will provide a starting point for geeking out fully on FSL Mobile!

Resources