TerriTool SalesForce Integration


TerriTool is a route optimisation tool for territory sales teams that was initially built for EDI express in an effort to automate the 20 – 30 hour excruciating route creation task each salesmen had to do every month for their monthly accounts. This solution quickly evolved in to a product called ‘TerriTool’ that is currently being sold to territory sales teams as a solution to reduce the amount of time spent creating territory based routes and also manage their day-day sales activities within the product.


Being a system that is tailored for salesmen, it was important for EDI express and also future users of the TerriTool system to have this system integrated in to SalesForce so that they could have data through their main CRM and TerriTool synchronised at all times. Because salesmen would be switching between TerriTool and Salesforce, making changes to their data, we needed to ensure:

  • That data would transfer from TerriTool to Salesforce and vice-versa.
  • All data from TerriTool is transferred to SalesForce, even the fields that were not within SalesForce (Custom Fields via API)
  • Every user is able to connect their own individual salesforce account with their own TerriTool sales account.
  • Fail-Safe scenarios were catered for so that data is always flowing between the two systems.


Since we had built TerriTool and understood the architecture and design of the system, we didn’t need to do a system analysis. However, we did need to go through several user persona’s and processes analysis to really understand the best way way to integrate SalesForce with TerriTool behind it. Working with the stakeholders of TerriToo, we first determined the user personas that would use Salesforce within TerriTool and then worked backwards from there:

  • From the user persona’s we discussed several user stories and use cases, this was the foundation of the data mapping exercise we did next.
  • Next, we mapped how this data would flow in to Salesforce and how data would flow from SalesForce in to TerriTool and determined the custom fields that would need to be created on SalesForce by the integration so that data on TerriTool & SalesForce matched.
  • Lastly, we discussed several scenarios where the API integration could fail and also discussed workarounds.


The custom solution developed for TerriTool was tough as we had to overcome the complexity of 2-way syncs (Logically & Technically) and creating custom fields on SalesForce via the integration. Despite the tough task, we managed to achieve it by implementing rule-based syncs and also taking advantage of deep API integration. This meant that all the data that is on TerriTool was synced to SalesForce (Including fields that did not exist on SalesForce), and data was shared between both systems.

This integration was built to emulate a run-time experience for the sales agents, so every time a change was done in TerriTool or SalesForce, the change would be sent to the other system immediately, either SalesForce or TerriTool depending on the origin system of where the change was made. Using smart development techniques, we used 15-minute crons for API-fail scenarios that would allow a delay in information sent to SalesForce but ensure there was no loss in information on Salesforce. If for some reason there was a failure to send data to SalesForce through the run-time call, we’d acknowledge this in our integration and the integration would then keep trying to send the failed data to SalesForce every 15 minutes until it succeeds.

With this integration, we ensured that we met Territool’s objective and also ensured the integration with Salesforce was reliable and scalable.