Se considerarmos o evento de indisponibilidade que houve, na ocasião não seria viável a utilização da tabela de dados, pois pelo menos aqui, ninguém estava conseguindo logar e aqueles que estavam logados, não conseguiam mudar de página.
Para "derrubar" (tirar de oferta) muita gente de uma vez, o caminho prático é via API. O que funciona, na prática, são dois "botões de pânico" diferentes:
-
"Desligar as linhas" (lado de entrada do fluxo)
- Ative um Emergency Group vinculado às rotas de Call Routing. Com isso, todos os DIDs continuam recebendo chamadas do carrier, mas a roteirização é desviada para um fluxo de contingência (mensagem, VM, fallback etc.) sem depender do status dos agentes. Dá pra ativar/desativar via UI ou API (Data Action/Workflow): PUT /api/v2/architect/emergencygroups/{emergencyGroupId} setando enabled=true/false. É o failsafe mais rápido para incidentes de ACD.
-
"Derrubar agentes" (lado do agente)
- Use PUT /api/v2/users/{userId}/routingstatus para colocar agentes em OFF_QUEUE (ou IDLE). Por design, você não consegue forçar estados como INTERACTING/NOT_RESPONDING; os estados manualmente setáveis são limitados. Para presença (Available/Away/Busy/Offline), use PATCH /api/v2/users/{userId}/presences/{sourceId} - observando que, desde 20/jul/2025, mudar a presença de outro usuário exige a permissão presence:userPresence:edit. Não há endpoint "bulk"; você precisa iterar a lista de usuários (ou orquestrar com Workflow/Triggers + Data Action).
Mas, durante o evento de falha que vivenciamos recentemente, por algum tempo, não seria possível resolver o seu problema. No apagão da AWS em out/2025, parte da dor foi justamente DNS/"acesso"; quando isso acontece, a própria API pode ficar intermitente ou indisponível. Nesse cenário, você precisa de um "plano B" fora do Genesys.
------------------------------
Fernando Sotto dos Santos
ConsultorVIA VAREJO
------------------------------