Troubleshooting

By symptom. Each entry names the check that separates two different causes, because most of these symptoms have more than one.

Nothing is being assigned

By far the most common problem, and it has three causes with one symptom: silence.

Run these three checks in order. Do not skip ahead — each is only meaningful once the previous one passes.

1. Do your records have coordinates?

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

All null → geocoding clean rules are off. This is the most likely answer. → Geocoding clean rules

2. Is anything assigned at all?

SELECT COUNT(Id) FROM ObjectTerritory2Association

Zero, with coordinates present in check 1 → the geocode half works and the callout half does not. Go to 3.

3. What does the exception queue say?

Open Assignment Exceptions:

Records have coordinates but nothing is assigned

The credential (step 4) or the grant of access to it (step 5).

These are two separate steps and the second is the one people miss. Both fail identically: the callout never leaves your org, so there is nothing in a callout log to find.

The exception queue is where it does show up, as NOT_CONFIGURED. A new install starts in this state, so a queue full of them is expected rather than alarming.

After fixing: select the rows and Re-run after a fix. Fixing the credential does not retry what already failed.

The map is blank, or shows a basemap with nothing on it

Work through these in order:

1. Is a territory model selected? With no model selected there is nothing to draw.
2. Does the model have territories with saved boundaries? A territory with no boundary draws nothing. Check the tree.
3. Do you have the permission set? Without Territory Mapper User the app may open and show nothing.
4. Basemap present, territories absent → the model has no saved boundaries, or you are zoomed somewhere they are not. Zoom out.
5. Nothing at all, not even a basemap → a browser or network problem. Check the browser console; contact MapKraken Labs with what it says.

Records are assigned to the wrong territory

Three causes, most likely first.

The address is imprecise

Check the record's BillingGeocodeAccuracy. Values like City, County, PostalCode or State mean the record was placed at the centre of that area, potentially miles from its real address — and near a boundary that is enough to land it on the wrong side.

Those records are in the queue as IMPRECISE_GEOCODE. They are not failures; the assignment happened. Fix the address to fix the placement.

The boundary changed after the record was assigned

Changing a boundary does not move records. A record assigned under an older boundary stays where it was, indefinitely.

Nothing flags this — the record was assigned successfully, just under a boundary that has since moved, so it is not in the exception queue either.

To move them: select the affected records' rows in the queue and Re-run after a fix. For records that are not in the queue at all, there is currently no bulk re-evaluation — that capability is planned, not built.

Two territories overlap

Nothing prevents territories in one model from overlapping, and a point inside an overlap is assigned to both.

If a record has more territories than you expect, look at the boundaries around it on the map first.

A territory I deleted still affects assignments

A boundary is stored outside Salesforce, keyed on the territory's record id. Deleting the territory does not delete its boundary — the boundary is stranded, and the GIS service can still return it.

You will see this as ORPHAN_TERRITORY_MODEL in the queue.

🔴 Do not redraw anything. Your map is correct. Contact MapKraken Labs to reconcile the service against your org, then Re-run after a fix.

The same thing happens if you clone a territory model. A clone gets new ids throughout, so it has no boundaries at all, while the original's boundaries stay with the original. Do not use clone-a-model as a realignment strategy until this is fixed.

A territory disappeared

Somebody selected over all of it.

When a selection takes area from another territory, the area moves. If a selection covers all of a territory, the territory is removed rather than emptied — and its owner is not notified.

There is no undo. The territory has to be recreated and redrawn, and recreating it produces a new id, so see the stranded-boundary note above.

This is a known defect owed a fix. Until then, look before a large drag over ground that already has territories on it.

Selection is slow

Expected, above a certain size. Click selection is answered in your browser and is fast regardless. Box and lasso selections are answered by the server and their cost grows with how many areas they cover — a rectangle over a metro at block-group resolution can be tens of thousands of areas.

• Zoom out one step to select coarser areas, then refine.
• Split one big drag into a few smaller ones.
• The first large drag over an area is the slowest; repeats over the same ground are much faster.

The map shows no territory names

Expected, and not a fault in your org. Territory name labels are not drawn on the map yet — the typeface has not been chosen, and rather than pick one arbitrarily the name layers are left out.

Hover a territory to see its name. Colour, position, outline weight and hatching all carry meaning in the meantime — Reading the map.

What a working map looks like. Compare against yours: a basemap with nothing on it is the signature of a configuration problem, not of an empty model.

What to send when you contact MapKraken Labs

Everything below is answerable from Salesforce and none of it is customer data:

1. Your org id.
2. The counts from checks 1 and 2 at the top of this page.
3. The category breakdown of the exception queue.
4. For a specific record: its id, geocode accuracy, latitude and longitude, and the territory you expected.
5. For a failed callout: the reason text on the exception row — it carries the service's own message.