Transactions and Flow Orchestration

Think of an Orchestration step as a core flow surrounded by a layer that tracks who that flow is assigned to and what determines when that flow has been properly completed. Once the main orchestration flow starts, it will pause and go to sleep when all appropriate steps have been started. Then it will wake up when work on the steps is carried out, and reevaluate, determining if new steps should be started. Starting a step does not itself create a transaction. Let’s look at what happens with the step’s core flow:
1) If it’s an Interactive Step, the core flow is a screen flow, and the assignee is sent a notification. When the assignee starts that screen flow, it will obviously be in a new transaction.
2) If it’s a Background Step, the core flow is an auto-launched flow. It will normally run synchronously with the resumed Main Orchestration Flow. That means it’s part of the same transaction as the Main Orchestration Flow, and this ‘open DML’ situation prevents callouts, so Orchestrator provides an optional checkbox with the text ‘Contains external callouts or pause elements’ , that will force a new transaction for the step’s core flow. If your entry conditions for a step are advanced, you may want to use a flow to determine whether the step is ready to start. These are called Evaluation Flows, and they also execute in the same transaction as the resumed Main Orchestration Flow.

Quick Tip: Cancel a Running Orchestration from a Flow

You can terminate a running orchestration by doing an Update Records on its Orchestration Run record:

Summer ’22 Sneak Peak: Flow, Orchestrator, NBA

Here’s what you can look forward to in Summer ’22 – hopefully this post will make your ‘Summer 22 Treasure Hunt’ posts a little easier!

Note that this is not the complete list of changes and you should carefully check the Release Notes for changes that may impact your org.

Record Triggered Flows

No-Code Flow Testing Arrives (Beta)

Imagine a scenario where your organization has a team of 15 people managing your Salesforce instance and multiple people making changes to Flows. There’s often a risk that somebody could unintentionally break some business rule logic. With the introduction of Flow Tests, you can check to ensure that you’ve maintained your business-critical logic from version to version. 

Flow Tests allow you to set up assertions or ‘assumptions’ about your results that you want to always stay the same. Those assertions protect your future self or others on the team from making costly mistakes in the future. 

Note: You can currently only create Flow Tests for After-Save and Before-Save flows.

Be on the lookout for a bigger post with a video walkthrough of Flow Tests in the coming weeks.

New Formula Builder With Syntax Checking in Entry Conditions

Get a sneak peak of our new and improved Formula builder in action on Entry Criteria in Record Triggered Flows.  Yep – that means you can now use a formula for your entry conditions! Before this new formula experience existed, you generally had to hope your syntax was accurate and only received feedback about your formula when you went to save your Flow.


  • Select predefined operators to build your formula versus starting out with a blank slate
  • Check syntax to validate that your formula works within the context of your Flow
  • Traverse through relationships using Formulas and reference Global Variables

As noted above, you can now traverse through parent fields in Entry Criteria – one of the most common scenarios is checking for the Record Type’s Developer Name!

Keep in mind that complex formulas in entry criteria will negatively affect performance, so if you are able, stick with non-formula based conditions.  Be on the lookout for this new formula building experience to come to other areas of Flow, like Formula resources, in a future release. 

Workflow Rule Converter Goes GA

Our Workflow Rule converter is now GA – You can now convert even more workflow rules to Flows using our nifty conversion tool. We added support for Formulas and also added support for Null checks.

There will still be some Workflow Rules that are not convertible, namely:

  • Formulas featuring:
    • Hour/Minute/Second/TimeNow/TimeValue
    • IsClone
    • $RecordType

Be on the lookout for the official release notes covering all of the additions and considerations.

Flow Trigger Explorer Enhancements

Check out all the awesome improvements to Flow Trigger Explorer below.

Create New Flows Directly From Trigger Explorer

We’ve added the ability to create a new flow directly from Trigger Explorer – save time by pressing ‘New Flow’ for each trigger category. It even autofills the type and object for you!

Control Trigger Ordering

You can now control your record-triggered flow order directly from Trigger Explorer! Before this, ordering had to be done within each Flow’s advanced settings. Note that if you change the ordering of an active flow, a new version will automatically be created and activated for you. Keep this in mind if you decide to revert a Flow to an older version which may conflict with another flow’s trigger order.

Link: Flow Trigger Ordering Guidelines

Flow Triggers and Trigger Explorer Available in Object Setup Menu

Save time and get a picture of all of an object’s record-triggered flows directly from the Object Manager. You can even create a new flow or open up Trigger Explorer from the object’s setup menu! No more digging around in your org’s Flows list view.

Screen Flows

Add Descriptive and Collapsible Section Headers to Your Flow Screens

New in Summer ‘22, admins can add headings to sections in their Flow screens.

When a section has a heading, the end user is able to collapse or expand the section as they progress through the screen. Currently, all sections are expanded by default.

With section headings, admins can provide additional context and visual hierarchy for their end users, making it easier for users to make sense of a long block of inputs or multiple tasks in one screen. 

Additionally, section headings give visually impaired users the hierarchy they need to assess where in the screen they are. 

Dynamic Forms for Flow (Beta) – Name and Address Fields Added

You can now add Address and Name fields from the Fields tab in Screen Flows. For example, dragging the Name field on a Contact record will bring over all of the associated name fields like Salutation, First Name, Last Name, and more.

Dynamic Forms Address Field – Now with Google Typeahead!

Note that one of the coolest features of the newly added Address field support with Dynamic Forms for Flow is that it now supports typeahead results to automatically populate address data – a huge data integrity and time savings improvement. Check out how fast and accurate it was to fill in the Billing and Shipping address information for a new account.

Screen Editor Accessibility Improvements

We’ve made the following improvements to the Screen Editing experience for visually impaired users:

  • When you open the screen editor, the focus is automatically set to the Label field in the screen properties pane (for new screens) or the Edit button that enables you to edit a screen’s label (for existing screens). 
  • After you create a component visibility condition in a screen component, focus is set to the condition you created.
  • After you create a choice resource from a value field, focus is set back to the value field where you created the choice.

Screen Flows Can Now Run in LWR Experience Sites

Screen Flows can now be run in LWR Experience Cloud Sites.  

What is LWR?

With Lightning Web Runtime (LWR) on Node.js, you can build digital experiences that meet the high scale, security, and performance demands of modern web applications. LWR is a non-opinionated way to configure and load the modules, services, and dependency providers you need to build a JavaScript app.

Some benefits of LWR are:

  • Performance—Thanks to page generation at build time, not runtime, our bar is set at subsecond full-page loads.
  • Friction-Free—An enjoyable local development experience.
  • Power—All the power of Lightning Web Components and the Salesforce platform at your disposal.

Important Notes About Running Flows in LWR

LWR is a strict ‘no aura’ environment, which means there cannot be any aura-based local actions or custom aura components in your Flow.

Additionally, Flows with the following screen components / features are not yet supported:

  • File Upload
  • Image
  • Screen Inputs generated using Dynamic Forms for Flow

Lastly, Flows run in LWR Sites cannot be paused or resumed.


Orchestrations Now Deployable with Change Sets

Admins that use Change Sets to deploy changes through their environments can now deploy orchestrations and the associated flows with the change set tool. Keep in mind you still need to activate the orchestrations upon successful deployment.

New $Orchestration System Variable

We introduced the new $Orchestration global variable that you can reference at any place throughout an orchestration. This new variable allows you to reference the Orchestration Instance Id which is handy for complex orchestrations that involve external systems which may pause or resume the orchestration with platform events.

Open Associated Flows from an Orchestration.

You can now save time to make quick edits by opening evaluation, screen, or autolaunched flows directly in Flow Builder from within an orchestration step.

More Orchestration History Tracked

You can now track more orchestration events from the Orchestration History. orchestration. The following events were added to the history: 

  • An orchestration is canceled
  • A stage or step is discontinued
  • An orchestration, stage, or step encounters an error
  • A work item is reassigned

Order Triggered Orchestrations with Flow Trigger Explorer

Triggered orchestrations can now be ordered along with other After-Save Flow Triggers within Flow explorer. This makes maintaining the order of your automations easier and ensures your orchestrations occur exactly when you want.

Next Best Action

Limit Recommendation Repetitions

You can now limit the number of times Next Best Action recommendations are repeated with the new Limit Repetitions Flow element.

Available for strategies built using the Recommendation Strategy Flow type.

Example Use Cases

  • Limit a recommendation from repeating for 3 months when an employee accepts an action to reset password. 
  • Limit a recommendation from repeating for a year when a customer rejects an offer to purchase an add-on for a discount.


  • When the Flow runs on an object page, it limits repetitions by record. Otherwise, it limits by runtime user.
  • Add Limit Repetitions element after you have your collection of recommendations and you have your recommendation IDs or keys.
  • Customize limits based number of responses within a specific number of days.
  • Save a step by assigning values to the RecommendationOutput right within the Advanced section versus adding the Assignment element. 

All Flows

Autolayout’s Go-To Connectors Now Highlight Referenced Elements 

We introduced Go-To connectors as a way to summarize the outbound connections an element may have in autolayout. For elements with long names, it was often hard to see the element a Go-To connector referenced.

Now, you can find connected elements in your flow by clicking the Go-To connector – Flow will now highlight and the target elements. As an added benefit, we’ll also adjust the Zoom level to ensure the Go-To connector and all of the target element(s) are all in view. 

Custom Icons for Invocable Actions

Take note ISVs and Partners – invocable actions can now have their own unique icons in Flow Builder. This provides fantastic opportunities for branding and at-a-glance ease of use.

  • Developers creating invocable actions can choose to specify either Salesforce Lightning Design System (SLDS) icons or custom SVG files (added as a Static Resources in the org) to use as the icons for their actions in Flow Builder.
  • Developers specify action icons through a new iconName modifier in the invocableMethod annotation in the Apex code for actions: @invocableMethod(iconName=’icon’).
  • Note that custom icons are only displayed in flows using auto-layout.

Use Standard SLDS Icons

Below is a quick example of an out of the box SLDS icon – all I did here was add the SLDS path to the icon in the invocable action @InvocableMethod piece of the Apex Class: 


The format expected is slds:<slds Icon category>:<icon name>

Using Custom Icons – SVG Files

The real power and pizazz of this feature comes from being able to use custom SVG files. SVG (Scalable Vector Graphic) files are vectorized and contain XML metadata about how they should be displayed. 

Suppose I have a static resource named ‘slacklogo’ – an SVG file. The naming convention expected in the invocable method is resource:staticResourceName:svgID. The SVG g-tag Id can be found in the actual metadata of the file. If one doesn’t exist, you’ll need to add one (via Notepad or your IDE of choice).

SVG files must meet the following requirements:

  • The <svg> element in the file includes an id, xmlns, and viewBox attribute
  • The <svg> element in the file doesn’t include a style, height, or width attribute
  • The file doesn’t include a <clipPath> element
  • Each <path> element in the file includes a fill attribute

Here’s an example with a custom slack icon uploaded as a static resource:    @InvocableMethod(iconName=’resource:slacklogo:slack’)

Be on the lookout for more info in the official release notes for best practices and setup help with custom action icons.

Delete Flow and Process Versions from Managed Packages

ISVs and Partners – this one is a biggie for you. You can now delete a flow or process version from a managed package in the org that uploads the package. After you delete the version, the org that subscribes to the package keeps the version until someone manually deletes the version in the subscriber org. This is a great change for ISVs as it means orgs will no longer hit the Flow version limit when new flow versions are pushed from package upgrades.

Note: To turn on this feature, contact Salesforce Support.

Great New Demo Video: Incident Management Via Orchestrator

This official Salesforce demo highlights Orchestrator:

For more videos and information Orchestrator, the powerful way to build sophisticated multi-step workflows on top of Flow, go here.

How to Run an Orchestration: Case Management Example

This is the second post of a 2-part series. Here, we go over how to run an Orchestration. In Part 1, we built this Orchestration and showed the different features available to admins and end users during design time.


Orchestration Run Through

This is what the end user experience looks like when running the Orchestration that we built in the first post.

Orchestration Runs List View

The Orchestration Runs list view will give you a consolidated view of every orchestration that’s ever been run in your org. Admins can also cancel their running Orchestrations from this list view.

Debugging Your Orchestration

If an orchestration is not functioning as expected, you may want to visualize how it has progressed through each stage. The Debugger is a great tool for seeing the progress an orchestration has made. Additionally, the Debugger will list real values of any variables you’ve added in your Orchestration.

Orchestration History

Upon clicking into an orchestration run, you can access the full run history. You’ll see a step-by-step rundown of what’s been completed in the orchestration so far, who completed it, and how long it took. The history is a great starting point for identifying bottlenecks in your process.

Orchestration Work Items List View

The Orchestration Work Items list view allows your end users to more efficiently track all of their assigned work, and is the view from where Admins can reassign work items.

How to Build an Orchestration from Scratch: Case Management Example

This is the first post of a 2-part series. Here, we go over how to build an Orchestration. In Part 2, we actually run this Orchestration and show the different features available to admins and end users during runtime.


Orchestrator (GA Spring 2022) is a new product from Salesforce that allows you to orchestrate processes with multiple flows and multiple users to automate sophisticated business processes without code.

In this tutorial, we will build a Record-Triggered Orchestration for a case management process. We will cover all of the features available to customers while building their Orchestrations.

How do I activate Orchestrator?

Orchestrator is by default activated in every production salesforce Org. As pricing is done using a freemium consumption-based model, you can build and test your orchestration for free, given that you have not exceeded the default 600 runs provided to every org (Please reach out to your Service Cloud AE regarding further Orchestrator pricing). So, you shouldn’t have to do anything special in order to activate and use orchestrator.

To ensure you have Orchestrator in your Salesforce org, you can navigate to the setup menu. From there:

  • Click Process Automation > Flows
  • Click New Flow
  • Click All + Templates

If you see a tab for Orchestrator, that means you can use Orchestrator!

Flowchart (model it out)

Before creating your orchestration, it can be useful to visualize your entire end-to-end process in order to understand which parts you’d like to model within salesforce, which parts will need intervention from third-party systems, which parts should occur in the background, which parts need user input, etc.

Getting Started

To create a new orchestration, you’ll need to navigate to the set up menu. From here, click on Process Automation > Flows, and then “New Flow”. This will take you to the flow set up modal. From here, click “All + Templates”, and then “Orchestrator”. You now have the option of building either an auto-launched orchestration (invoked by Apex, REST API, or other custom code) or a record-triggered orchestration (invoked similarly to a record-triggered flow). We are going to build a record-triggered orchestration.

We are now taken to the Orchestration Builder UI. It’s pretty empty since we haven’t added anything yet. What we do see is the Orchestration trigger. Here, we can modify when we want our Orchestration to be triggered.

Add Stages

Let’s add a stage to our Orchestration. Stages are how Orchestrator groups related steps together. Stages are useful for visualizing Orchestrations in terms of larger subprocesses. Also, you can run multiple steps in parallel if they share a stage, so if you’ve got a number of steps that need to be run in parallel, you’ll want to put them in the same stage.

Add Flows

Each stage will consist of steps. Before we can add a step, we need to create a flow for each step we want our Orchestration to have. These flows will be doing the low-level work (record updates, screens for user tasks, etc.) for our Orchestration.

Background Steps

The first type of step is a background step, which calls an autolaunched flow when it is run. Background steps are great for repetitive background work: record updates, invocable action calls, and sending notifications to users are all examples of background work for which these steps should be used.

Interactive Steps

The second type of step is an interactive step. This step should be used whenever a user needs to give their input on something: approval steps, pricing quotes, and collecting feedback through a form are three examples of how interactive steps might be used.

Logic Elements

Orchestrator currently supports 2 types of logic elements: decisions and go-to connectors. Decision elements allow you to have branching paths that execute on certain conditions, while go-to elements let you loop back to previous elements of your Orchestration. You may have multiple paths in your Orchestration which lead to the same rejection stage; a go-to element allows you to reuse the same stage to handle all of these outcomes.

Evaluation Flows

Evaluation flows give you greater control over the entry and exit criteria of your steps and stages. If you don’t wanna start a step until a certain condition has been met on a record field for example, you’ll want to use an evaluation flow to check for this. Additionally, maybe you want to end a stage before completing all of its steps, because an important criteria has already been met. An evaluation flow fits this use case as well.

Before You Run: Do These 3 Things

Before you can run your orchestration, you need to set up the work guide on any relevant record pages, set the process automation email, and activate your orchestration. This video shows you how to do all three.

Important Consideration: $Record Refresh

A current limitation to be aware of is how Orchestrator saves the context record for a Record-Triggered Orchestration.

In a nutshell, you can circumvent this by always calling a “Get Record” element at the start of every flow to ensure you’re getting the most up to date information on the context record.

This video will help you ensure you don’t run into any problems related to this limitation.

Next Steps

In Part 2, we will go over how you can run this Orchestration and take advantage of our monitoring features to get more information on your running Orchestrations.

Debugging Tips for Salesforce Orchestrator

These guidelines apply as of Spring ’22. In general, the idiosyncracies and gaps that are discussed here represent things that the development team just hasn’t had a chance to get to yet.

Key Debugging Concepts

Use the Orchestration Run list view to access the debugger for in-process orchestrations.

Unlike screen and autolaunched flows, there’s no Debug button in Flow Builder for orchestrations. There probably will be one at some point, but the best explanation is that the mindset of an orchestration is oriented around it being ‘In Process’, and there’s going to be a different place where you manage your In Process orchestrations than the Flow Builder canvas.

The first thing to get comfortable with is the Orchestration Run list view, which you can access from the waffle

This produces this view:

The Debug and Cancel menu items are only available on In Progress runs.

You can debug a paused orchestration, and you can debug a failed (errored) orchestration, but you can’t debug a completed orchestration

Suppose you are trying to figure out whether a value is being output by a step flow as expected. You could run the step flow in isolation, but then you have to simulate the inputs that it gets, and that can take time and be unreliable.

As long as you have at least one Interactive Step, the orchestration will pause and you can click Debug Orchestration, as shown above. If you don’t have anything to stop the run from hurrying through to completion, you won’t have a way (for the time being) to inspect intermediate values.

If you do have an all-Background Step orchestration, you can tack on a placeholder Interactive step to ensure you can fully inspect the values. Here’s an example:

You can also insert a step that causes an error, because the error email will contain the same information as the debugger:

Note that when the error happens in a step flow, you’ll get two error emails, one for the step flow and one for the orchestration (which is also a flow).

If you want to inspect intermediate step flow values, use manual variables

Orchestrator currently shows, for each step flow, the inputs that went into it and the outputs that came out of it:

However, Orchestrator does not yet show each element of the Background Step. In the case above, I was debugging a problem with the Flow Interview and wanted to see what value was output from the Get Records call here:

Usually, I use automatic outputs and don’t create manual variables, but because of the limitation of seeing the internal elements of background steps, I elected to create a variable to store the Flow Interview and clicked ‘Available for output’:

Then, in the Get Records, I manually mapped the field I cared about to this manual variable:

As a result of this, I’m able to observe what was being returned for Flow Interview, even though it’s in the middle of the Background Step:

If you choose to do this, be careful about other things downstream in your flow that might mutate the value of your variable before it gets output.

Orchestrator Pricing

Orchestrator is generally available and here’s an unofficial FAQ on how it will be priced.

How is it sold?

The product will be sold via a Service Cloud add-on license.

What’s the Freemium Allocation?

All PxE, Enterprise, Enterprise, and Unlimited Editions get 600 annual runs included (regardless of org size).

Pricing Before any Discounts?

It’s a consumption-based SKU which means you pay $1 per orchestration run, and it’s sold in yearly increments. Customers purchasing in volume can seek discounts, as is usual.

Is there a way to extend Orchestrator usage to non-Salesforce users in my org?

Yes. There’s a new ‘no-cost’ Limited User License in the works that is designed to be assigned to users who don’t already have a user license. This will allow them to log into Salesforce and participate in orchestrations. The license will have limitations on it, so it isn’t a substitute for a typical Salesforce license. Final details are still being worked out.

Learn more about Orchestrator.

From Akihiro Iwaya: Adding Approval Functionality to Orchestrator

Akihiro-san has done some of the most in-depth early consumption of Orchestrator. Here he demonstrates a number of techniques for lighting up approval processes.

Orchestrator goes GA in Spring ‘22 with new enhancements!!

  • Assignment to Queues and Groups
  • Reassignment of Work Items
  • Cancel a running orchestration
  • API access to trigger Orchestrations

I have been exploring the use of Orchestrator for approvals use cases. Previously I concluded that  “I have confidence in replacing the approval process with Flow Orchestrator because I believe that new functionalities related to the approval process will be available at GA. My implementation of the approval process is a little bit complicated because of lacking standard functions such as supporting Autolaunched Flow, recall approval process (back to previous stage), standard actions (lock & unlock record, get queue member) but I am very excited to continue to watch new features.

In this post I’ll look more deepily at approvals use cases using the GA Orchestrator feature set. I will show three approval process examples using a simplified Employee Time Off Application with minimum automated actions. 


Automatically assign an approver using the manager field in User.

The second example is using the new enhancement of “Assignment to Queues and Groups”. Submitter and the first approver can choose either a user or a queue. 

  • Example 3: User Can Dynamically Choose Next Approvers: 

The final example makes use of the new enhancement of “API access to trigger Orchestrations”.  Submitters can select one of the orchestrators to initiate new orchestration on Screen flow calling Apex action. This is a great enhancement because the user dynamically chooses any orchestrator on the fly. At this Example, the submitter selects a route table record containing three approvers and serial or parallel orchestrator during submit for approval. Again you can add functionalities that are implemented at case1 and case2.

Example 1: Simple Approval Process1 using the Manager Field

The first example is very simple and familiar with the legacy approval process. Automatically assign an approver using a manager field in the user table. There are only two approval steps but you can add more steps.


  • Assign an approver using a manager field
  • Return approval request to previous approver after final approval
  • Track and view approval history
  • Custom ‘Lock Record Behavior
  • Custom notification
  • Eemail notification


Creating Custom ‘Lock Record’ Behavior using Record Type

When the user clicks on this custom Submit for Approval button, the record type of the underlying record is changed. There are two record types, new and read-only with corresponding page layout

. This allows for these behaviors:

  • The Submit for Approval button vanishes. This is enabled in part by the recently introduced Dynamic Actions, a feature that allows admins to choose which actions need to appear in the Highlights Panel on the object’s record page
    • The new record type is linked to a read-only page layout, creating the effect of a Lock Record process.
  • Additional Notes:
    • There is one concern that required fields can not be Read-Only in the layout. Since those fields are always editable, I decided that no fields are required at this object.
    • Replace “New” button : There are two reasons for replacement of New button. Users can not skip record type selection page for default new button and after hitting new button, screenflow shows record creation form with validation of required fields. 

Custom Notification

The Messaging Notification(?) action is used to generate custom notifications:

Work Guide Usage

Approval is done in the Work Guide, where conditional field visibility shows only the necessary fields:

Approval History

Approval History items are logged to enable the full history to be easily views:



Example 2 Approval Process Using Queues/Groups

The second example highlights the abillity of Spring ‘22 Orchestrator to “Assignm to Queues and Groups”. This example doesn’t provide a way to  return the approval request to other approvers but you can easily add that as was shown in  Example1.


  • choose a user or a queue 
  • approval history
  • lock / unlock record
  • custom notification
  • email notification

Choosing a Queue with a Custom ‘Submit for Approval’ Flow



Example 3 :User Can Dynamically Choose The Next Approvers

The final example demonstrates the power of the new feature  “API access to trigger Orchestrations”.  Submitters can select one of the orchestrators to initiate new orchestration on Screen flow calling Apex action. This is a great enhancement because the user dynamically chooses any orchestrator on the fly. 

To enable this, I created a custom object called  a route table where I can configure different combinations of approvers:  


  • route table (custom object) containing three approvers
  • choose either parallel or serial orchestrator
  • return the approval process to other approvers at serial mode
  • approval history
  • lock / unlock record
    • Change record owner to System User so that submitter and approvers can not edit
  • custom notification
  • email notification

When the record is submitted, this version of the orchestration let’s them choose between Serial and Parallel, and lets them choose one of the predefined routes:

Serial mode

Parallel mode



Serial mode

Parallel mode

Legacy Approval Process Features

There are legacy approval process features and corresponding implementation ideas on Orchestration. 

Create an Approval Process with the Standard Wizard

There are three ways to implement “No one can edit a record after submit for approval except admin” functionalities in my examples. The legacy approval process allows administrators to edit or the both administrators and the assigned approver to do. In case you need that the assigned approver also edit a record, “Changing record owner” may be one you take. Before assigning a work item to an approver, the record owner is updated to the approver in flow.

  • Example1 : Dynamic action,record types, replace new button
  • Example2 : Apex Approval Class
  • Example3 : Change record owner
  • Design the Approval Request Page
    • You can design whatever you like on Screen flow  for the approval request
  • Specify Who Can Submit Records to an Approval Process
    • Record-Trigger Orchestration can not set an entry condition with a hierarchy field. So you need to go a long way around to achieve it. 
      • flow action
        • Dynamic action can control who can submit records to an approval process
      • screen flow
        • Update records element update field value
        • Updating field value kicks your Record-Trigger Orchestration
  • Dynamic action can control action buttons on your record pages. You can set action visibility in order to hide/show your action button that executes your Autolaunched Orchestration 

Add an Approval Step to an Approval Process

Automated Actions to an Approval Process

Prepare Your Org for Approvals

Approval History Reports

Manage Multiple Approval Requests

Approval Requests for Users


Orchestrator CAN be a replacement of the legacy Approval Process and implemented with a more complicated scenario. But in case the legacy approval process supports your requirement, then implement it by legacy one. Otherwise you develop your own approval process on Orchestrator. Before Approval Process Flow Templates will be officially distributed, we utilize a hybrid of the legacy and orchestrator for the approval process.