Design

Overview

The Auto terr assignment code has been designed to take advantage of the service endpoint that Veeva already uses, on the Assign Territory button on the Account. This is a nice "packaged" endpoint, that

• Runs any Zip-to-terr/Brick-to-terr rules over the Account (based on address data and Z2T/B2T rules)
• Populates the Territory_vod__c field on the Account itself
• Executes any active territory assignment rules against the current Account, and assigns territories if matching rules are found and the criteria is correct (for more info see here: http://na3.salesforce.com/help/pdfs/en/salesforce_territories_implementation_guide.pdf see p18)

This works well for 1 Account, but is executed interacively from a button on the Account.

The premise of the territory assignment code, is to use the same service, but

• Execute behind the scenes as a result of some triggering condition(s), and
• Allow execution for a batch of Accounts (eg. if loaded in from an external integration)

Particulars

The pieces of the logic that are part of this design, are

• Trigger code on Account, which detects a change to a particular field, and in turn calls the territory assignment web service.
• The callout code itself, which takes input from the Account trigger on which Accounts to execute for. Note this is executed asynchronously, due to limitations on making web service calls from triggers in Salesforce

These 2 pieces of code satisfy the direct update of Account data. In addition, there is also logic that handles Address changes, since these may also affect territory assignment:

• Workflow field update on Address_vod__c to monitor any address change (currently Brick_vod__c) and set a 'callout required' checkbox on the Account (NB. We can't directly call the Account-based logic from Address_vod__c as there is other logic on Address_vod__c which also synchronously updates Account, and to prevent locks/order of execution issues, this is the safest way)
• Complementary time-triggered Account workflow to reset the callout checkbox back to FALSE, and trigger the Account callout logic. This time trigger is set at Trigger time +0 hrs, which generally results in a 1-5min delay in processing the Account. This however is acceptable in the general scheme of things...