I agree, a demostration would make it much more clear. Especially because the similarity with flows are many and it looks like almost 99% of the usecase could be easily be solved with flows.
Great question! Find sample use cases here:trailhead.salesforce.com/content/learn/modules/build-a-flow-orchestration/identify-business-uses-for-flow-orchestration#:~:text=Use%20Case%3A%20Organize%20your%20sales%20cycle%20with%20Flow%20Orchestration.&text=Build%20an%20orchestration%20to%20automate,while%20saving%20time%20between%20tasks.
Brilliant - it's a great fit for many of our CMS style workflows - especially when many of the parties don't have a Salesforce license. We considered doing user registration for this - but the use case got priced out
I thought Adobe product managers moved to salesforce and then started planning for Flow as Flow is nothing but similar to Adobe Lifecycle BPM engine which was implemented in organizations like 20 years ago. Debugging style and the way drag and drop of components were all a copy of Adobe Lifecycle.
The orchestration and any background steps without callouts all run in a single transaction and any error within that transaction will cause the orchestration to rollback. This could, for example, cause a Record-Triggered Orchestration run not to be saved if the record save transaction is rolled back. Interactive steps, background steps with callouts, and mulesoft steps all run in their own transactions and an error there will not cause the orchestrator to rollback (but may cause the orchestrator to transition to an error state if they fail. For more details on orchestrator states (and errors) see: help.salesforce.com/s/articleView?id=sf.orchestrator_manage_orchestration_statuses.htm&type=5
Didn't knew there's a good price tagged to this orchestrator!
This is great, but it's purely theoretical to understand Orchestrator's capabilities. Could you please demonstrate a few use cases?
I agree, a demostration would make it much more clear. Especially because the similarity with flows are many and it looks like almost 99% of the usecase could be easily be solved with flows.
Great question! Find sample use cases here:trailhead.salesforce.com/content/learn/modules/build-a-flow-orchestration/identify-business-uses-for-flow-orchestration#:~:text=Use%20Case%3A%20Organize%20your%20sales%20cycle%20with%20Flow%20Orchestration.&text=Build%20an%20orchestration%20to%20automate,while%20saving%20time%20between%20tasks.
Thanks for sharing! Is USD 1 per RUN/STEP the correct price?
Please reach out to your AE to confirm the pricing for your organization!
Brilliant - it's a great fit for many of our CMS style workflows - especially when many of the parties don't have a Salesforce license.
We considered doing user registration for this - but the use case got priced out
I thought Adobe product managers moved to salesforce and then started planning for Flow as Flow is nothing but similar to Adobe Lifecycle BPM engine which was implemented in organizations like 20 years ago. Debugging style and the way drag and drop of components were all a copy of Adobe Lifecycle.
What about roll back
The orchestration and any background steps without callouts all run in a single transaction and any error within that transaction will cause the orchestration to rollback. This could, for example, cause a Record-Triggered Orchestration run not to be saved if the record save transaction is rolled back. Interactive steps, background steps with callouts, and mulesoft steps all run in their own transactions and an error there will not cause the orchestrator to rollback (but may cause the orchestrator to transition to an error state if they fail. For more details on orchestrator states (and errors) see: help.salesforce.com/s/articleView?id=sf.orchestrator_manage_orchestration_statuses.htm&type=5
We are working on using Flow (builder) to achieve similar thing... Flow orchestrator seems amazing but TOO expensive for our use case.
Thank you for the feedback!
Could flow orchestration be useful for business processes based on date fields where the records are not often edited to trigger the flow to run?
Sounds like you could just use Flow to solve that! Orchestrator is best for complex long running async processes across multiple teams.