#Automation51 personnes en discutent

Hi @Manikandan M, The "Use Approver Field of Product Owner" option tells Salesforce to route the approval request to the user specified in the Approver field on the related Product Owner record, instead of using another approver selection method.

For Example,

•  Product Owner = John Smith 
•  Product Owner's Approver field = Sarah Johnson 
•  An approval request is submitted. 

If the checkbox is checked,

•  Salesforce sends the approval request to Sarah Johnson (the value in the Product Owner's Approver field). 

If the checkbox is unchecked,

•  Salesforce ignores the Product Owner's Approver field and uses the approver defined elsewhere in the approval step (for example, a specific user, manager, queue, or another routing option configured in the process). 

This option is useful when approval responsibility should be maintained directly on the Product Owner record, allowing approvers to be changed without modifying the approval process itself. 

One thing to verify is whether you are referring to a standard Salesforce object/process or a managed package/custom object. In standard Salesforce approval processes, there isn't a standard checkbox called "Use Approver Field of Product Owner", so the exact behavior may depend on the custom implementation or package being used. 

Hope it provides a clear understanding.

The HR system is irrelevant as we can't directly interact with it (due to security reasons).  We have a nightly load that is dumped into a database that we can pull from that contains the structure we are looking for. 

What I've noticed is that only the User Object is exposed to the Object Manager, and as a result, exposed for imports into Salesforce.  If I want our HR data to maintain Roles, Permission Sets [Groups], Profiles, Public Groups, and Queues, how do I set that up? 

My first thought was to create a custom object with our HR data that we would load, and then have Flows to modify the various Salesforce User Objects (if that is possible).

@Garrett Semola

You're not missing anything. This is how Enterprise Territory Management works, and your instinct about it being disjointed to replicate in Flow is exactly the right read.

The key thing to understand is that Enterprise Territory Management was designed to decouple access from ownership on purpose. Territory assignment grants access to a set of users through the territory model without ever touching the OwnerId field. Salesforce's design philosophy is that a team of people in a territory can all work an account through that shared access, so ownership becomes less relevant. That's why there's no native "assign owner based on territory" setting. The product intentionally treats territory membership and record ownership as two separate concepts. So the feature you're looking for genuinely doesn't exist out of the box, and you haven't overlooked a checkbox. 

Now to the practical problem, which is that you still want ownership to follow territory, and you're right that the trigger is the hard part. Territory assignment runs through the assignment rule evaluation engine, not through standard DML the way you'd normally hook a Flow into. When an account gets evaluated and assigned to a territory, that doesn't fire a clean record-triggered Flow event you can latch onto reliably, which is exactly the limitation you identified. 

Here's the approach that actually works without feeling completely bolted on. The ObjectTerritory2Association object is the junction record that gets created when an account is associated with a territory. That object can be queried, and critically, when an account's territory association changes, that junction record is created or updated. You can build a record-triggered Flow on the Account itself that runs on create and update, and in that Flow, do a Get Records on ObjectTerritory2Association filtered to the current account to find its assigned territory. From there, look up the territory's designated owner (more on where to store that in a second) and set the OwnerId. This keeps the logic on the Account where ownership lives, rather than trying to trigger off the territory association directly. 

The piece that ties it together cleanly is defining who the owner should be per territory. Rather than replicating your assignment rule logic a second time in Flow, which is the disjointed part you want to avoid, create a custom field on the Territory2 object (or a custom metadata type mapping territory to a default owner). Stamp the intended owner there once. Then your Flow just reads the territory off the account's association, reads the designated owner from that territory record, and assigns it. Now you have a single source of truth. Your assignment rules decide the territory, and the territory record itself declares its owner. No duplicated rule logic. 

On the trigger timing problem specifically, since territory assignment can run in batch (nightly recalculation or manual recalculation), the cleanest pattern many orgs use is a scheduled Flow that runs after the territory recalculation completes. It queries accounts where the current owner doesn't match the designated owner of their assigned territory, and corrects them in bulk. This handles the case where territory assignments change through recalculation rather than through a user-initiated save, which a record-triggered Flow would miss entirely. If your territories are fairly stable and assignments mostly happen at account creation, the record-triggered Flow alone may be enough. If territories shift frequently through batch recalculation, the scheduled Flow is the more reliable backbone. 

One caution worth flagging before you build this. Be deliberate about the interaction between automated ownership reassignment and your sharing model. If an account's owner changes automatically, you can trigger ownership-based sharing recalculations, email notifications, and potential record access shifts for the previous owner. Test in a sandbox with a realistic data volume, because reassigning owners in bulk during a recalculation window can generate a lot of downstream processing. Also confirm this plays nicely with any existing assignment rules or other ownership automation you already have, so two processes aren't fighting over OwnerId. 

So to summarize the path I'd take: store the designated owner on the Territory2 record as the single source of truth, use a record-triggered Flow on Account to handle create and update time assignment by reading the territory association, and back it with a scheduled Flow to catch batch recalculation changes. That gives you territory-driven ownership without duplicating your rule logic and without depending on a territory association trigger that doesn't exist. 

- SP