Genesys Cloud - Developer Community!

 View Only

Sign Up

  • 1.  Digital Bot Flow calling another Digital Bot Flow — what benefits are you seeing?

    Posted 08-10-2026 08:00

    Olá, pessoal!

    Gostaria de ouvir a experiência de quem já está utilizando a capacidade recente que permite que um Digital Bot Flow chame outro Digital Bot Flow.

    Consigo enxergar alguns benefícios, principalmente em relação à modularização e separação de responsabilidades. Por exemplo, em vez de termos um bot muito grande, podemos criar bots mais especializados, responsáveis por domínios ou partes específicas da jornada do cliente.

    Porém, olhando pela perspectiva de arquitetura e desenvolvimento, neste momento alguns desafios estão me chamando mais atenção do que os benefícios.

    O primeiro é a rastreabilidade.

    Quando começamos a ter uma jornada como:

    Inbound Message Flow
    → Digital Bot A
    → Digital Bot B
    → Digital Bot C
    → Digital Bot D

    o troubleshooting pode ficar consideravelmente mais complexo. Entender onde uma variável foi alterada, onde uma intenção foi identificada, qual versão de determinado bot foi executada ou exatamente em qual ponto o cliente seguiu um caminho inesperado pode exigir navegar por diversos flows.

    Minha segunda preocupação é a profundidade da jornada e a complexidade arquitetural.

    Tecnicamente, permitir que um bot chame outro é bastante útil. Mas até qual profundidade devemos permitir que essa hierarquia cresça?

    Em algum momento, modularização pode acabar se transformando em fragmentação.

    Por exemplo:

    Digital Bot A
    → Bot B
    → Bot C
    → Bot D
    → Bot E...

    Mesmo que cada bot individualmente esteja bem construído, a jornada completa pode começar a ficar difícil de compreender, testar, documentar, investigar e manter.

    Isso também me trouxe algumas perguntas de arquitetura:

    • Vocês estão definindo uma profundidade máxima interna para chamadas entre bots?

    • Como estão documentando as dependências entre os Digital Bot Flows?

    • Como estão tratando versionamento quando um bot depende de vários outros?

    • Como estão rastreando a jornada completa de um cliente através de múltiplos bots?

    • Estão utilizando essa funcionalidade principalmente para componentes reutilizáveis ou para construir jornadas completas compostas por vários bots?

    • Como estão tratando uma alteração em um subflow que pode impactar vários bots que dependem dele?

    Particularmente, acho a capacidade poderosa, mas também vejo o risco de ambientes complexos se tornarem mais difíceis de manter caso não existam bons padrões de arquitetura e governança.

    Por isso, fiquei curioso:

    Quais benefícios reais vocês já encontraram utilizando a orquestração entre Digital Bot Flows?

    E, principalmente:

    Quais práticas ou limites arquiteturais estão adotando para evitar que a modularização se transforme em complexidade excessiva?

    Gostaria muito de conhecer exemplos de outras implementações.

    _______________________________________________________________________________________________________________________________________________________________________

    Hi everyone,

    I would like to hear how others are using the recent capability that allows a Digital Bot Flow to call another Digital Bot Flow.

    I can definitely see some potential benefits, especially around modularization and separation of responsibilities. For example, instead of building one very large bot, we could have more specialized bots responsible for specific domains or parts of the customer journey.

    However, from an architecture and development perspective, I currently see some challenges that concern me more than the benefits.

    The first one is traceability.

    When a journey becomes something like:

    Inbound Message Flow
    → Digital Bot A
    → Digital Bot B
    → Digital Bot C
    → Digital Bot D

    troubleshooting can become significantly more complex. Understanding where a variable changed, where an intent was detected, which version of a bot was executed, or exactly where the customer took an unexpected path may require navigating through several flows.

    My second concern is journey depth and architectural complexity.

    Technically, being able to call another bot is useful, but how deep should we allow these hierarchies to become?

    At some point, modularization can turn into fragmentation.

    For example:

    Digital Bot A
    → Bot B
    → Bot C
    → Bot D
    → Bot E...

    Even if each bot is individually well designed, the overall customer journey can become difficult to understand, test, document, troubleshoot, and maintain.

    It also raises some architecture questions for me:

    • Do you define an internal maximum depth for bot-to-bot orchestration?

    • How are you documenting dependencies between bots?

    • How do you handle versioning when one bot depends on several other bots?

    • How are you tracing a customer journey across multiple Digital Bot Flows?

    • Are you using bot-to-bot calls mainly for reusable capabilities, or are you using them to build complete multi-bot journeys?

    • What happens when a subflow changes independently and affects multiple parent bots?

    Personally, I think this capability is powerful, but I also feel that without strong architecture and governance standards it could make complex environments harder to maintain.

    So I am curious:

    What real benefits have you found so far with Digital Bot Flow orchestration?

    And more importantly:

    What architectural practices or limits are you putting in place to prevent modularization from becoming excessive complexity?

    I would really like to hear examples from other implementations.


    #Architect
    #WebMessaging

    ------------------------------
    Matheus Mendonca
    ------------------------------


  • 2.  RE: Digital Bot Flow calling another Digital Bot Flow - what benefits are you seeing?

    Posted 08-10-2026 09:34

    Hi Matheus,

    We've implemented a fairly simple use case for this in production.

    We have a production Digital Bot Flow with multiple service menus, covering areas such as MFA, passwords, software and other support enquiries. Using Flow Outcomes, we identified that some customers were still requesting an agent after hours when they couldn't resolve their issue through self-service.

    Before escalating to an agent, we now perform a schedule check. If the customer is contacting us after hours, the main bot calls our existing after-hours callback Digital Bot Flow, which allows the customer to schedule a callback for the next business day.

    So our journey is relatively shallow:

    Main Digital Bot → Agent requested → Schedule check → After-hours Callback Bot

    The main benefit for us is reuse without duplicating the callback journey inside our production bot. The callback bot has a clearly defined responsibility and can remain separate from the different service journeys in the main bot.

    I do agree with your concern around depth though. For our use case, keeping bot-to-bot orchestration shallow and using it for clearly defined reusable capabilities makes sense. I would be cautious about creating long Bot A → B → C → D chains, as troubleshooting and understanding the overall customer journey could quickly become difficult.

    In our case, Flow Outcomes also helped identify the customer journey gap that led us to introduce this orchestration in the first place.

    Interested to see how others in the Community are using bot-to-bot orchestration and what approaches they are taking around depth, governance and troubleshooting.



    ------------------------------
    Phaneendra
    Technical Solutions Consultant
    ------------------------------



  • 3.  RE: Digital Bot Flow calling another Digital Bot Flow - what benefits are you seeing?

    Posted 08-10-2026 15:02
    Olá! Suas perguntas são muito pertinentes e tocam exatamente no ponto crucial de como evoluir uma arquitetura de bots de forma sustentável. A capacidade de um Digital Bot Flow chamar outro é realmente um avanço significativo, pois permite quebrar bots monolíticos em componentes especializados e reutilizáveis, mas, como você bem observou, essa modularização traz consigo desafios reais de governança, rastreabilidade e manutenção. A boa notícia é que, pelo que já é possível ver na documentação e em discussões da comunidade, você não está sozinho nessas preocupações, e vamos explorar como algumas dessas questões estão sendo tratadas.
     
    A preocupação com a rastreabilidade é a mais imediata, porque quando uma jornada atravessa múltiplos bots, entender o fluxo exato e os valores das variáveis em cada etapa se torna mais complexo. Para mitigar isso, a plataforma oferece algumas ferramentas que podem ser usadas em conjunto. A primeira delas é o Histórico de Execução de Fluxos, que é uma ferramenta essencial para depuração, pois permite que você veja a execução passo a passo de uma interação, inclusive em subfluxos. No entanto, é importante estar ciente de uma limitação crucial: o histórico de execução pode ser perdido se sua interação ultrapassar 350 variáveis combinadas no fluxo. Para contornar essa limitação e ter um registro mais permanente, uma prática comum é usar a ação Set Participant Data em pontos-chave da jornada, o que permite salvar valores importantes, como o resultado de uma ação de dados ou a decisão de um bot, diretamente nos detalhes da interação. Dessa forma, mesmo que o histórico de execução não esteja disponível, você pode consultar os dados salvos para entender o que aconteceu, e a comunidade tem usado essa abordagem como uma alternativa eficaz para rastrear o caminho do cliente. Além disso, para uma análise mais focada no comportamento do bot em si, a funcionalidade Utterance History no Optimization Dashboard permite filtrar interações por ação ou resultado, ajudando a identificar onde um fluxo de sub-bot pode ter falhado ou se comportado de forma inesperada.
     
    A preocupação sobre como documentar e gerenciar dependências é outro ponto acertado, e a plataforma tem evoluído para ajudar nisso através da funcionalidade Dependency Search no Architect. Com ela, você pode pesquisar todos os fluxos publicados que dependem de um recurso específico, como uma fila, uma ação de dados ou um bot flow, o que é fundamental para avaliar o impacto de uma mudança. Por exemplo, antes de atualizar um sub-bot, você pode usar essa ferramenta para listar todos os bots "pai" que o chamam e verificar quais versões estão em uso, lembrando que esta pesquisa funciona apenas para fluxos já publicados, não para versões em desenvolvimento. Aqui reside um dos maiores desafios práticos: um ponto importante a considerar é que, ao chamar um sub-bot com a ação Call Digital Bot Flow, você atualmente não pode selecionar uma versão específica do sub-bot para chamar, pois a ação sempre utilizará a versão publicada mais recente do fluxo. Isso significa que publicar uma nova versão de um sub-bot afetará imediatamente todos os bots que o chamam, sem que seja necessário atualizá-los, e essa limitação de versionamento força uma abordagem mais cuidadosa para o desenvolvimento, como você já desconfiava.
     
    A prática mais recomendada pela comunidade para lidar com isso é não atualizar o sub-bot diretamente, mas sim criar uma cópia dele usando a opção Save As para desenvolver e testar suas alterações. Ao final do desenvolvimento, você pode substituir o sub-bot original pela nova versão ou, alternativamente, atualizar a ação no fluxo "pai" para que ele aponte para a cópia do sub-bot recém-criada e testada. Essa abordagem de cópia e substituição, ou redirecionamento, é a única maneira de testar mudanças em sub-bots sem impactar fluxos em produção que deles dependem.
     
    Sua intuição sobre a necessidade de estabelecer limites arquiteturais está correta, e embora não haja um limite máximo oficial de profundidade documentado, cada chamada de bot adiciona complexidade. Com base nos desafios mapeados, algumas práticas arquiteturais podem ajudar a evitar que a modularização se transforme em fragmentação. A primeira é definir um limite de profundidade claro para sua equipe, por exemplo, permitindo que um "bot orquestrador" chame "bots de domínio", mas que estes não chamem outros bots, mantendo a profundidade máxima em dois ou três níveis, o que facilita a rastreabilidade e o gerenciamento de dependências. A segunda é diferenciar claramente os bots que atuam como orquestradores, que gerenciam o fluxo geral da conversa, daqueles que atuam como especialistas, que realizam tarefas específicas como coleta de dados, verificação de identidade ou pesquisa de informações, ajudando a manter cada bot com uma responsabilidade única e bem definida. A terceira é manter uma documentação viva, como uma wiki ou um diagrama, que mapeie todos os bots e suas dependências, usando a ferramenta Dependency Search para validar essa documentação periodicamente. A quarta é adotar a prática de criar cópias dos sub-bots para desenvolvimento e testes, como descrito anteriormente, para evitar que mudanças em desenvolvimento impactem a produção acidentalmente, sendo que a decisão final sobre quando usar a cópia ou substituir o original deve ser deliberada e acompanhada da devida análise de impacto. A quinta é implementar um processo de governança que exija que qualquer mudança em um sub-bot seja precedida de uma análise de impacto, identificando quais "bots pai" serão afetados.
     
    Concordo com sua visão de que a funcionalidade é muito poderosa, mas traz responsabilidades arquiteturais. Parece que o caminho não é evitar seu uso, mas sim adotá-lo com disciplina, definindo regras claras de governança, profundidade, versionamento e rastreabilidade desde o início. As ferramentas para lidar com a complexidade existem, mas exigem um esforço consciente de design para serem usadas de forma eficaz.


    ------------------------------
    Camila Meneghini
    ------------------------------



Related Content