Skip to main content

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 个回答
  1. 9月11日 10:57

     

    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