Genesys Cloud - Developer Community!

Hello @Adriaan Bogaerts, saudações do Brasil.

There is currently no native alert or trigger in Genesys Cloud that evaluates agent proficiency levels directly (for example, "number of agents logged in with 5-star proficiency on a given skill"). Proficiency is used for routing decisions, but it is not exposed as a condition for alerts or triggers.

That said, one possible workaround is to separate primary and backup agents at the queue level purely for monitoring purposes. For example:

• Assign primary agents (those with maximum proficiency) to an auxiliary or "monitoring" queue.

• Assign backup agents to a different auxiliary queue.

• Both primary and backup agents can still remain members of the main production queue that receives interactions.

With this setup, you can create queue-based alerts that monitor the number of logged-in or available agents in the primary agents queue. When that number drops below a defined threshold, an alert can be triggered.

This approach does not change your actual routing strategy; it only provides a way to approximate proficiency-based monitoring using queue membership, which is supported by the alerting framework.

Regarding alert frequency, Genesys alerts allow you to configure notification intervals and suppression behavior, so you can limit how often email notifications are sent during the day.

While not ideal, this pattern aligns with current platform capabilities and avoids unsupported logic around proficiency-based alerting.

Great! Thanks Fernando. I think I'll schedule some API and powershell to get the correct agents and check their status.

Asking user management to manage those monitoring queues is prone for errors.

Hello @Adriaan Bogaerts, saudações do Brasil.

There is currently no native alert or trigger in Genesys Cloud that evaluates agent proficiency levels directly (for example, "number of agents logged in with 5-star proficiency on a given skill"). Proficiency is used for routing decisions, but it is not exposed as a condition for alerts or triggers.

That said, one possible workaround is to separate primary and backup agents at the queue level purely for monitoring purposes. For example:

• Assign primary agents (those with maximum proficiency) to an auxiliary or "monitoring" queue.

• Assign backup agents to a different auxiliary queue.

• Both primary and backup agents can still remain members of the main production queue that receives interactions.

With this setup, you can create queue-based alerts that monitor the number of logged-in or available agents in the primary agents queue. When that number drops below a defined threshold, an alert can be triggered.

This approach does not change your actual routing strategy; it only provides a way to approximate proficiency-based monitoring using queue membership, which is supported by the alerting framework.

Regarding alert frequency, Genesys alerts allow you to configure notification intervals and suppression behavior, so you can limit how often email notifications are sent during the day.

While not ideal, this pattern aligns with current platform capabilities and avoids unsupported logic around proficiency-based alerting.

Great! Thanks Fernando. I think I'll schedule some API and powershell to get the correct agents and check their status.

Asking user management to manage those monitoring queues is prone for errors.

Hello @Adriaan Bogaerts, saudações do Brasil.

There is currently no native alert or trigger in Genesys Cloud that evaluates agent proficiency levels directly (for example, "number of agents logged in with 5-star proficiency on a given skill"). Proficiency is used for routing decisions, but it is not exposed as a condition for alerts or triggers.

That said, one possible workaround is to separate primary and backup agents at the queue level purely for monitoring purposes. For example:

• Assign primary agents (those with maximum proficiency) to an auxiliary or "monitoring" queue.

• Assign backup agents to a different auxiliary queue.

• Both primary and backup agents can still remain members of the main production queue that receives interactions.

With this setup, you can create queue-based alerts that monitor the number of logged-in or available agents in the primary agents queue. When that number drops below a defined threshold, an alert can be triggered.

This approach does not change your actual routing strategy; it only provides a way to approximate proficiency-based monitoring using queue membership, which is supported by the alerting framework.

Regarding alert frequency, Genesys alerts allow you to configure notification intervals and suppression behavior, so you can limit how often email notifications are sent during the day.

While not ideal, this pattern aligns with current platform capabilities and avoids unsupported logic around proficiency-based alerting.

Hello @Adriaan Bogaerts, saudações do Brasil.

There is currently no native alert or trigger in Genesys Cloud that evaluates agent proficiency levels directly (for example, "number of agents logged in with 5-star proficiency on a given skill"). Proficiency is used for routing decisions, but it is not exposed as a condition for alerts or triggers.

That said, one possible workaround is to separate primary and backup agents at the queue level purely for monitoring purposes. For example:

• Assign primary agents (those with maximum proficiency) to an auxiliary or "monitoring" queue.

• Assign backup agents to a different auxiliary queue.

• Both primary and backup agents can still remain members of the main production queue that receives interactions.

With this setup, you can create queue-based alerts that monitor the number of logged-in or available agents in the primary agents queue. When that number drops below a defined threshold, an alert can be triggered.

This approach does not change your actual routing strategy; it only provides a way to approximate proficiency-based monitoring using queue membership, which is supported by the alerting framework.

Regarding alert frequency, Genesys alerts allow you to configure notification intervals and suppression behavior, so you can limit how often email notifications are sent during the day.

While not ideal, this pattern aligns with current platform capabilities and avoids unsupported logic around proficiency-based alerting.