Roles and assignment

Two different things get attached to a territory, and mixing them up is the second most common confusion in this product after the two hierarchies.

They are stored separately, set separately, and neither implies the other.

Membership — putting people in territories

Open a territory and add users. Each user has a role in that territory — whichever roles your administrator has defined for your organisation.

A person can be in as many territories as you like, with a different role in each.

Changed 2026-08-18 — and if you read this page before, what it said has changed. The selector used to list your org's role hierarchy — CEO, CFO, Channel Sales Team and the rest. That was a stand-in, put in place because the proper list was empty in every org, and it had a real cost: those names were not territory roles and were not valid values for the field they were saved into. The selector now lists the territory roles your organisation has defined, and the old behaviour is gone. Memberships recorded under the stand-in still hold a role-hierarchy name and are worth re-setting.

Where the role list comes from. Your administrator defines it — see Admin setup, step 8. Two things follow:

• They are your organisation's words, not Salesforce's and not ours. The package ships no roles at all, deliberately, so nothing arrives pre-loaded with someone else's job titles.
• The list is shaped. Roles can be flat, or nested to show that one sits under another. Nesting is indented in the selector. Whether your list is flat or a hierarchy is entirely your administrator's choice, and they can mix the two.

If the selector is empty, it will say why, rather than showing a dropdown with nothing in it and an Assign users button that never enables. There are two different messages and they need different people:

🔴 A role here is a label on the membership. It grants nothing. Giving someone Sales Manager in a territory does not change their record access, their permissions, or anything they can see elsewhere in Salesforce. It records "this is the part this person plays in this territory", and nothing more. It is also unrelated to your org's role hierarchy under Setup → Users → Roles — that is a different thing with a confusingly similar name, and it is changed only in Setup, never from this screen.

⚠️ Spellings still matter, but now they are set once. The underlying field accepts anything, so "Manager", "manager" and "Mgr" would be three different roles. Because you now pick from a defined list rather than typing, that is your administrator's problem to get right when they create the roles — not something each user can get wrong.

⚠️ Roles do not inherit. Being a Manager of a parent territory gives you nothing in its children. If someone should hold a role across a branch, add them to each territory in it.

Assignment — how records reach territories

Records are assigned by where they are, automatically:

1. Salesforce geocodes the record's billing address and writes latitude and longitude.
2. Territory Mapper notices the coordinates arriving.
3. It tests the point against your territory boundaries.
4. It writes the assignment.

Nothing about this is manual and nothing needs scheduling. It happens as records geocode.

🔴 Step 1 is the one that fails

If geocoding clean rules are not enabled and configured, no record ever gets coordinates and step 2 never fires. Nothing errors; nothing happens at all.

This is the most common cause of "assignment isn't working". Check it — two minutes.

What gets written

A record assigned automatically is associated with every territory containing it, at every tier — if its point falls inside Southeast → Florida → Orlando Metro, all three associations are written, not just the deepest.

⚠️ A record assigned by hand from the map gets only the deepest territory. The two paths disagree, and nothing stored tells them apart. If you compare records assigned automatically against records assigned manually, they will look inconsistent — because they are. This is a known open question rather than a setting you can change.

When there is no single answer

Assignment assumes a point falls in at most one territory per tier. Nothing enforces that, and territories in a model can overlap. A point inside an overlap is assigned to both, and neither is wrong from the system's point of view.

If a record has more territories than you expect, look for overlapping boundaries first.

What is not assigned

Only records with coordinates. No coordinates, no assignment — the record lands in the exception queue as NO_GEOCODE, which is the queue telling you the address needs work rather than the map.

Only objects that are configured for it. If a record type you expect to see is not being assigned, check with whoever set up the org before assuming a boundary problem.

What does NOT happen

Each of these is a reasonable assumption and each is wrong.

Checking your work