If you’ve ever found yourself facing the challenge of making minor updates to a flow, only to encounter a complex scenario like the one depicted below, then you’re well-acquainted with the struggles of maintaining these sprawling “mega-flows.” Even a seemingly straightforward task, such as modifying a field’s assigned value, can quickly devolve into a hair pulling exercise in patience development.
As you navigate through a myriad of nodes, each responsible for completely separate processes, the only common thread being their reliance on the same object as a trigger, a thought is likely to arise: “Surely, there exists a more efficient approach.” Prior to Winter ‘22’s introduction of Subflows, your options were confined to either attempting to visually organize these nodes on a single canvas or circumventing the “2-record triggered flow” rule. However, in today’s landscape, this powerful and innovative addition graces our toolkits and offers a renewed sense of organization and control.
Subflows can be thought of as building blocks that serve a specific purpose. They provide a structured way to organize and manage your automation processes, improving scalability and readability for more complex systems.
Similar to how classes facilitate collaboration among developers, Subflows facilitate collaboration between different teams working on different aspects of a project. Here are a few other benefits of Subflows beyond reducing the jumpscare when someone opens your case after-save flow for the first time:
Enhanced User Experience: Subflows contribute to a more user-friendly experience by hiding intricate details from the main flow, presenting only the essential elements to users. This simplification not only benefits your current team but also reduces the learning curve for new users.
Modularity and Reusability: Subflows promote a modular approach to automation. Instead of duplicating similar actions across multiple flows, you can create a Subflow with the necessary actions and reuse it wherever needed. This not only reduces redundancy but also simplifies maintenance. Changes made to a Subflow will automatically be reflected in all the flows that utilise it, ensuring consistency and reducing the risk of errors.
Easier to Build & Describe: When used correctly, Subflows allow you to understand a complex system more easily. This can take some of the cognitive challenges out of system design & development. In some cases, well named Subflows can allow you to utilise a flow to explain processes to business users as a sort of Process Flow Diagram.
Facilitates Collaboration: As your Salesforce environment evolves, maintaining control over changes and collaborating efficiently becomes crucial. You can update a Subflow independently without affecting the parent, facilitating collaboration among different teams who otherwise may have been working on the same flow simultaneously.
Error Isolation and Debugging: When an issue arises, pinpointing the source of the problem can be challenging in a complex flow. Subflows allow you to more quickly isolate the issue, reducing debugging time.
Now that we’re all onboard with how great Subflows are,
how do we use them correctly? What are the best practices?
As a general rule, you can apply nearly every Programming Principle to flows. Here are a few examples of what we’d recommend to get started.
Single-responsibility Principle (SRP): The ‘S’ in the ‘SOLID’ software design principle, SRP states, “There should never be more than one reason for a class Subflow to change.” Subflows should be responsible for one and only one thing.
Plan Ahead: Before diving into Subflow creation, outline your workflows and identify opportunities for modularization. Specifically, you should be looking for processes that are repeated across different workflows and for breaks between “steps” in a process.
Naming Conventions: Establish clear and consistent naming conventions for your Subflows. These are important to help your team quickly understand the purpose and usage of each Subflow.
Documentation: Document the functionality and purpose of each Subflow to ensure that all team members can leverage them effectively.
Testing and Validation: Thoroughly test your Subflows in isolation before integrating them into larger flows. This approach ensures that each Subflow functions as intended before being utilised across your Salesforce processes.
Variable Management: Lastly, it’s helpful to remember that the initial motivation behind consolidating your flow to begin with was to minimize the proliferation of Get and Update nodes. As you integrate Subflows into your workflow, it’s crucial to adopt a comprehensive approach. Rather than sending only the ID, consider passing the entire record when invoking your Subflows. In parallel, when the Subflow concludes its execution, ensure that you send the modified record back with its corresponding field values duly updated. This meticulous handling of variables not only maintains the integrity of data but also maximizes the effectiveness of your streamlined flow architecture.
We hope this article has helped you to understand how Subflows can help you with creating reusable logic and keep your flows more organised. Paint a mental picture of the days ahead, where the once-overwhelming maze of nodes, each tugging at your sanity, is now elegantly streamlined through the strategic implementation of Subflows. It’s a beautiful thing, don’t you think?
Do you have any questions or would like support in consolidating your workflow? Don’t hesitate to contact us today!
Author: Pete Gilbert
Technical Lead, Lane Four
