Salesforce Workflow vs Process Builder vs Flow - Which One?
ฝัง
- เผยแพร่เมื่อ 4 ส.ค. 2024
- Sign up to a 5 Day Salesforce Challenge to help get your certification! talentstacker.com/salesforce-...
Learn about the different features in Salesforce Workflow, Process Builder and Flows and which could be right for your needs!
Timecodes
0:00 - Intro
0:45 - Overview
1:05 - Best Practice
1:52 - Review of Salesforce Workflow
3:18 - Review of Salesforce Process Builder
4:33 - Review of Salesforce Flow Designer
5:52 - Recommendation = Workflow vs Process Builder vs Flow
6:05 - Learning More/Outro
If you find this useful subscribe for more videos like this every week!
May the Salesforce be with you! x
Connect with me on Twitter: / adamfoyston
Connect with me on LinkedIn: / adam-foyston-32148954
UPDATE! Workflows and Process Builder will be discontinued! Salesforce announced in Dreamforce '21 that they are launching migration tools to move your Workflows and Processes over to Flows, which is now THE recommended automation tool!. So get on the use of Flows now! xxx
I want to work but I don't have knowledge on sales force
Please what do I do?
I love it when a video not only answers my question, but helps me understand the better question to have asked in the first place. Well done.
Thank you so much for the kind feedback, Phil! Let me know if there is anything in particular you'd like help on or have content suggestions for me! Cheers again :)
Thank you so much for this easily explained information! Certification in 2 days!!
Best of luck Corey!...actually, 11 days ago. How did it go :? - if not great don't worry - you always get other chances if not successful first time :)
@@AdamFoyston Thank you so much, I didn't pass but re-evaluating and retesting in a month!
Great video! This helped me understand the process better. Looking forward to seeing more of your videos.
You're welcome. I'd also recommend checking out this video: th-cam.com/video/09NL4KsZ61s/w-d-xo.html
As it articulates that you should only use Flow from now on as SF are decommissioning Workflow and Process Builder. :)
Great explanation and I love the length of your video. Thank you
Glad you enjoyed it! you're welcome. However, DON'T FORGET that this is an old video and Salesforce are currently phasing out Workflows and Process Builder so check out this other video I did for more info on that: th-cam.com/video/09NL4KsZ61s/w-d-xo.html
Great overview! Keep these videos coming...
Thanks! Will do! :)
Concise, clear and to the point, love it! Subscribed! 👌 🙏
Awesome, thank you!
Although! I would say that an update to this video is a recommendation that you should 100% only do Flows from now on as SF are decommissioning Workflow and Process Builder. Check out this video (and my other Flow videos) for more: th-cam.com/video/09NL4KsZ61s/w-d-xo.html
Thanks again!
Perfect Tutorial ! Thank you :D
You're welcome!
Great video and awesome explanation, thank you sir
You are welcome - glad you found it of use. Do let me know if you have any suggestions or how I can help you with anything. Cheers, Adam :)
Awesome as always
Thanks again Vincenzo! Hope you're doing well.
what a video mate, go on! looking forward for more tips
Haha, Thank you! Let me know if you have any suggestions for videos you'd like to see Vishnu :)
Thanks for the explanation!
You're welcome!
Awesome video thank you!
You're welcome James.
thanks for the video!
You're welcome, although good to note that Workflows and Process Builder are now dumped by Salesforce, with Flows being the future, so check Flows out :)
Great video!
Thanks!
Best explanation 👌😃✌
Thanks a lot 😊
Let me know if you found this useful - did it help you? Or not!? Is there a subject or tutorial you'd like me to do next?
I've often found it difficult to know when to use Apex and when best to use one of the Salesforce automation tools. Although, when you don't code in Apex like me and you don't have a clever developer to hand - Workflows, Process Builder and the Flow Designer have become my best friends! If I didn't have these I would probably be back in my old job pushing trolleys in a Super Market!
Very helpful. Thanks for the info!
Very very helpful. I am showing your videos to my class.
@@gracepunay8875 Don't forget to tell them that Workflows and Process Builder are being phased out by Salesforce and replaced completely by Flows. Check out this video for more info: th-cam.com/video/09NL4KsZ61s/w-d-xo.html
Adam, great video!
I'm seeing blogs & videos starting to say only use Flow to avoid having the technical debt of having to move anything you have in workflows and process builder over in the future. Our Org is newer so I have mostly a clean slate, should I go all-in on learning and creating Flows?
Hi Jonathan! Thanks for the comment. So great question. That's what I was kind of saying in the video, that in my opinion, Salesforce will enhance Flows even further and eventual (possibly) phase out the need for Apex code. However, I don't see Process Builder going away any time soon. Workflows are still around and even though Process Builder has pretty much made Workflow irrelevant, I still think there will be a place for BOTH Process Builder and Flow in the future for Salesforce (at least the next 5 years min).
My reasoning for that:
a) Flow designer is great, but it still requires a slightly higher level of competency in the Salesforce Admin/Dev/Consultant to be able to design complexity and utilise the tool accordingly. Therefore, there Salesforce will still need a 'simpler' tool available for the aforementioned to use in automating out business processes and functions
b) There are still a lot of common use cases where Process Builder can handle things very well. Only when things become much more complex will you need to rethink and pull into a Flow.
However, the arguments to go 'all in' with Flows, using it for all of the simple and more complex things, is still a valid one. It all depends on a few things:
1. Are you comfortable enough with Flow designing to build everything you need there?
2. Will other admin/dev users who work with you or who come after you, be just as confident with Flow?
If the answer to both is 'Yes', or at least, 'willing to get there', then great, go for it. Like you say, you won't have any 'technical debt' or more accurately, process automation running in more than one place to manage.
Let me know if you have any further questions or if you have any requests for future content (i.e. use cases)
Cheers again!
Adam
@@AdamFoyston thanks for the feedback! That's reassuring. And great point on the future hires/replacements having to know it too. I'm a new solo admin (no one else w/Salesforce knowledge in the company) and feeling pressure to learn Flow for this reason. And it's not easy! - Why I've found your videos. Please keep the flow tutorials coming.
And I'm honestly, I would value any content on building formulas for validation rules, formula fields, etc. Why do we put an '!' in front of some words, a $ sign, why shouldn't we reference a specific user/account id, any other best practices, tips/tricks.
Thanks so much for taking time to help us all grow & learn!
Amazing
Thanks amigo x
Hi,
Thanks for video. You said that 80% of automation can be done with process builder. I was reading on Focus on Force study material that Flow is the tool recommended by Sales force for most declarative solutions moving forward because it has better performance.
Hi there - yes you’re right. It’s what Salesforce will push to be the number 1 going forward but my comment was more that, for most of the basic/medium automation needs of a lot of businesses, you can achieve it using Process Builder which is easier to use/start with. However, (I think) I mentioned in the video that if you can, move all your automation across to Flows eventually when you’re more experienced. Check out my other flow videos and if you find it easy/understandable, then go all in with flows. Good luck and let me know how you get on! 👍🏽
@@AdamFoyston Very well Explained Adam, Thanks!
So, how do you Unit Test a flow? or do you rely on pure "Smoke Testing"?
Hi there! Great question. So nomenclature might differ but here is my usual process for getting a new function, like a flow, into ‘Live’:
1) Unit Test = usually the developer themselves, running functional test cases against the requirements ‘acceptance criteria’ (usually supplied by the business analyst) - this is to ensure what they created actually works as it was designed to.
2) User/Stakeholder acceptance = effectively a demo/show and tell to ensure that what the dev team create meets the requirement owner’s requirements (if appropriate the users would be invited to try it out themselves or run the testing too)
3) Regression Testing = wider testing to ensure this new piece of functionality hasn’t broken something elsewhere in the system or process
4) Smoke Testing = this is more ‘tongue in cheek’ but refers to the testing performed after deployment from one org to another to check that, not only was the deployment successful (I.e. did you activate the flow, etc) but does it work the same in the context of this Org (ideally the orgs will match completely but there might have been changes to profiles or permissions that mean it might not work for some users the same - as an example)
The great thing about Flow design (as you may have seen in the video) is the debugging feature in runtime so you can see exactly where thing might be going wrong as you execute the test cases. Here is a link to better describe this use case: trailhead.salesforce.com/en/content/learn/modules/flow-testing-and-distribution/make-sure-your-flow-works
All in all, I could have gone into a bit more detail into the testing and deployment piece but was aware I already had a long video.
I may do a specific video on my experience and self-taught best practise around deployment and testing? What do you think? Is there any thing else you think might be useful to do a video on next?
Thanks again for the comment - appreciate the feedback/questions :)
@@AdamFoyston " is the debugging feature in runtime so you can see exactly where thing might be going wrong as you execute the test cases."
So whenever a change happens, all the flows must be tested one by one? that doesn't seem to scale well..
Hi Barabim, apologies for my tardy reply.
Great question. To answer your question directly, "...when a change happens, all the flows must be tested one by one..", not exactly no. If you've made a change, and I'm assuming you mean to a Flow, then no, you wouldn't need to test all the other flows UNLESS your flows were overlapping for some reason - e.g. one flow had a path that changed a value on a field that was used by another flow, or a path in a flow triggers another flow to run. Even then, you wouldn't need to test each flow, just the ones in question and mainly to ensure the other process is unaffected. This would form part of your 'regression testing' if you were launching a new flow that could affect another flow or part of some other existing functionality.
Testing is an unavoidable and painful thing at time, but can differ greatly in size depending on the type of functionality your launching. In all cases there should be an impact assessment into how the new function/dev will affect the wider org (or not) and adjust testing according. You would also, in all cases, need a governance process setup to effectively manage releases into your live org and create a minimum/baseline of testing and due diligence for all dev, even if just the impact assessment and a unit test.
One note on the debug feature in Flows, it won't work for when you have a Record-Trigger Flow....which isn't great. So if the flow doesn't work in testing, you have to get a bit creative in trying to find out where it's going wrong. You can use an 'error path' to direct the user (yourself when testing) to a screen with a message, etc, or, better still, you can add an email action at various points to pinpoint when the process is failing.
Regarding 'scaling' or, making the testing process quicker/more automated, there are some tools that can be used to run some of them for you, such as ACCELQ, HP Unified Functional Testing (UFT), Cucumber, Force.com IDE (Eclipse-based), Change Sets (Cloud Deploy), Ant/force.com migration tool, but require detailed frameworks built to run against. These are great for regression testing as over time, you will get more and more functionality that need testing if new and big functionality goes in, so being able to add more and more to the scripts will mean automation will be a huge huge time saver - as per your comment. Automated testing in Salesforce is still a challenge though. Maybe one day they'll build some great new testing functionality in, even if just to help run regression over time? There are also still Apex Test Scripts, but these require a lot of dev and not always build in the most comprehensive and use case driven way. Mainly as a requirement to get code coverage for code deployment (which you won't need if you do in Flows or Process Builder).
Anyway, I hope that helps a bit or at least expands the discussion. Food for thought.
Let me know what you've found works well or if you have any specific use cases to explore in future content that you think might be useful?
Cheers,
Adam