I wish you can come up with a video on what could be a good framework to design flows? should there be a single entry point for all records of an object, and then modularized by actions to be done during CREATE or UPDATE? what can be suggested modularity when there are many record types? what can be suggested modularity to achieve reusability?
This is constantly evolving and will depend on the responsibilities of the team and complexity of the implementation. My latest thinking is: focus each flow on one action. Before Save flows are simply assigning values to the triggering record. All assignments can be made in a single assignment element (or "Update Records" element, which is translated to an assignment in before-save context) For After Save flows, you can have multiple on each object and order them with Flow Trigger Explorer - just don't have multiple that are creating/updating/deleting the same types of records. I think it's important to consolidate DML statements here so you limit the number of times that automation is triggered on the records you are affecting. I am working on a session that analyzes the performance of various configurations of flows that achieve the same result, then I'll have some data to back up my hypothesis. Sign up for Automation Dreamin' November 10-11 to learn more sites.google.com/automationdreamin.com/home/home?authuser=0 If you are trying to reference the record type in entry conditions, you can create a formula field on the object that displays the Developer Name, then reference this field. You could also try the new "Formula" option for specifying entry criteria (though Salesforce cautions that this might not perform well depending on the complexity of the formula you enter) If you'd like to set up a sub routine, you can call subflows in after-save record-triggered flows. This works great to define a collection of records and pass it back, which could be reused in multiple scenarios on different objects. I also achieve reusability with formula resources within a single record-triggered flow
@@RealEvanPonter thankyou for so nicely detailed reply.. I was recommending this video to my colleagues in office today when we were brain storming for flow framework.. We have been using framework for Process Builders and was also trying to see if we cam reuse the principle in Flow Framework also. Gonna share the link for your reference as well here 🙏
Yes, for a short and simple formula that is not needed anywhere else, that would be nice. I find the full-screen input and reusability benefits of formula resources outweighs the extra step of creating that resource
I am not saying to replace formula resource, i am saying it will be good if we have it on assignment. So that I can create a object and assign default values and update in end.
Excellent Playlist, congratulations
Thanks for listening
There are scenarios where you will need to use the triggering record’s values and copy them over to associated records in an after save flow.
We will keep posted you
I think an after save flow would already have that value if its on the triggering record.
Sad to see no sub flow supported in before insert. 😔
May be soon
@@apexhours And they don't have it for Platform Events. SO SAD.
You can create an apex invocable action
I wish you can come up with a video on what could be a good framework to design flows?
should there be a single entry point for all records of an object, and then modularized by actions to be done during CREATE or UPDATE?
what can be suggested modularity when there are many record types?
what can be suggested modularity to achieve reusability?
This is constantly evolving and will depend on the responsibilities of the team and complexity of the implementation.
My latest thinking is: focus each flow on one action. Before Save flows are simply assigning values to the triggering record. All assignments can be made in a single assignment element (or "Update Records" element, which is translated to an assignment in before-save context)
For After Save flows, you can have multiple on each object and order them with Flow Trigger Explorer - just don't have multiple that are creating/updating/deleting the same types of records. I think it's important to consolidate DML statements here so you limit the number of times that automation is triggered on the records you are affecting. I am working on a session that analyzes the performance of various configurations of flows that achieve the same result, then I'll have some data to back up my hypothesis. Sign up for Automation Dreamin' November 10-11 to learn more sites.google.com/automationdreamin.com/home/home?authuser=0
If you are trying to reference the record type in entry conditions, you can create a formula field on the object that displays the Developer Name, then reference this field. You could also try the new "Formula" option for specifying entry criteria (though Salesforce cautions that this might not perform well depending on the complexity of the formula you enter)
If you'd like to set up a sub routine, you can call subflows in after-save record-triggered flows. This works great to define a collection of records and pass it back, which could be reused in multiple scenarios on different objects. I also achieve reusability with formula resources within a single record-triggered flow
@@RealEvanPonter thankyou for so nicely detailed reply..
I was recommending this video to my colleagues in office today when we were brain storming for flow framework..
We have been using framework for Process Builders and was also trying to see if we cam reuse the principle in Flow Framework also.
Gonna share the link for your reference as well here 🙏
Sad to see no formula values directly supported in assignments, need to created formula variable and assign separately.
Flow is improving alot expecting that in coming release
Yes, for a short and simple formula that is not needed anywhere else, that would be nice. I find the full-screen input and reusability benefits of formula resources outweighs the extra step of creating that resource
I am not saying to replace formula resource, i am saying it will be good if we have it on assignment. So that I can create a object and assign default values and update in end.