Salesforce Territory Management Customization
Quoting Salesforce : “Salesforce Territory Management allows territories to be defined through a set of rules. Classifying sales reps, sales managers, opportunities, and customers by territory, gives another way to sort CRM data and gives executives a better picture of the business by area.”
Having unbalanced territories can cause many problems. Some of these include the unfair distribution of sales potential amongst the sales force, distorted compensation amongst sales reps and, reps leaving the company to seek out better balance and compensation elsewhere.
In essence, if you’re going to use Salesforce territory management, you had better get it right.
So, what do you do in a situation where you need to implement territory management, but the default capabilities of Enterprise Salesforce territory management do not align with your business processes, and as such, will not be enough to meet the needs of your company?
Having unbalanced territories can cause many problems. Some of these include the unfair distribution of sales potential amongst the sales force, distorted compensation amongst sales reps and, reps leaving the company to seek out better balance and compensation elsewhere.
In essence, if you’re going to use Salesforce territory management, you had better get it right.
So, what do you do in a situation where you need to implement territory management, but the default capabilities of Enterprise Salesforce territory management do not align with your business processes, and as such, will not be enough to meet the needs of your company?
This was the case with our client “Tilequip” - (real company name withheld in line with signed NDA).
Our client’s customization requests
Tilequip manufactures and sells tile production equipment and spare parts in major tile producing countries around the world. These were their requests:
- When a new account or lead is created, regardless of who creates it, the account owner should be set to one of the users assigned to the territory. Territories for accounts and leads are specified by zip codes.
- In territories with 2 or more assigned users:
- If there are more than 1 sales representatives assigned to the same zip code, we assign sales representatives evenly.
- If a new user is added to a region, we assign him records until he has a number equal to the average number of records of the other users in the territory for the last month, and then, continue distributing to all the users evenly.
How we implemented the Territory management customization in Salesforce
We wrote Apex code which changes the owner id in accounts and leads. The code runs in the background when a new account or lead is created.
The apex code checks the record, and changes the owner id to the correct owner, who is assigned to the record’s territory (Billing/ shipping address for account and .
The actual responsible person for each territory is taken from Territory Models, so it was first configured there.
When a user creates an account or lead, our code sets a service flag in the record which prohibits the record from being edited until our apex code checks it for the current ownerID and sets the correct owner for the territory.
Let’s see an example:
Tim, the head of Tilequip Sales in NewYork attends a conference in Houston,
where he meets the CEO of Marazzi. He creates an account. Marazzi’s HQ is located in Sassuolo, Italy.
Tim doesn’t know what team is in charge of Sassuolo, but he finds the Zip code of the company and indicates this on the account.
As soon as he saves the account, our code places a special flag on the handler of the account, to process and prohibit editing the record. This is necessary so that during the change of the ownerid, the user does not break the application.
Then, our code checks the zip code of the new account against the assigned owner. It changes the account owner from Tim to Rosa, who is the sales agent assigned to Sassuolo.
After this, all other record access settings apply, and Tim is no longer able to view the Marazzi account.
Our Apex code runs on an hourly schedule. It goes through all records that have this special flag every hour and compares their zip codes with the rules in territory Models.
Following the rules from territory models, it creates a list of users responsible for the different territories and then, selects the least loaded user in the last month and assigns them as the new record owner.
This solves the problem of unequal workload distribution between old and new employees.
If there were 2 users originally assigned to a territory with 100 accounts/leads each, and then a new agent is assigned to the territory. What happens?
Since our code checks for workload for the last month, the new agent will not receive the next 100 leads. Rather, he will receive them on par with the old users.
After a new owner is assigned to the record, the service flag that forbade editing the record is removed.
This evaluation and owner assignment is carried out ONLY once. The process is not repeated every time the record is updated.
The apex code checks the record, and changes the owner id to the correct owner, who is assigned to the record’s territory (Billing/ shipping address for account and .
The actual responsible person for each territory is taken from Territory Models, so it was first configured there.
When a user creates an account or lead, our code sets a service flag in the record which prohibits the record from being edited until our apex code checks it for the current ownerID and sets the correct owner for the territory.
Let’s see an example:
Tim, the head of Tilequip Sales in NewYork attends a conference in Houston,
where he meets the CEO of Marazzi. He creates an account. Marazzi’s HQ is located in Sassuolo, Italy.
Tim doesn’t know what team is in charge of Sassuolo, but he finds the Zip code of the company and indicates this on the account.
As soon as he saves the account, our code places a special flag on the handler of the account, to process and prohibit editing the record. This is necessary so that during the change of the ownerid, the user does not break the application.
Then, our code checks the zip code of the new account against the assigned owner. It changes the account owner from Tim to Rosa, who is the sales agent assigned to Sassuolo.
After this, all other record access settings apply, and Tim is no longer able to view the Marazzi account.
Our Apex code runs on an hourly schedule. It goes through all records that have this special flag every hour and compares their zip codes with the rules in territory Models.
Following the rules from territory models, it creates a list of users responsible for the different territories and then, selects the least loaded user in the last month and assigns them as the new record owner.
This solves the problem of unequal workload distribution between old and new employees.
If there were 2 users originally assigned to a territory with 100 accounts/leads each, and then a new agent is assigned to the territory. What happens?
Since our code checks for workload for the last month, the new agent will not receive the next 100 leads. Rather, he will receive them on par with the old users.
After a new owner is assigned to the record, the service flag that forbade editing the record is removed.
This evaluation and owner assignment is carried out ONLY once. The process is not repeated every time the record is updated.
Before customization:
- The owner of a record does not change to one of the users assigned to the record’s territory automatically.
2.You could not define how workload should be distributed to new users who are assigned to a territory
After Customization:
- Record owners are automatically changed to one of the users assigned to the territory
2.Workload is distributed to new members of territories according to a custom rule.
RIBERATEC can help you customise Salesforce according to your industry or company needs.
We have 20+ years of experience in IT technologies.
RIBERATEC can help you customise Salesforce according to your industry or company needs.
We have 20+ years of experience in IT technologies.