Future of Lightning Flow
On Monday, 11/6/17, I was invited to join a small group to meet with Salesforce’s Flow team at Dreamforce. The Lightning Flow Builder Happy Hour was to thank some of the community members who have participated in helping the Flow feature grow at Salesforce and give a sneak peek in what’s to come.
The following information is super-duper-Safe-Harbor/Forward-Looking-Statements. I would love to be sharing things that are “For Sure” going to happen, but the fact is that this is very much an ebb and flow (ha!) process (double ha!). Scott Kozinchik asked us very nicely not to share any pictures. I’m free to talk about it, the team simply wants to make sure none of the images would be taken out of context.
Some Flow Background
Here are some important things to know about the future of Flow:
- The Flow Builder is currently built within Flash
- Browsers are aggressively moving to not allow Flash in their applications
- The Flow Builder must be rebuilt
This is where I’m obligated to make a Six-Million-Dollar-Man joke: We can rebuild Flow. We have the technology. We can make Flow better than it was. Better, stronger, faster.
To be clear, a lot of this is going to be about the look and feel of the Flow Builder and not underline engineering changes.
They have five categories the team is considering as part of this rebuilt;
- Visuals & Aesthetics
- Ease of Use
- Document & Understand Flows Later
- Testing & Debugging
- More Flow Engine Capabilities
From that, here’s some general examples.
- A familiar interface. By now, most of us has seen Engagement Studio in Pardot and Journey Builder in Marketing Cloud. The thought is to borrow elements (ha) from those tools so the feel of the new builder is similar. Pretty icons. Informational icons. Clear lines. Very obvious start and stop images. The team wants someone to come to Flow and immediately feel comfortable because the look is similar to other tools.
- Improve debugging tools. Anyone who has built a Flow knows it can be arduous at best to debug a Flow. So the team is thinking of how they can add to the User Interface to help with the Debug process. An example would be allowing you to specify values for your input variables so we don’t have to use variable defaults just to debug
- Documenting for now and the future. There’s been a few times I built something. Came back and thought “What the heck was I doing here.” The team is looking at ways to allow us to annotate our Flows and potentially group a selection of elements together to make really large flows easier to navigate and review.
- Ease of Use. The team wants to make Flow more accessible to everyone. I’m no going to provide specifics, but this is a great goal for this tool.
I know I didn’t provide many specifics. Part of this is intentional, and part is because I honestly don’t remember some of the details. I’m sorry Scott, but I purposefully didn’t take any photos so I wouldn’t be tempted to share them. Now I wish I took some so I can recap a bit better.
Don’t expect this changes soon. We’re not talking about the Spring or even Summer releases. This is a huge overhaul of Flow. The good news is the team has the resources to do it. The bad news is it’s going to take quite some time. The also good news is they have a team that is very eager to listen to user’s feedback. They want to see samples of complicated Flow we’ve built. They want to hear our use cases of what would make our lives easier in a new builder. These are good things.
I did ask Scott to come on the WizardCast to share more details when the team is ready. So stay tuned to the podcast for more insights.
What would you want the new Flow builder to look like if you got to build it? Remember, we’re talking User Interface details and not engineering changes like being able to compare collection variables (which would be amazing). Let me know in the comments.
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Wow! Awesome to hear that. Yes, we will wait. Good things take time! Even if it is made to look like Process Builder that should be fine.
The concepts I saw make it look more like journey builder from marketing cloud. Good icons, colors and very apparent start and end points
Being able to document flows would be a HUGE plus in my book!
What type of documentation options would you like to see?
This is awesome! A couple months back I gave Flow training and had to preface it with saying despite how the flow designer looks, it’s actually quite useful!
UI Improvements:
1) No more versioning. I want to be able to edit and save and then the new changes take affect. This is probably part of the underlying engine but still would make things easier.
2) A better formula builder. Various variables and other resources can be used in places you wouldn’t think you could. It would be great if every place you could use these and the built-in formulas, the UI would show you the available, usable resources.
3) For picklist fields, allow it to default to the currently selected value when bound to a record. There are so many workarounds for this.
4) Easier previewing and running from the cloud designer.
1. I actually like versioning. It means I can be working on changes without disruption. Another common use case for me is to have a temporary version that gets used and then quickly switch to a different version when I’m ready. It can be very confusing since pretty much all the references (process builder, visualforce etc) alway use the current “active” version even when there could be 10 versions before or after it. Would be nice to be able to “Save & Activate” without having to go back to the flow version page.
2. An easier formula builder would be great. You can get to the “available” variables now through the type-ahead drop down feature. It’s why I always start my variables with “vr*variablename*” or vrTxt, vrF, etc. Makes using that feature really easily and it removes everything that starts with “var”
3. OMG yes. Picklist values and multi-select values are a royal PIA in Flow. I think this may be more of an engine issue than a UI issue though.
4. There was some concepts for this. It was focus more on the idea of being able to debug a flow. For example, being able to specify the input variables without having to set a default for the variable (or create a fake assignment just for testing).
I am all for the change.
1. Marketing design needs to be easy to understand.
2. Versioning is important and should be kept. Especially in large organizations with many admins.
3. Picklists have always been an issue. I would not hold up the release for this. If the new version is on par with the current version, this can be a quick follow up enhancement. Unless the engine needs to be changed fundamentally.
4. I also use a similar naming convention. Formula engine needs work.
5. Documentation. I use third party software to capture screens to document how flows are built and supported. Very time consuming.
My name is Kathy Baxter & I am a Research Architect working on Lightning Flow. If you would like to participate in our research studies, please sign up at salesforce.com/ux/research. We are keen to involve our users at every stage of our process! Thank you!
Thanks for commenting Kathy!
I get the need to improve the UX etc, etc. Now don’t get me wrong I think flows are the best thing since sliced bread. That all said until they enable flows to:
1) to run asynchronously
2) to be batchable and hence run on schedule
Until the above happens Flows will never be able to stand as equal to batch APEX. I am hopeful however as flows definitely seem to be getting some love the last year or so.
Good points. Although, something to consider is whether Salesforce intends or wants flow to equal to Apex or Batch Apex. My knee jerk reaction is “no” that they have different use cases and needs (and hit the system differently).
The other take away is knowing they’re still going to be improving the Flow platform, but the meeting I intended was focused on the UI change necessary to flash being removed.