Round robin

This guide covers our ticket round robin, an automation system that performs the assignment of tickets based on specific criteria.

Understanding our ticket round robin

How it works

Before each job runs, it performs a few actions to setup the image to perform the needed actions:

• Clones the repo at support-team to data/support-team
• Output the response from running the command ruby -v
• Install the bundler gem
• Run the bundle command
• Put the values of the environment variable SERVICE_CREDS into the file data/config.json

After this, the ./bin/round_robin script is executed.

Using a pre-made view, the script will get a list of tickets to round robin. If there are no tickets, the script will exit with a status code of 0.

The script will then determine the currently available agents by checking the support-team information, remove any agents on PTO, and remove any agents not currently within working hours. In the event no agents are available, it will post a notification to a Slack control via a Support controlled Slack incoming webhook (and exit with a status code of 0).

Using the list of currently available agents, it will then determine the current workloads of said agents (this is done by looking at assigned tickets with a status lower than solved) using the Ticket Weight field on the tickets it locates (a numeric value dictating the complexity of a ticket).

After gathering the tickets in need of being round robin’d (using the Not round robined view), the script will then assign them out to the agent with the lowest workload (incrementing their workload by 1).

Administrator tasks

Modifying the round robin

To modify the round robin, you will need to create a MR in the project repo. The exact changes being made will depend on the request itself.

After a peer reviews and approves your MR, you can merge the MR. Once merged, it will be used on the next scheduled pipeline run.

Common issues and troubleshooting

This is a living section that will have items added to it as needed.