01 Dec 2022
One of my favorite coding projects from work to use as a teaching tool has pertained to the way our sales representatives divide their territories.
The teaching example
- Amjit Anush covers A-M inside the United States.
- Benita Borges covers A-M outside of the United States.
- Cathy Combs covers N-Z inside France.
- Darweesh Daher covers N-Z outside of France.
The real world
In real life, prospective customers actually get assigned two representatives at a time:
- a sales representative
- a billing assistance representative
There are dozens of representatives on staff.
There are dozens of branches to the territory logic (and it’s different for sales vs. billing representatives). Considerations also include:
- the customer’s prior experience level with our product
- the customer’s connections to the U.S. military
- not only the customer’s geographic location, but their citizenship
- geographic splits not only by country, but all the way down to zip code
- not all names start with the 26 letters of the English alphabet
- …and more
In real life, sales rep territory assignment where I work is a beast of a flowchart!
- Q: And what’s even more fun?
- A: The rules change once or twice a year as staff join and leave the company.
Find your sales rep webpage
My company’s public-facing corporate webpage hosts a “find your sales rep” webpage that looks something like this:
(Note: the submit button is deliberately disabled in this example.)
The result of clicking “Find my sales rep” displays something like this:
(imagine a smiling photo of Benita here)
We’re powering this web page by letting the webpage’s form make HTTP calls to a “REST API” hole we poked into our Salesforce instance.
Here’s some sample code for such an API, which can be powered by a reusable implementation of the sales rep territory assignment flowchart (like an Apex Class or an Autolaunched Flow).
Request more information webpage
My company’s public-facing corporate webpage hosts a “request more information” webpage that asks potential customers to submit more detailed information about themselves, such as:
- email address
- physical mailing address
Every time a visitor submits this form, we create (or find and edit) 3 Salesforce records to capture the details they submitted:
- a Contact record
- a parent Account record for the contact
- a child Opportunity record for the contact (via OpportunityContactRole)
We make sure that we always set the value of the
OwnerId field on each of these 3 records using the same “sales rep territory” logic I’ve described in this article.
We have 3 Apex triggers – one on Contact, one on Account, and one on Opportunity.
(Or 3 Record-Triggered Flows – we’re in the middle of playing around with whether Apex or Flow is a better trigger mechanism.)
Each of these 3 uses the same logic as the other for setting
OwnerId. This makes all 3 great candidates to be powered by a shared, reusable implementation of the sales rep territory assignment flowchart (like an Apex Class or an Autolaunched Flow).
In fact, they can all be powered by the same one that powers the “find your sales rep” web page!
That said, as of 2022, Record-Triggered Flows that run in the efficient “before” state can’t delegate their work to Apex or other Flows, so the 3 triggers really ought to be Apex triggers, even if the sales rep territory assignment flowchart is implemented with Autolaunched Flow.