#Automation48 utenti parlano di questo argomento

I like the approaches shared above. One thing I'd also consider is making the renewal date

the primary business driver rather than the contract term itself. 

If the renewal date is what ultimately matters, keeping the Contract Term as a whole number and calculating any partial period elsewhere can simplify both reporting and automation while staying within the platform's standard behavior. 

I'd be interested to know whether this is primarily a reporting requirement or if another downstream process depends on the Contract Term field.

Hi @Maria Zazzara you can do this entirely in a Flow. Once WebinarGeek pushes registrants into Salesforce, a Flow can generate a certificate per person and email it automatically. 

CloudFiles Document Generation fits this case well. You build the certificate once as a Word or PDF template, and a Generate Document Flow action merges each attendee's name, title, and training date, runs in bulk across the whole registrant list, and saves the PDF to the record. Add a Send Email step in the same Flow to deliver each certificate automatically. 

Conga works too. CloudFiles tends to be simpler to set up for a clean generate-and-send flow like this, and pricing is transparent. You can free trial too!

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