Define assignment rules
Match lead fields to ordered rules, preserve a valid existing owner, and choose an eligible rep using weighted assignment.
Route inbound leads with readable rules, weighted rep assignment, and explainable decisions. An open-source application in active development.

This walkthrough illustrates how company size, territory, and rep selection can shape an assignment.
Inspect the routing rules →Preset fictional leads and results. No CRM is connected, no calendar is checked, and no meeting is booked by this example.
Enterprise East
The public application matches ordered rules, preserves an eligible existing owner, and otherwise uses weighted assignment. The rule below comes from its routing tests.
{
"company.employee_count": { "gte": 500 },
"company.state": {
"in": ["NY", "NJ", "PA", "MA"]
}
}
The design problem: assign a qualified lead once, respect an eligible existing owner, and return a clear failure when no one can take it. Matching and rep selection are separate from the database and provider calls, so the core decision can be checked with fixed inputs.
In the public tests, a fictional 900-person New York company arrives Monday at 12:00 UTC. Ada and Marcus each have two assignments; their weights are 2:1, so Ada is selected. Set Marcus as the existing owner and Marcus is preserved. Mark Ada busy and Marcus is selected. On Sunday, outside both reps’ schedules, the same lead returns NoEligibleRepError.
Read the routing function ↗ · Inspect inputs and assertions ↗ · Inspect retry and duplicate-request checks ↗ · View this version’s CI result ↗
The retry failure case: an older owner update fails, a newer assignment succeeds, and the old retry must not undo it. The database check verifies that obsolete work becomes superseded without calling the CRM, and that concurrent owner writes finish in order. These checks use synthetic provider callbacks.
Evidence is pinned to public source 03916c4. These are synthetic routing tests, not measured customer results or proof of a connected CRM or calendar. The animation above remains a separate preset illustration.
These capabilities are available in the linked public source. The illustrations below use fictional records.
Match lead fields to ordered rules, preserve a valid existing owner, and choose an eligible rep using weighted assignment.
Filter reps by weekly schedules. Google free/busy checks require a configured connection; this public version does not book meetings.
Persist the selected rep, matched rule ID, and assignment reason. A repeated request ID returns its existing decision.
The operator view shows the selected rep, matched rule name, and CRM writeback status.
Hot Potato is software you run and configure yourself. This site offers a preset illustration and an inspectable routing case from the public application.
The linked public version covers lead assignment, saved decisions, Google availability checks, and queued HubSpot owner updates. Setup and provider credentials are required for external actions.
Meeting booking, an editable routing studio, and detailed rule/rep previews exist only in later local development. They are not included in the public version linked here. Live provider operation has not been demonstrated by this website.
Explore the application source, read the setup instructions, and inspect its current scope. The routing engine and application are licensed under AGPL-3.0-only.
harrisonoconnorhover/hot-potatoPublicgit clone https://github.com/harrisonoconnorhover/hot-potato.git
Start with the example, then explore the application and its setup requirements.