I expect Slack to be front and center this week at Dreamforce but I’d be shocked if Flow didn’t also take center stage. There’s a ton of new functionality, most of which comes straight from the Apex playbook, but should add a TON of value to this tool. Excited about a few other features in the Winter ‘22 release as well!
As Flow continues to evolve to become more and more like Apex, it adds a major feature that previously was only available in code; the ability to update an external system asynchronously. For those unfamiliar with the idea of asynchronous (async) operations, it just means that it won’t happen immediately (like synchronous operations). It may run a few seconds or even minutes after the original transaction. Nonetheless, I think this has great potential to be expanded for future releases.
One of the great things about code is the ability to take repeatable processes and break them down into methods that can be called from multiple places without having to be repeated every time. Now that feature is available in Flows with Subflows for Record-Triggered Flows! Now you can reduce the complexity of a flow by calling a subflow instead.
Yet another feature that comes from code, the ability to rollback to a previous state. Now you won’t have to worry about Flows partially completing with possible unwanted behavior. The ability to rollback is very useful in Apex and I expect it to be useful to Flow-natics as well!
Keep the code features coming to flow! Similar to running Batch classes in Apex, now you can specify a batch size in your flows to help you avoid hitting some of the limits. Instead of trying to process all records at once, you can specify that they run 1 (or any number ideally under 200) at a time to help avoid hitting the limits.
The death of workflows…may be coming sooner than you think with this new feature, that more or less renders them obsolete. One of the last major use cases that only workflows could solve is now replaced with Outbound Messages in Flows. This feature should also help with plans to eventually convert workflow rules to Flow.
One of the major components to writing Apex code is testing, the idea that you’d create test data to run your code that will help you understand whether real data will pass when users run it. Now with this feature, you can do the same thing with flow, by setting test values while debugging to make sure your Flows run as intended. You can come up with edge cases to test with and hopefully catch errors before they happen, just like with Apex testing. I wonder if something like this will eventually be required before being able to deploy Flows to production, similar to how Apex needs a certain amount of coverage to be deployed.
Not entirely sure what this is, and sounds like it’s a work in progress while in Beta, but if it sounds like an interface to be able to better manage Flows and Processes. Definitely looking forward to seeing more from this feature in the future as Flows grow bigger and potentially more complex. Find out more info about it here!
As part of the Dynamic Interactions feature, developers can now expose LWC events for Admins to configure using the Lightning App Builder.
One of the cool things about components is the ability to nest and re-use them. I think this feature to be able to visualize how the components interact will help developers of new orgs get a sense of how everything fits together.
It sounds like the official GA date is still TBD, but Salesforce Developers have been waiting on this one for a while, ever since it was announced a few Dreamforces ago. The ability to write Node.js, Typescript, or Java and use it on top of Salesforce will increase the customizability for developers as well make the platform more attractive for non-Salesforce Developers to build on.
This is a feature I’ve been excited about for a while. Any time you can save users some clicks, I think it’s a win. Avoiding having to navigate into a record to make updates directly from a report, I think will be a great time saver for end users.
I’ve been a big fan of how Salesforce Developers can make all the components on a page interact with each other. Now Admins will be able to configure those interactions as well. Definitely an improvement to lower the barrier to entry to customizing the UI.
For years, the mantra was always that sharing is always additive but nothing would take access away. That’s all about to change with essentially, the anti-Sharing rules. Now you can restrict certain users from seeing the full scope of records they originally would have had access to. Based on the documentation, it sounds like these will be applied at the end to filter the records after all other sharing has been applied. It only appears to work for custom objects and a few standard objects for now, but I imagine that all objects will be in scope at some point.
I don’t work with Service Cloud too closely but this is what I envision all support agents should have when I call or message a company with a problem. I want them to have my details as well as my case details in front of them so I don’t have to repeat myself multiple times. The ability to pop multiple records on an agent’s screen at once when they accept work should help the overall flow for customers.
I think the writing has been on the wall for this one for a while, My Domain will now be required for all Production Salesforce orgs. Doesn’t sound like it’s coming to Dev Orgs just yet but I’m guessing that will come soon. My hope is that new dev orgs will automatically get a domain like Trailblazer Playgrounds when they’re initially created.