Territory Management in CRM Analytics

Using the Territory hierarchy for row-level security in CRM Analytics is a popular request. If you’ve previously done this in CRMA, you’ve probably come across Darshna Sharma’s fantastic blog.

Good news: In Winter ’25, we’re making things easier than ever.

Let’s start with the Pre Winter ’25 Approach

Without going into too much detail, here are a few things regarding the current approach.

• The Territory Object and Territory2Association objects are used to find out the list of users who are part of the territory hierarchy.
• The number of joins is equal to the number of territories levels.
• The final output will have the list of user IDs at each level.

Security predicate for a 7-level territory hierarchy:

'Territory.users.N_0.UserId' == "$User.Id" || 
'Territory.users.N_1.UserId' == "$User.Id" || 
'Territory.users.N_2.UserId' == "$User.Id" || 
'Territory.users.N_3.UserId' == "$User.Id" || 
'Territory.users.N_4.UserId' == "$User.Id" || 
'Territory.users.N_5.UserId' == "$User.Id" || 
'Territory.users.N_6.UserId' == "$User.Id" || 
'Territory.users.N_7.UserId' == "$User.Id" || 

Why is the above approach necessary?

Let’s look at the syntax of a security predicate:

<dataset column> <operator> <value>

<dataset column> – A column/field in the dataset.
<value> – A number, string, or column in the User object.

Territory ID is not part of the user object by default. That is why it is necessary to have a column in the dataset with the list of users (ID) who have access to that row, which is then compared to the logged-in user in the security predicate.

Whats changing in Winter’25?

We are expanding the security predicate beyond the user object. To start with, We are opening up for Territory Hierarchy.

Let’s consider this new syntax:

<dataset column> <operator> <value> or ["$UserTerritory2Ids"]

<Value> will still be a number, string, or column in the User object. We can now also provide
["$UserTerritory2Ids"], which will be dynamically resolved to the territories the user belongs to.

All we have to do now is add a column to the dataset that contains a list of territories with whom the source record is shared. So, the recipe described in part 2 will be simplified as follows.

Just flattening the territory hierarchy and joining with the record source.

Reducing the number of joins, columns, and multi-values will result in faster Recipes and Dataflows.

I hope this simplifies the whole process of inheriting Territory security from Core to CRM Analytics. If you have more questions on this, please do let me know in the comments.

Written by

Chocks Kandasamy

See author's posts