Skip to main content

#Territory Management4 discussing

Este tópico nos interessa, face termos reginamento de Territorial

Setup

Enterprise Territory Management, one active model: 3 Geography nodes → 16 Region nodes → ~50 Territory → ~19 Sub-Territory. ~ Opportunities, ~ Accounts, 99.96% of which are assigned to a territory.

Opportunity OWD is already Private, but View All is granted on ~ profiles, so everyone effectively sees every region. We're removing it and replacing it with region-scoped access.

Phase one targets our Sales User profile only (~155 users). Sales managers sit on that same profile, so manager visibility has to come from the territory hierarchy rather than a separate profile. Everyone else keeps View All via a bypass permission for now.

Where I've got to

My plan was:

  1. Stamp a stored field Visibility_Region__c on Opportunity before save.
  2. Create 16 criteria-based sharing rules — Visibility_Region__c = 'X' → share with Territory X and Subordinates.
  3. Check UserTerritory2Association before letting a sales user create an opportunity out of region.

Then I noticed our territories already have OpportunityAccessLevel set, and accounts are almost fully assigned — so native ETM territory sharing would already give us region-scoped access once users are assigned, without any of the above.

The reason I'd built the stamped-field approach is that our region isn't always the account's region: an opportunity can carry an MSP end-user region or a manual override that should win. Native ETM only keys off the account. But that's 1.8% of our opportunities — the other 98% would be handled natively.

My questions

1. Is the stamped field + 16 sharing rules the right call here, or am I overbuilding? Would you lean on native ETM territory access for the 98% and handle the override cases some other way — manual shares, apex sharing, an opportunity team — rather than building a parallel mechanism for all records?

2. How would you handle lead conversion? Conversion creates Opportunities too, and the only hook is Opportunity beforeInsert. addError() there rolls back the entire conversion, destroying the Account and Contact the user just created. What I want is to let the conversion complete but withhold only the Opportunity, then route it to the account owner. I'm considering a screen flow replacing the standard Convert button with createOpportunity = false on the out-of-region branch — is that what people actually do?

3. One factual check: when addError() fires on the Opportunity during convertLead, does the whole transaction roll back cleanly, or can it orphan the Account/Contact?

Any views on territory assignment level — region node versus the specific territory a rep owns — would also be welcome. 

 

#Answers  #Salesforce Developer  #Territory Management  #Object Permissions  #Sales Cloud  #Salesforce Admin

1 answer
  1. Oct 8, 12:50 AM

    Hi Rohan,

    Native territory access is the right base. Opportunity access on the territory already covers the opportunities for accounts assigned to that territory, and users higher in the hierarchy get that access from the parent territory. Sixteen criteria-based sharing rules would be a second model for the 98 percent ETM already handles, and you'd be keeping both in sync.

    For the small set where the opportunity region isn't the account's region, don't stamp a field on every opportunity just to catch those. An opportunity team, a manual share, or a bit of Apex sharing on the override records is enough. Managers can stay on the Sales User profile. Put them on the region node so the hierarchy gives them the child territories, instead of a separate profile with View All.

    On conversion, convertLead is one transaction. addError() in an Opportunity before-insert trigger rolls the whole thing back, account and contact included. It doesn't leave an orphan, and it can't withhold only the opportunity.

    A screen flow in place of the standard Convert button can do the branch you want. Call the convert action with opportunity creation off on the out-of-region path, let the account and contact land, and then route the opportunity. The standard button can't split the transaction that way.

    I'd assign the rep to the territory they own and the manager to the region node above it.

0/9000

Hello! 

 

We are using TerritoryMgmt.OpportunityTerritory2AssignmentFilter in Enterprise Territory Management.

Our implementation works as follows:

  • If Opportunity.AccountId is populated, we use the standard Account relationship to determine the territory.
  • If Opportunity.AccountId is NULL, we use a custom lookup(Account) field called End_User__c.

In our Apex filter implementation, we successfully:

  1. Retrieve the Account referenced by End_User__c.
  2. Determine the associated Territory2Id.
  3. Return the correct OpportunityId -> Territory2Id mapping from the filter.

However, when we run Run Opportunity Filter, the territory is assigned correctly when AccountId is populated, but it is not assigned when AccountId is NULL and the territory mapping is derived from End_User__c.

We have verified through debugging that:

  • The filter executes successfully.
  • The correct Territory2Id is identified.
  • The correct mapping is returned by the Apex filter.

Our question is:

Does OpportunityTerritory2AssignmentFilter and the standard "Run Opportunity Filter" process support assigning territories based on a custom Account lookup field when Opportunity.AccountId is NULL?

If not, is there a documented platform limitation? If it is supported, are there any specific configuration requirements or known considerations that would prevent the territory assignment from being applied?

Any guidance or confirmation from others who have implemented a similar approach would be greatly appreciated. 

 

Thanks 

 

#Territory Management

1 answer
  1. Sep 11, 10:57 AM

     

    Hi Ankitha S, 

     

    you've essentially hit the boundary of how the standard filter works: the Run Opportunity Filter process and OpportunityTerritory2AssignmentFilter are anchored on the Opportunity's Account, not on the Opportunity itself. The whole pipeline derives an opportunity's territory from its Account's territory assignments, so when Opportunity.AccountId is null there's no account-territory context for the platform to validate against and it won't persist the assignment - even though your filter runs and returns a correct OpportunityId to Territory2Id mapping. That's exactly why it works when AccountId is populated and silently no-ops when the territory is derived only from your End User lookup, and it isn't a bug in your Apex, it's inherent to the account-anchored design. 

     

    The reliable fix is to stop relying on the standard filter for those accountless opportunities and set the field yourself: Territory2Id is a standard writable lookup on Opportunity, so put your End User to Territory2 logic in an Opportunity before-save trigger (or a record-triggered Flow) and write Territory2Id directly - that bypasses the account-gated filter entirely and is a supported automation point. Keep the standard filter for the AccountId-populated path and let the trigger handle the accountless path. 

     

    If this helps, please mark it as the Best Answer so it helps the next person - thanks!

0/9000

Created Account report, added territory label and territory description column to report, but these columns are showing blank. 

can anyone help?  

 

#Territory Management

3 answers
  1. Feb 29, 2024, 7:53 AM

    @Isameddine Yousfi Till now, my issue is not resolved. will mark the best answer when the issue is resolved. I didn't gave answer, i just responded to your advise. I still need help. 

0/9000

Hello!

 

I am trying to set up territory management, but I am not able to create a territory layer and can't seem to figure out why. For permissions I do have Manage Data Layers and Manage Territory Layers turned on, but when I go to create a layer I'm not able to select Territory for a layer type. Is there another permission that I need or is it something else in the settings?

 

Thank you!

3 comments
0/9000

Hello! Our company uses Enterprise Territory Management. In our Classic account page layouts, "Evaluate this account against territory rules on save" is the default. So, edits to territory assignment attributes trigger the rules to run and the account to be assigned to a new territory.

 

This also works when we hit "Edit" and make changes on the edit screen, but it does not work for inline edits.

 

Any workarounds for this issue? #Territory Management #Lightning Pages

4 answers
0/9000

error:

In the 'US East Coast Zip Code' assignment rule, we can't find the expected selection criteria. Select only accounts with a Billing/ZIP/Postal Code that’s 30000 or lower.

 

Acutally I have done all steps in proper manner ,But still challenge is not completed

5 answers
0/9000

Hi EA team!

 

Does anyone has worked implementing a security predicate based on territory management?

 

I would like to know if the way to augment security predicate nodes is the same for role hierarchy for example.

 

Thanks in advance!

4 comments
  1. Jan 24, 2023, 1:53 PM

    Hi @Roman Michalik I am implementing the same Territory management in CRM Analytics for our org. I am unable to understand the logic for Compute Expression "Add Level". You created Level, F1, F2 etc from TerritoryNamePath. How can I verify my Territory levels. In the territory Model I have territory hierarchy as below

    Territory Model(Active) 

         +WW

               +A

                    AX

                    AY

               +B 

                    BX

                    BY

               +C

               +D

               +E 

               +F 

               +G

    Each territory with + has child territories as shown. How can I implement F1,F2... for above territory Model?

     

    Thanks in advance!

0/9000

The client is asking to put validation so only one territory can be assigned to an Account, if there is any territory assigned to any account, then the system should not allow assigning any other territory to this account.

Second validation regarding userTerritory2Association object. Here client asking to put some restrictions so only one user can be assigned to a territory and if we try to assign a second user against a territory, the system should not allow.

 

Any suggestion please I have checked both and there is no solution as such I know  because Salesforce doesn't give control to write any trigger on ObjectTerritory2Association Object. Also for my second ques, I have checked before insert triggers don't work on the UserTerritory2Association object that's why I am unable to put validation there.

 

Need your valuable comments here.

 @Territory Management

2 answers
  1. Sep 19, 2022, 9:07 PM

    I think you can handle this with the territory filter logic. You will have to be very specific with your territory identifiers. When you break your territories down so that a territory only ever matches one territory filter. Then only ever associate 1 user to the lowest level territory.  

0/9000

#Wisdomwednesday Territory Planning can help you to streamline your territory creation process all from within Salesforce.  Have a look at how and what data to include to start the Territory planning process.

 

Dataset Concepts

 

#Salesforce Maps #Territory Planning #Salesforce Maps Territory Planning #Territory Management #Dataset

0/9000

I am looking to see if someone can explain why Territory Management doesn't change account ownership when you run the assignment rules within a territory? I'm trying to understand the overarching purpose of ETM without being able to reassign ownership within it? Hope that makes sense! Thank you! 

5 answers
  1. Jun 21, 2022, 4:44 PM

    In my organization, we run a batch program periodically to update the account ownership after the territory is assigned to it based on a specific territory role. 

0/9000