Defining territory roles

What a territory role is, why the package ships none, and how to add yours. Until you add some, users cannot be added to territories at all — the role selector has nothing to offer.

This page was part of Setting up the org and is now its own, because it is the one setup step that is a design decision rather than a configuration value. The others have a right answer. This one is your organisation's vocabulary and nobody else can supply it.

These are not the roles you are thinking of

🔴 A territory role is not a Salesforce role.

The same person can be a Regional Director in one territory and an Account Executive in another. That is the whole reason territory roles exist separately.

Why the package ships none

Deliberately. A territory role is your organisation's vocabulary, and inheriting someone else's org chart would be worse than starting empty — you would spend longer deleting ours than writing yours.

The cost of that decision is the one symptom to recognise: **before you define any roles, the Assign users button never enables and nobody can be put into a territory.** That is this step not being done, not a defect.

Adding a role

Setup → Custom Metadata Types → Territory Role → Manage Records → New.

Flat, hierarchical, or both

Parent Role API Name is the only field that decides the shape. Leave it blank on every role and you get a flat list. Fill it in and you get trees. Mix them freely — there is no setting to switch between the two, and no limit on how many trees you have.

Sales                        ← blank parent, Is Assignable unticked
  Sales Manager
    Sales Rep
Operations                   ← blank parent, a second tree
  Dispatcher
Contractor                   ← blank parent, no children: a flat role

Leaving Territory Model Name blank

Blank means the role applies to every territory model you load, which is what almost everyone wants.

It also means your roles survive cloning a territory model, which is how territory realignment normally works. A per-model role set would have to be re-created on every planning cycle.

Fill it in (with a model's Developer Name) only when one model genuinely needs a different set of roles. A model-specific set replaces the org-wide one for that model rather than adding to it.

Functional groups

Setup → Custom Metadata Types → Functional Group → Manage Records.

A functional group is a bucket of roles — Sales, Operations, or however your business divides up. Set Functional Group on each role to place it in one.

Groups are optional, and most of the product works without them. If you define none, the group selector does not appear and nothing on the map stops working.

🔴 One feature does depend on them: "Show by Role". The descendants panel — seeing everything beneath a territory — can group what it lists by role instead of by tree position. That control is disabled whenever no functional group is defined, because it reads its list of roles from the groups rather than from the role catalogue.

So: if Show by Role is greyed out, it is not a permissions problem and not a defect. It is this step.

If you want clean reporting on Role in Territory

The role is stored on the standard Role in Territory field of the user-territory association. That field is a Salesforce picklist with its own separate value set, and it does not learn your role names automatically.

Everything works without doing anything about this — the field accepts your values as they are. But **reports and list views that filter on Role in Territory will not offer your role names as choices. If you need that, mirror them into Setup → Picklist Value Sets → RoleInTerritory2**.

🔴 Do not tick "restrict to defined values" on that picklist unless you have mirrored every role name first. If you do, every attempt to assign a user fails. The app will tell you exactly that when it happens, but it is easier not to hit it.

Next

People, roles and assignment — putting people into territories and giving them these roles, and the entirely separate question of how records reach territories.