from Alex: In internal conversations and conversations with customers, one of the posts I find myself sharing the most is the ‘Thousands of Screens’ post on how flow can drive record-based decision trees that are easy to edit and manage. Teo has extended the design with some clever enhancements and shares them here.

A Practical Application of the “Thousands of Screens” Flow Pattern with Enhancements for Supporting Multiple Troubleshooter Tools-in-One, Pathway Continuation without Selection, and Exit and Return-to-Start Functionality

The “Thousands of Screens” flow pattern (aka: the “Troubleshooter” pattern) is useful for providing a way for end-users to do more than just search a knowledge base for solutions based on keyword matches. It enables end-user guidance and can be applied to a multitude of contexts (i.e. service, sales, etc.).

Think of the “guessing game”, wherein one person thinks of a person, place, or thing in their mind, and another person asks them a series of elimination questions until they can deduce exactly what the first person is thinking. With every response, the person asking the questions is able to collect more information from the person with the solution and apply that information to adjust the questions they ask.Throughout the process, they inevitably work their way closer to the solution.The provision of a pathway to enable “guessing” in this game is the critical component to obtaining the solution. Without it, arriving at a solution is infinitely more difficult, if not–impossible. This pathway provision is what the “thousands of screens” flow pattern brings to Salesforce.

By providing the “thousands of screens” pattern through flow you’re able to utilize the native functionality of the Salesforce platform to provide a “skeleton” for building out “troubleshooting” pathways, while empowering your end-users to manage the actual building, configuration, and content management of these pathways themselves.

The example below provides a sample application of the “thousand of screens” flow pattern as applied to an organization that currently uses multiple service agent “troubleshooting” tools scattered throughout several powerpoint files housed on a common server. Pain points in this use case include:

1. The troubleshooter files are cumbersome for service agents to locate and access daily from the server.
2. When all opened and kept ready for immediate service agent use, the troubleshooter files take up valuable screen real estate from other applications.
3. When all opened and minimized, the troubleshooter files cause confusion and waste service agent time when they are trying to locate the applicable file to maximize and use.
4. The troubleshooter file contents have grown to hundreds of slides and are difficult for service managers to modify contents/pathways/configuration as information changes are needed over time.
5. The troubleshooter file sizes continue to grow and impact each file performance.
6. The troubleshooter file search functionality and pathway visualization is limited.

Supporting Multi-Troubleshooter-Tools-in-One

To begin utilizing the “thousands of screens” flow pattern to replace multiple existing powerpoint-based troubleshooter tools with a single Salesforce-based troubleshooter tool, we can combine the contents of the multiple powerpoint tools into a single troubleshooter tool in which the first question of the tool is, essentially, ”Which tool do you need?” (see Image 1). From this single flow screen, we can now support launching into multiple tool pathways. Additionally, we can use native Salesforce functionality to embed the single troubleshooter flow into the utility bar of the service console for easy, recurring access by service agents and pop-out ability.

These two actions combined 1) eliminate the need for multiple powerpoint files, 2) reduce the amount of screen real-estate dedicated to tools so that the agent can focus on case documentation, and 3) reduce the amount of minimized windows to comb through when searching for a tool.

Image 1: Multi-Pathway Utility Bar Troubleshooter Tool Using “Thousands of Screens” Flow Pattern

Using DiagnosticNode (the front-end accessible record representation of a flow screen’s contents and configuration) and DiagnosticOutcome records (the front-end accessible record representation of a flow screen’s picklist selection values) within Salesforce, we can create a series of pathways for each tool, which in turn, can contain a series of branching pathways based on outcomes themselves, and so on–all stemming from a single starting screen. Additionally, we can establish record naming conventions and ordering mechanisms that help us leverage native Salesforce search functionality and listviews to find, manage, modify, and visualize our troubleshooter tool pathways and content (see Image 2).

Image 2: Naming Convention and Ordering Examples for a Multi-Pathway Troubleshooter Tool

Pathway Continuation without Selection

The original “thousands-of-screens” flow pattern provided through unofficialsf.com, assumed the end user would select a response from the picklist values provided on every screen the agent passed through. However, in practice, instances do arise where end users need to be provided with information (i.e. an instructive statement) without necessarily being asked a question that warrants making a selection in order to move forward (see Image 3).

Image 3: Example of Necessary Pathway Continuation without Selection

To achieve this configuration for a particular DiagnosticNode screen, we can utilize the:

• “Continuation Node” checkbox, and;
• “ContinuationDiagnosticNode” lookup field.

Together, these identify 1) a DiagnosticNode record as a screen in a pathway that does not require a selection from the end user in order to move forward, and 2) which screen should be displayed next upon clicking the “Next” button (see Image 4).

Image 4: Marking a Diagnostic Node (Flow Screen) for Selection Exemption and Continuation

Exit and Return-to-Start-Screen Functionality

We can add more robust functionality to our multi-tool “troubleshooter” tool by recognizing when a tool pathway ends and handling these “endings” in an end-user-friendly manner. Essentially, once a pathway ending is reached 1) the end-user should be notified that no more action is required of them regarding the issue they are troubleshooting, and 2) the multi-tool “troubleshooter” tool should reset so that it is ready for our end users to troubleshoot the wide variety of issues that could occur with the next case (see Image 5).

Image 5: Example of a Pathway Ending

To solve for both of these desired outcomes when a pathway ending is reached, we can use the “End Node” checkbox to identify a DiagnosticNode that marks the end of a pathway (see Image 6). When the end-user encounters the flow screen represented by this End Node DiagnosticNode record, upon clicking “Next” on this screen, they will be routed to the flow “Finish” screen, instead of another DiagnosticNode record. From this standard flow “Finish” screen, they can click “Finish” to reset the tool back to the initial start screen.

Image 6: Marking a Diagnostic Node (Flow Screen) for Pathway Ending

Installation

There isn’t a straightforward installation package, but sample code is available in the repo here.

I recently built an invocable action that uses the Tooling API. I had been hoping to handle authentication automatically using SessionId, but this action needs to be able to work in background flows like record-change triggered flows, and there’s no obvious SessionId in those cases. So I ended up setting what I’ll call ‘proper’ authentication. This incorporates three elements: a Connected App, an Auth. Provider, and a Named Credential.

It’s a little counter-intuitive to have to set up this kind of authentication because we’re trying to use a Flow on an org to call other apis on the same org. Ideally, we’d be able to make that call directly. But some APIs like Tooling API treat even the calls from the same org as public incoming calls. That means we have to create this authorization to allow our flow actions to loop back into our own org.

The relationship between the different security entities has been discussed in some previous posts.

Here’s the approach I used.

1. The invocable action should be designed to take a Named Credential.

2. Start by creating a Connected App.

Here’s an official Help doc

3. Add an Auth Provider.

Here’s the second help page.

4. Create a Named Credential that references the Auth Provider

Here’s the third help page.

5. Assign the Named Credential in Two Places

There are some new requirements for providing access to Named Credentials. You need to explicitly authorize a profile or permission set to use the Named Credential:

Additionally, you now need to create a personal setting for each Named Credential:

The community has built some powerful tools that enable flow metadata to be retrieved, modified and deployed. These tools were used, for example, in the unofficial Convert Process Builder tools. However, these tools make direct use of the metadata api, which is asynchronous. That means that they have to be deployed in the form of a screen flow that fires off the request and then sits there and polls for a result. That’s not useful if you’re running an autolaunched flow on the server.

Server-side flows can retrieve Flow metadata synchronously, via the Tooling API. This powerful interface is not as well known as the Metadata API, but has a lot of capabilities. One powerful facet of this API is that it returns the Flow metadata as a Metadata Apex object that can be manipulated via direct references in code:

This is, for many use cases, a lot nicer than parsing XML, which is what the Metadata api serves up.

I had a use case (involving the training of GPT models to generate flows) where I wanted the synchronous immediacy of the Tooling API (so I can trigger it on background events) and the XML return values that the Metadata API returns. It turns out that this is trivially easy, but it’s not well documented, and I had to consult a senior engineer to learn about it.

You can retrieve XML via the Tooling API, but you need to use the Accept header

The Tooling API is used via REST, and in REST calls to Salesforce, you can set the ‘Accept’ header like so:

req.setHeader(‘Accept’, ‘application/xml’);

This will not be done by default. Most Tooling API calls do not return a traditional SObject and the developers using those calls are happy to skip the XML and work with JSON. If you leave this header out and try to carry out XML parsing with what comes back, you’ll just get odd errors like this:

Error Occurred: An Apex error occurred: System.XmlException: Failed to parse XML due to: only whitespace content allowed before start tag and not { (position: START_DOCUMENT seen {… @1:1)

The Retrieve Flow Metadata action that’s installable below does this work for you, so you can simply insert it into a flow to retrieve flow xml synchronously, by flow name. Here’s where I set the REST header:

Querying by Flow Name is Not Intuitive

The second tricky bit I ran into involved my goal to query on the flowName. I didn’t have the ID. That’s a problem because the Tooling API has two modes and neither directly uses a name. ‘Easy Mode’ is focused on requesting records by their ID. Here’s an example:

If you want to use anything other than a recordId, the good news is that the Tooling API gives you the full power of SOQL queries. Here’s an example of how you query for a piece of metadata that’s confusingly named MetadataContainer:

At this point, I thought I was all set. I posted up this tooling query that queries by Flow Name :

url = baseUrl + '/services/data/v57.0/tooling/query/?q=Select+id+from+Flow+Where+FullName=\'' + flowName + '\'';

When I did this, though, I got this error message:

INVALID_FIELD Select id from Flow Where FullName='Test_MetadataRetrieval' ^ ERROR at Row:1:Column:27 field 'FullName' can not be filtered in a query call

A closer look at the documentation revealed that FullName is indeed explicitly disallowed in Tooling queries:

Thinking it through, this has to do with the fact that there are actually as many as 50 versions of metadata tied to a single flowName. The flowName is thus less unique than it might first appear.

The documentation does not make it clear just how you’re supposed to use multiple queries if you can’t query on name. However, the answer turns out to be to use Definition.DeveloperName:

String url = baseUrl + '/services/data/v57.0/tooling/query/?q=Select+id,Metadata+from+Flow+Where+Definition.DeveloperName=\'' + flowName + '\'';

FlowDefinition is a special object that basically stores which flow version is active. It isn’t used much these days.

With these new learnings, I was able to create Retrieve Flow Metadata action.

Considerations

This action so far is unaware of version numbers. It’s just going to grab whatever is handed to it, which is going to be either the Active version or the Latest.

Authentication Considerations

This action provides a way to provide the name of a Named Credential. If you do that, it will use the NC. If one is not provided, it will try to use the SessionId. Be aware though that SessionId will only work for screen flows.

Install

Version 1.0.2 6/5/23 Production Sandbox added Named Credential support

Previous Versions

Version 1.0 5/12/23 Production Sandbox First Release

View Source

source

I’ve added a new action to the library of Collection Actions. This action will take, for input, a collection of records and a count then it will return, for output, a collection of records along with a count of how many records were returned.

The primary reason I created this action was to address the desire to programatically specify the number of records to keep in the standard flow Sort element. Currently, you must hard-code that value when configuring the Sort element.

With this new action, you can take the entire output of the Sort element or any other record collection and then use a flow resource (variable, formula, etc) to specify how many records you want to keep.

If there are more records in the input collection than the number requested (N), it will return the first N records. If there are fewer records in the input collection than the number requested, it will return the entire collection as well as a count of the number of records in the output collection.

Attributes

Installation

This component is installed with the Collection Actions package version 3.1.0 or later.

Release Notes

4/24/23 – Eric Smith – v1.0

Initial Release

Previous Versions

View Source

Source Code