When does agent/queue association change?


New Member
Hello all,

I have been working on integrating FusionPBX with our own QueueMetrics Live platform, and so far it is working pretty well. I am able to track agents logging on and off and pausing themselves over ESL events, and this is enough to provide agent tracking and agent actions to our platform (see https://manuals.loway.ch/Uniloader-chunked/ch07.html if interested in how it works).

The problem I'm having is that at the ESL level I get events that an agent "starts working", but I have no information on which queues they are supposed to work on. So this requires a separate dip into the database to pull the configuration of queues and agents and keep it in sync within QueueMetrics. But I was thinking that if I was to do the database dip when an agent start working I could know for sure on which queues they are currently available.

My question is: what happens if someone changes agent/queue association from the GUI while an agent is working? e.g. you are supposed to work on queue "A", you log on (and are working on queue A) and then when you are logged on your supervisor also sets you on queue B. Do you immediately get calls from B, or do you have to log off and log on again first?

Another thing: is there a trigger of sorts that one can use to know that a specific queue, or a tenant's configuration, was changed, as to allow caching while said configuration has not changed?



Aug 25, 2019
If an agent is assigned to multiple queue's when that agent logs in they are logged into all queue's. Do you have separate agent logins for each user for each queue?

Or are you saying if the supervisor add's an agent to a queue they are not already a part of? In which case that queue may need a restart from my experience.

BTW - I'm using queuemetrics as well so pretty interested to hear if you can get this working. The team at queuemetrics im sure would be more than happy to help out as well.


New Member
Or are you saying if the supervisor add's an agent to a queue they are not already a part of? In which case that queue may need a restart from my experience.

So a queue won't change until the agent gets logged off and on again?

If that's so, I think it could be implemented so that when an agent logs in, the Uniloader queries the database for their current queue associations, and outputs those as a series of ADDMEMBER records - this way you can see the set of queues an agent is supposed to work on. Pauses and unpauses do not require such information, and we could output a custom closure record for when they log off that just means "leave all queues".

This would require less aggresive resyncing of QueueMetrics - ATM we do this daily with Uniloader, so that any new agents are created, appear with their current name and have their UUID set so that they can log on and log off. The way we do it is by scripting an Ansible task, where uniloaders are installed (on a separate server) to pull data from all the members of the Fusion cluster, rewrite it and send it t the correct QMLive instance for each customer: see https://github.com/Loway/OpenQueueMetricsAddOns/tree/master/ansible-fusionpbx

The agent page would still work - you'd see all queues visible to an agent, when they log in one of them, all of them log in, and vice-versa.