Even better, if you can talk about or mention where this flow hooks into the business process and which groups it touches so the next person can go to them with questions. Outline the flow’s purposeįill in that description field! Which problem is your flow solving? Be sure to include what your flow does, the objects your flow touches, and where it’s invoked from (such as which page layout to use if it’s a screen flow, which Process Builder process to use if it’s an Autolaunched flow, etc.). Flow designers don’t create solutions out of thin air - we need a business case to solve hard problems, and having those breadcrumbs is critical for maintaining the automation long term. Document your flows!ĭocumenting your flow allows the next person, or the forgetful future version of yourself, to understand the overall flow’s objective.
In this blog, we’ll discuss best practices, ‘gotchas,’ and design tips to make sure your flows scale with your organization. We’re starting to see a unique collaboration between admins and developers, with both sides learning a little something about Development and Administration. Flow is not just an ‘admin tool’ - it’s the holy grail of declarative development that unites developers AND admins by allowing the use of Lightning Web Components (LWC) and Apex, and letting the admin orchestrate all of it in one place. There’s no way around it: Salesforce Flow is the automation tool of the future.
0 kommentar(er)
