Stories in Flow and admin

Salesforce has released a beta version of Test Mode, a dedicated workspace that replaces the traditional Debug button in Flow Builder. This update merges debugging and automated testing into a single interface, requiring administrators to enable the feature through Process Automation Settings before it becomes available for Record-triggered and autolaunched flows.

The new workspace allows builders to save execution runs as reusable manual test scenarios. These saved configurations preserve triggering records, input variables, and mocked outputs. Administrators can now supply static record identifiers for poorly searchable objects and populate primitive collections directly in the test panel. Once validated, these manual scenarios can be transformed into permanent regression tests by attaching expected results.

Test Mode also introduces element mocking, which simulates outputs for subflows and external actions to keep testing isolated from live endpoints. The roadmap includes Winter ’27 enhancements such as visual test coverage tracking on the canvas and Agentforce powered capabilities. These future features will synthesize transaction context to diagnose cross automation failures and automatically generate comprehensive test scenarios with isolated data silos.

The article addresses the limitation of Flow Builder when trying to replicate the standard Recently Viewed List View, noting that direct sorting by view date is unavailable through standard Get Records elements. It introduces the Recently Viewed object as the underlying source that tracks records accessed by each user without requiring explicit user filtering.

The author demonstrates a six-step process starting with a Get Records element to fetch Recently Viewed entries filtered by the Account type. A Transform element extracts the record identifiers, which are then used in a second Get Records element to retrieve full Account data.

Because the original view date field resides outside the Account collection, another Transform element joins the two datasets using the record identifier as the key. The merged collection is subsequently ordered by the Last Viewed Date field using a Collection Sort element before being rendered in a Data Table component.

The Winter ’27 release introduces Flow Tags to help administrators manage rapidly growing automation inventories. This feature provides a flexible categorization method that moves beyond relying solely on flow names or folder structures.

Users must navigate to the Automation App to establish Tag Categories such as Business Area or Purpose. Once categories exist, administrators can add reusable tags and apply them to individual flows through row-level actions or directly within Flow Builder during the save process.

The primary value emerges when searching the platform. Administrators can display a Tags column in List Views, filter results by single or combined labels, and open any tag record to see a Related List of associated automations. This entire workflow operates exclusively within the Automation App and does not function from the standard Setup menu.

Complex Flows often become difficult to navigate as they grow in size and handle multiple processes. Salesforce has introduced a Group element that lets administrators place related components inside a single container directly on the canvas. This visual organization makes it easier to locate specific logic and understand the overall structure.

Users can collapse these containers to hide detailed steps and reduce screen clutter while working on other areas. Expanding the group restores the full view when review or editing is required. The arrangement exists solely for layout purposes and does not modify how the automation runs.

The element supports standard editing operations such as cut, copy, paste, and ungroup. These tools allow teams to quickly restructure diagrams or duplicate entire logical blocks when replicating similar processes elsewhere in the same automation.

Starting in Winter ’27, users can select several records in a List View or a Related List and hand them to a Screen Flow that opens in a modal. The article treats it as an overlooked part of a large release because it lets admins build mass actions without code.

The setup has one detail that is easy to miss. The flow needs a text collection variable named ids, in lowercase, marked as available for input. The selected record Ids arrive in that variable. The example flow gets the matching Contacts, shows them in an editable Data Table on a screen, and writes the edits back with an Update Records element, with fault paths on the data elements.

To expose it, create an action of type Flow on the object and add it to the List View Button Layout under the Lightning Experience List View actions. For Related Lists, create the same kind of action, then add it to a Dynamic Related List – Single component on the parent’s Lightning Record Page.