In Support, we have an automated ticket distribution system. It's built using LaunchDarkly's percentage rollout feature.
Zendesk
When a ticket comes into Zendesk, it pings a Heroku server running an app built by John Winstead, our Senior Support Engineer.
The Heroku App
This script written in Node.js processes the “capacitor” (more on that below) calculations.
This is hosted on GitHub and is hooked up to a Heroku instance, and then feeds into a Redis cache.
The script then sends requests to the Zendesk API and calls the customized feature flag that utilizes the percentage rollout.
It is also connected to the Node SDK that calls variationDetail to check what rule says the user matches based on rule_match instead of following the default rule.
The Automatic Ticket Distribution Flag
As you can see in the screenshot, we have set up each variation for adjustable distribution through percentage rollout.
One could just use the SDK directly to evaluate this flag using the tickets ID as the users key and in bulk; the distribution would be even. This is the way we originally distributed tickets.
The only problem is that since the percentage rollout is TRULY random, it isn't uncommon to see some agents receive no tickets for a period of time, or see one agent receive nearly all of the tickets for a period of time.
Because of this, we use the configured percentage rollouts in conjunction with custom distribution logic rather than using the SDKs evaluation logic.
When a Zendesk ticket is created, Zendesk sends a webhook to our Heroku app.
The Heroku server keeps a “capacitor” variable for each agent. These variables are persisted in Redis so that the server can be restarted without losing the value of these variables.
When the Heroku app receives the webhook, it increases each agent's “capacitor” variable by the percentage attributed to them in the configuration dashboard.
Using the above screenshot as a reference, the capacitor for the variation Bonnie would be incremented by 10 while the capacitors for variations Leo, JW, and Jennifer would all be incremented by 30.
The ticket then gets assigned to whoever has the highest value, and that variation has their “capacitor” variable reset to 0, while the others remain the same.
These values are persisted in Redis and used as starting values the next time the Heroku server receives a webhook.
Future considerations
Everything on here was devised by John Winstead, a senior support engineer on our team. There are plans to expand upon utilizing LaunchDarkly for other internal automation tools. Stay tuned!
.webp)
