Geocoding clean rules — the prerequisite

🔴 If you read one page on this site before filing a support ticket, read this one.

Territory Mapper never geocodes anything. It reads the latitude and longitude that Salesforce writes onto a record, and tests that point against your territory boundaries. If Salesforce is not writing coordinates, Territory Mapper has nothing to test, and it does not report an error — nothing happens at all. The map looks perfectly healthy. The territories are drawn. No record is assigned.

This is the most likely cause of "I set it all up and nothing happened".

What clean rules are

Salesforce's built-in geocoding data integration rules turn a billing address into a latitude and a longitude and write them onto the record, along with an accuracy telling you how precisely the address matched.

They are a standard Salesforce feature. They are off by default in a new org, they cost nothing, and Territory Mapper cannot function without them.

Turn them on

Setup → Data Integration Rules.

You will see a list including:

• Geocodes for Account Billing Address
• Geocodes for Account Shipping Address
• Geocodes for Contact Mailing Address
• Geocodes for Lead Address

For each object Territory Mapper assigns, open the rule for the address you want used and choose Activate.

Activate the BILLING address rule for Accounts. Territory Mapper reads billing coordinates. Activating only the shipping rule leaves billing empty and nothing will be assigned.

Then backfill the records you already have

Activating a rule geocodes new and edited records. It does not, on its own, geocode the records already in the org.

On the rule, choose the option to process existing records. Salesforce queues them and works through them in the background.

⚠️ This is asynchronous and it is not fast. A large org can take hours. Coordinates arrive in bursts, and assignments follow them in bursts — a partially assigned org an hour after activation is normal, not broken.

Verify it in two minutes

Do this after activating, and again any time assignment looks wrong. It answers the question with data rather than with a screenshot of a settings page.

Check 1 — are the rules actually active?

Setup → Data Integration Rules. The billing-address rule for each object you assign should read Active.

Check 2 — do your records have coordinates?

Developer Console → Query Editor, or the Salesforce CLI:

SELECT BillingGeocodeAccuracy, COUNT(Id)
FROM Account
GROUP BY BillingGeocodeAccuracy

How to read the result:

Check 3 — did anything get assigned?

SELECT COUNT(Id) FROM ObjectTerritory2Association

Zero, while check 2 shows coordinates present, means the problem is not geocoding. Go to Troubleshooting — the next suspect is the callout credential, which fails silently when it has not been configured.

This three-check sequence is the whole diagnosis. Check 2 separates "Salesforce is not producing coordinates" from "Territory Mapper is not consuming them", and those two problems have nothing in common but their symptom.

Accuracy, and what "imprecise" actually costs you

BillingGeocodeAccuracy records how well the address matched:

A coarse geocode still assigns. The record is placed at the centre of the area it matched, and near a territory boundary that placement is a guess — it can land the record in the wrong territory with no indication that anything went wrong.

Territory Mapper raises IMPRECISE_GEOCODE for those records. It is a note about address quality, not a failure, and it does not block the assignment. See the exception queue.

Things to know before you plan a bulk load

• Coordinates arrive as an update, some time after the insert. Territory Mapper watches for that update. A record loaded without coordinates is assigned when its geocode lands, not when it is created.
• Clean rules have no service level. Under a large load they queue, and there is no way to make them faster from inside Territory Mapper.
• Loading records that already carry coordinates skips the wait entirely, and is the fastest way to a fully assigned org if you have the data.
• Nothing is lost while you wait. Records without coordinates are not silently dropped — they are listed as NO_GEOCODE in the exception queue, and assignment restarts by itself the moment coordinates arrive. No re-run is needed for that case.

If you cannot use clean rules

Territory Mapper needs a latitude and a longitude on the record. Where they come from is not its concern — if your org populates them from another source, assignment works the same way.

What it cannot do is work without them. There is no address-only path and no fallback.