Roadmap

Integração com Cloud Secret Manager Ler #

Organizações que utilizam plataformas de nuvem precisam de uma maneira de buscar segredos diretamente do serviço de gerenciamento de segredos do seu provedor de nuvem em tempo de execução, evitando a duplicação de credenciais e aproveitando as políticas de rotação existentes. Este recurso adiciona integrações nativas com AWS Secrets Manager e Azure Key Vault como recursos exclusivos do Enterprise.

Enterprise #

• Integração com AWS Secrets Manager — busca segredos em tempo de execução do AWS Secrets Manager usando roles IAM, chaves de acesso ou roles assumidos. Suporta segredos estruturados em JSON com extração de campos e rotação automática. (#2248)
• Integração com Azure Key Vault — busca segredos em tempo de execução do Azure Key Vault usando identidade gerenciada ou autenticação por principal de serviço. Suporta segredos, chaves e certificados com rotação automática. (#2248, #3170)
• Cache de Segredos — reduz chamadas de API para provedores de nuvem armazenando em cache na memória os segredos resolvidos.

Cache Persistente de Repositório #

Atualmente, o Semaphore clona (ou faz pull) o repositório em um diretório separado para cada modelo de tarefa, o que pode ser lento para repositórios grandes e desperdiça I/O de disco. Este recurso adiciona uma flag por repositório que alterna para um clone compartilhado e persistente, atualizado periodicamente em segundo plano — semelhante à forma como o AWX gerencia atualizações de projetos. Quando ativado, todos os modelos que referenciam o repositório compartilham uma única cópia de trabalho (o mesmo modelo já utilizado para repositórios locais no Semaphore), e as execuções individuais de tarefas não disparam mais um clone ou pull.

Community #

• Flag “Cache Repository” nas configurações do Repositório — adiciona um botão de alternância em cada repositório que, quando ativado, mantém um único clone persistente em vez de clonar por execução de tarefa. O clone é compartilhado entre todos os modelos que usam o repositório, correspondendo ao comportamento que os repositórios locais já possuem. (#1212)
• Sincronização periódica em segundo plano — quando a flag de cache estiver ativada, faz pull das atualizações em um intervalo configurável (por exemplo, a cada 5 minutos) em um worker em segundo plano em vez de no início da tarefa, para que as tarefas sejam sempre iniciadas instantaneamente com um checkout recente.
• Ação de sincronização manual — fornece um botão “Sincronizar Agora” na interface do repositório e um endpoint de API correspondente para disparar um pull imediato fora do agendamento periódico.
• Resiliência a force-push / reescrita de histórico — trata force-pushes do upstream de forma adequada (por exemplo, git fetch --all && git reset --hard origin/<branch>) em vez de falhar em um pull normal. (#800)
• Recuperação de árvore de trabalho suja — detecta e limpa automaticamente uma árvore de trabalho suja (por exemplo, arquivos .retry remanescentes) antes de fazer pull, prevenindo erros de “alterações locais”. (#308)
• Limpeza de clones obsoletos — coleta de lixo de clones em cache para repositórios que foram excluídos ou cuja URL foi alterada, recuperando espaço em disco. (#1497, #2679)
• Visibilidade do status de sincronização — exibe o timestamp da última sincronização e o status (sucesso/falha) na página de detalhes do repositório para que os usuários saibam quão atualizada está a cópia de trabalho.
• Agendamento de sincronização por repositório — permite substituir o intervalo de sincronização global em repositórios individuais (por exemplo, repositórios com alta rotatividade a cada minuto, repositórios estáveis a cada hora).

Mapeamento de Grupos LDAP e OpenID #

O Semaphore oferece suporte a LDAP e OpenID Connect (OIDC) para autenticação, mas a integração para no login — não há atribuição automática de função ou projeto com base em associações a grupos de provedores de identidade. Cada usuário OIDC/LDAP deve ser atribuído manualmente a projetos e funções após o primeiro login. Além disso, existem múltiplos bugs no tratamento de redirecionamento do OIDC, na análise de claims e na configuração do LDAP que tornam a experiência de autenticação não confiável.

Community #

• Restringir login OIDC por claim — permite que apenas usuários com valores de claim específicos (por exemplo, associação de grupo obrigatória ou domínio de email) façam login. (#2626, #2938)
• Login automático SSO — ignora a tela de login e redireciona diretamente para o provedor OIDC/SSO, com uma URL de recuperação para casos em que o SSO esteja indisponível. (#2548, #2899)
• Suporte OIDC PKCE — adiciona Proof Key for Code Exchange ao fluxo de código de autorização OIDC conforme recomendado pela RFC 9700. (#3072)
• Configuração OIDC por variável de ambiente — permite configurar provedores OIDC por meio de variáveis de ambiente em vez de apenas arquivo de configuração, simplificando o gerenciamento de segredos em contêineres. (#2528, #3120)
• Corrigir redirecionamento OIDC com web_host/web_root — resolve erros 404 após o login OIDC quando web_host está vazio ou web_root está definido como um subcaminho. (#2681, #1524, #2532, #3121)
• Corrigir tratamento de claims OIDC — resolve problemas com username_claim sendo ignorado, claim email não sendo reconhecido e client_secret_file produzindo solicitações malformadas. (#1731, #2818, #3122)
• Corrigir expressões de claim LDAP — resolve expressões de template quebradas no mapeamento LDAP (por exemplo, mail | {{ .username }}@domain.com resolvendo para <no value>). (#3127)
• Corrigir atribuição de nome de usuário LDAP — garante que os usuários LDAP obtenham seu nome de usuário LDAP real em vez de uma string gerada aleatoriamente. (#3688)
• Fallback de autenticação local LDAP — permite que contas de administrador local ainda façam login quando o LDAP está ativado, evitando bloqueio se o servidor LDAP estiver indisponível. (#1363)
• Log de depuração LDAP — adiciona saída de log útil para falhas de autenticação LDAP para possibilitar a resolução de problemas. (#2932)
• Vinculação de usuário OIDC/LDAP a conta local — permite converter ou vincular contas locais existentes a provedores de identidade externos sem criar duplicatas. (#3339)
• Logout do provedor OIDC — encerra a sessão do IdP (por exemplo, Keycloak) ao sair do Semaphore, permitindo a troca de conta adequada. (#1496)

Pro #

• Sincronizar credenciais LDAP com chaves de acesso — opcionalmente atualiza automaticamente a senha da chave de acesso quando a senha LDAP é alterada no login, mantendo as credenciais do Ansible sincronizadas. (#3696)

Enterprise #

• Mapeamento de grupo para função OIDC — atribui automaticamente funções do Semaphore e associações a projetos com base em claims OIDC (por exemplo, claim groups), eliminando a configuração manual do usuário após o primeiro login. (#1499, #2483)
• Mapeamento de grupo para função LDAP — mapeia grupos do Active Directory/LDAP para funções do Semaphore, incluindo atribuição de função de administrador por meio de associação ao grupo. (#3226, #1316)
• RBAC completo com integração LDAP/OIDC — implementa controle de acesso granular baseado em função (administrador global, administrador do projeto, usuário do projeto, somente leitura) com atribuição automática de função a partir de grupos de provedores de identidade externos. (#891)
• Arquitetura de autenticação plugável — abstrai a autenticação em uma interface de provedor para suportar múltiplos backends de autenticação e simplificar a adição de novos provedores. (#465, #1820)
• Corrigir exclusão de usuário deixando dados órfãos — garante que a exclusão de um usuário limpe os mapeamentos project__user para evitar falhas na visualização da equipe. (#3514)

Sistema de Notificação Flexível #

O sistema de notificação atual no Semaphore UI é configurado exclusivamente por meio de config.json, oferece suporte a um conjunto limitado de canais (Email, Telegram, Slack, MS Teams) e opera em nível global com personalização mínima por projeto. Este recurso redesenha as notificações desde o início para serem gerenciadas pela UI, extensíveis e configuráveis na granularidade do projeto e do modelo.

Community #

• Arquitetura de canal extensível — define uma interface comum para canais de notificação com implementações por canal, simplificando a adição de novos canais sem modificar a lógica principal. Considere adotar uma biblioteca de notificação universal (por exemplo, nikoksr/notify) ou gateway (por exemplo, Apprise) para cobrir vários provedores ao mesmo tempo. (#2325, #1290)
• Configuração de notificação gerenciada pela UI — move a configuração de notificação dos arquivos de configuração para a UI Web com granularidade por projeto e por modelo, suportando várias instâncias do mesmo tipo de canal. (#3387, #1821, #3588)
• Personalização de mensagem baseada em modelo — suporta modelos de mensagens definidos pelo usuário armazenados como arquivos em disco em vez de no banco de dados.
• Seleção de canal por projeto — permite que os usuários configurem quais canais de notificação estão ativos por projeto por meio das configurações do projeto. (#3588)
• Eventos de webhook de saída — define tipos de eventos (START, SUCCESS, FAILURE) e permite a criação de modelos de webhook por projeto com URL configurável, cabeçalhos e autenticação HMAC. (#1825, #2594, #3066)
• Novos canais de notificação — adiciona suporte para Discord (#2924), Ntfy (#3383), Google Chat (#1148), Rocket.Chat (#1091) e Pushover (#2594).
• Notificações “Fixed” — envia uma notificação na primeira execução bem-sucedida após uma falha, semelhante aos alertas de recuperação do GitLab CI. (#3380)
• Desativar todas as notificações por modelo — adiciona uma opção “Desativar Todas as Notificações” ao lado da caixa de seleção existente “Desativar Notificações de Sucesso”. (#3724)
• Email em caso de sucesso — inclui email no caminho de notificação de sucesso (atualmente apenas Telegram/Slack/MS Teams disparam em caso de sucesso). (#3503)
• Corrigir URL da tarefa nas notificações — garante que todos os canais (email, Slack, MS Teams) recebam uma URL de tarefa totalmente qualificada com esquema e host, não um caminho relativo. (#2097, #2311, #3292)
• Corrigir problemas de entrega de email — resolver suporte à porta SMTP 465 (TLS implícito), ordenação de autenticação antes de TLS e formatação de cabeçalho de data. (#2201, #2971, #3542, #3209)
• Suporte a threads/tópicos do Telegram — permite o envio de notificações para threads de grupos específicos do Telegram via message_thread_id, configuráveis por projeto e por modelo. (#3493, #1456)
• Melhorias no modelo do Slack — expõe campos de nível superior (title, text, color) para compatibilidade com o Slack Workflow Builder. (#2607)
• Suporte a proxy de alerta — permite configurar um proxy HTTP para solicitações de notificação de saída sem exigir um proxy para todo o sistema. (#1484)

Pro #

• Canais de notificação exclusivos do Pro — suporta canais de notificação específicos exclusivamente no plano Pro.
• Alertas de tarefas de longa duração — dispara uma notificação quando uma tarefa excede um limite de duração configurável. (#1393)

Enterprise #

• Log de auditoria para notificações — mantém um registro pesquisável de todas as notificações enviadas com status de entrega, timestamps e detalhes do destinatário. Melhora o registro de erros para incluir o contexto do destinatário em caso de falhas. (#3410)
• Integração com plataformas de gerenciamento de incidentes — integrações nativas com PagerDuty, Opsgenie e ServiceNow para criação automática de incidentes e rastreamento do ciclo de vida.
• Controle de acesso a notificações baseado em função — restringe quem pode configurar regras e canais de notificação com base em funções e permissões organizacionais.

Múltiplos Inventários por Modelo #

O Ansible CLI oferece suporte nativo à passagem de múltiplos argumentos -i para compor inventários (por exemplo, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Atualmente, o Semaphore restringe cada modelo de tarefa a um único inventário, forçando os usuários a soluções alternativas como scripts de inventário, arquivos mesclados ou variáveis de ambiente extras. Este recurso elimina essa restrição e aborda o conjunto mais amplo de lacunas no gerenciamento de inventário.

Community #

• Suporte a múltiplos inventários — permite anexar múltiplos inventários a um único modelo de tarefa, passados como argumentos -i sequenciais para o Ansible (por exemplo, ansible-playbook -i common_vars.yml -i staging_hosts.yml). Resolve a limitação de um inventário por modelo. (#2093)
• Campo de inventário opcional — torna o campo de inventário nos modelos opcional para casos em que ansible.cfg já especifica a origem do inventário. (#1574)
• Fonte de inventário URL/HTTP — suporta a busca de inventário de uma URL remota ou endpoint de API, essencial para ambientes hospedados/SaaS sem acesso ao sistema de arquivos. (#1924)
• Seleção de inventário em tempo de execução — permite que os usuários selecionem um inventário no momento do lançamento da tarefa por meio de um menu suspenso, substituindo a solução alternativa atual de texto livre. (#1354)
• Corrigir persistência de inventário em tarefas agendadas — garante que o inventário selecionado em uma caixa de diálogo de agendamento seja salvo e usado no tempo de execução, em vez de retornar ao padrão do modelo. (#3566, #3293)
• Corrigir perda do link do repositório de inventário na exportação/restauração do projeto — as associações de inventário para repositório são descartadas durante a exportação do projeto e não restauradas na importação. (#3369, #3177)
• Passar variáveis de ambiente para inventário dinâmico — garante que as variáveis de ambiente do contêiner/host estejam disponíveis para scripts e plugins de inventário dinâmico (por exemplo, scripts Python, microsoft.ad.ldap). (#2724, #2783)
• Corrigir autenticação de inventário baseado em git — usa credenciais do repositório ao buscar branches remotos para inventário, corrigindo tentativas de acesso não autenticadas. (#3539)
• Substituições de credenciais por host — para de substituir ansible_user por host e variáveis de conexão definidas no inventário por --extra-vars global. Permite padrões de inventário multiusuário. (#1464, #1621)
• Visualizar conteúdo do inventário na UI — exibe conteúdo de inventário dinâmico e baseado em arquivo na interface do usuário para inspeção e depuração, com um link para o arquivo de origem no repositório externo. (#3169, #1555, #3543)
• Expor o nome do inventário no contexto da tarefa — disponibiliza o nome do inventário em semaphore_vars ou como uma variável de ambiente para que os playbooks possam referenciar qual inventário está ativo. (#1580)

Pro #

• Afinidade de inventário com runner — associa hosts de inventário a tags de runners para que as tarefas sejam despachadas apenas para runners que tenham acesso de rede aos hosts de destino, evitando falhas em ambientes com múltiplas redes. (#3322)
• Múltiplas chaves SSH por inventário — permite atribuir múltiplas entradas de armazenamento de chaves a um único inventário para frotas em que cada host usa uma chave SSH exclusiva. (#3336)
• Integração de inventário de hypervisor — integração nativa com APIs de hypervisor (VMware, Proxmox) para gerar e atualizar automaticamente inventários dinâmicos. (#2709)
• API de gerenciamento de grupo de hosts — fornece uma API para adicionar/remover hosts de grupos de inventário sem reescrever toda a carga útil do inventário. (#1560)

Enterprise #

• Restringir inventários permitidos por modelo — quando um modelo tiver a opção “perguntar pelo inventário” ativada, limita os inventários selecionáveis a uma lista de permissões definida pelo administrador, evitando o direcionamento acidental de ambientes errados. (#3587)
• Registro central de hosts — fornece uma camada de gerenciamento de hosts compartilhada para que as alterações de host (por exemplo, nome de host ou atualizações de IP) se propaguem para todos os inventários que referenciam esse host sem edições manuais. (#564)
• Armazenamento e visualização de facts de hosts — armazena facts do Ansible por host e exibe o estado antes/depois da execução da tarefa com recursos de diff e histórico. (#930)

Múltiplos Grupos de Variáveis por Modelo #

Atualmente, o Semaphore permite anexar um único Grupo de Variáveis (Ambiente) a cada modelo de tarefa. Isso força os usuários a duplicar variáveis entre grupos quando múltiplos modelos compartilham configurações comuns, ou a criar Grupos de Variáveis monolíticos que contêm tudo. Este recurso permite compor múltiplos Grupos de Variáveis por modelo e corrige os diversos bugs no tratamento de variáveis — serialização, precedência, propagação e ciclo de vida de variáveis de survey.

Community #

• Composição multiambiente — permite anexar múltiplos Grupos de Variáveis a um único modelo de tarefa para que conjuntos de variáveis compartilhadas (por exemplo, padrões comuns, substituições por região) possam ser compostos e reutilizados entre modelos. (#2612)
• Clonar Grupos de Variáveis — adiciona uma ação de clonagem para que ambientes que diferem apenas em alguns valores possam ser configurados sem recriar todos os campos do zero. (#3295)
• Conjuntos reutilizáveis de variáveis de survey — desacopla variáveis de survey dos modelos de tarefas em objetos atribuíveis independentes, evitando a duplicação por modelo. (#2212)
• Corrigir serialização JSON de extra-vars — serializa extra-vars complexos como JSON adequado em vez de strings de mapa Go, corrigindo falhas de jsondecode no Terraform/OpenTofu. (#3748, #1644, #2619)
• Corrigir precedência de variáveis de survey — resolve substituição silenciosa quando o mesmo nome de variável existe tanto em extra-vars de Ambiente quanto em survey; define uma precedência clara ou gera um erro. (#3108)
• Corrigir tratamento de variáveis de survey vazias/opcionais — garante que as variáveis opcionais de survey sejam consistentemente omitidas ou passadas como strings vazias, e não misturadas aleatoriamente. (#2182)
• Valores padrão de survey para tarefas agendadas — permite especificar valores padrão para variáveis de survey ao agendar tarefas, para que as execuções automatizadas não falhem nos prompts obrigatórios. (#2244)
• Passar variáveis de survey como variáveis de ambiente para tarefas bash — expõe variáveis de survey como variáveis de ambiente do sistema operacional em vez de argumentos CLI para tarefas do tipo shell. (#2433)
• Passar variáveis de survey durante init do Tofu/Terraform — encaminha variáveis de survey para a fase init, não apenas plan/apply, para suportar configurações de backend baseadas em variáveis. (#2554)
• Referências Jinja2 em Extra CLI Arguments — permite referenciar variáveis de survey e de ambiente no campo Extra CLI Arguments usando sintaxe de template (por exemplo, -l {{ hosts }}). (#1053)
• Variáveis de ambiente na preparação da execução — disponibiliza variáveis de ambiente durante a fase de preparação (por exemplo, galaxy install, autenticação de role Git) e não apenas durante a execução da tarefa. (#3178)
• Carregar extra-vars de arquivo do repositório — suporta o carregamento de extra-vars de um arquivo JSON/YAML no repositório em vez de inline na UI, habilitando fluxos de trabalho GitOps. (#2343)
• Substituir ambiente em tempo de execução via API — permite passar um Grupo de Variáveis diferente ao iniciar uma tarefa via API. (#1367, #3291)

Pro #

• Tipos complexos de variáveis de survey — suporta variáveis de survey dinâmicas de lista de objetos (por exemplo, configurações de VLAN) passadas como arrays JSON estruturados. (#3557)
• Substituições de variáveis por agendamento — anexa valores de variáveis personalizadas a trabalhos agendados para que o mesmo modelo possa ser executado em agendas diferentes com parâmetros diferentes. (#2378)
• Valores dinâmicos de variáveis do contexto do usuário — preenche automaticamente variáveis com a identidade do usuário conectado (por exemplo, {{ current_user }}). (#2524, #909)

Enterprise #

• Marcar variáveis como privadas — adiciona um sinalizador “privado” nas variáveis que impede que os valores apareçam nos logs de execução, no histórico de tarefas e nas respostas da API. (#2887)
• Restringir visibilidade de variáveis de ambiente — limita o conteúdo do Grupo de Variáveis apenas a funções administrativas, evitando a exposição de credenciais em modelos de projetos compartilhados. (#1126)
• Snapshots de variáveis no nível de build — captura os valores das variáveis no momento da execução da tarefa para que re-execuções usem os valores originais, não os atuais. (#1097)

Segredos de Propriedade do Usuário #

O armazenamento de chaves do Semaphore é atualmente compartilhado por todos os membros do projeto. Qualquer usuário com acesso ao projeto pode usar (e em alguns casos visualizar) todas as credenciais armazenadas. Isso cria preocupações de segurança em ambientes multiusuário onde os membros da equipe deveriam ter acesso apenas às suas próprias credenciais. Além disso, o armazenamento de chaves possui múltiplos bugs relacionados a criptografia, atualizações de segredos e integridade de referência, e não possui integração com sistemas externos de gerenciamento de segredos.

Community #

• Armazenamento de chaves pessoal — fornece um armazenamento de chaves por usuário para que credenciais pessoais (chaves SSH, senhas sudo) sejam isoladas de outros membros do projeto e não sejam compartilhadas por meio do armazenamento de chaves no nível do projeto. (#1483, #1373)
• Corrigir comportamento de atualização de segredo — resolve o problema em que a edição de uma variável de ambiente secreta parece ter sucesso, mas o valor não é realmente persistido. (#2546)
• Ocultar segredos da lista de processos — para de passar extra-vars secretos por meio de argumentos de linha de comando visíveis na lista de processos do sistema operacional; usa um mecanismo seguro (por exemplo, arquivos temporários, stdin). (#3219)
• Suporte a certificado SSH no armazenamento de chaves — permite o armazenamento de certificados SSH juntamente com chaves SSH para fluxos de trabalho de autenticação baseados em certificados. (#3171)
• Mostrar chave pública SSH — exibe a parte da chave pública das chaves SSH armazenadas na interface do armazenamento de chaves por conveniência. (#1643)
• Suporte a segredos do Docker — suporta o padrão _FILE env var (por exemplo, POSTGRES_PASSWORD_FILE) para que os segredos do Docker/Kubernetes possam ser montados e lidos em vez de passados por variáveis de ambiente. (#1268)
• Corrigir tratamento de chave de criptografia no Docker — garante que a env var SEMAPHORE_ACCESS_KEY_ENCRYPTION seja respeitada e não seja substituída por uma chave aleatória na reinicialização do contêiner. (#2228, #3068, #3204)
• Corrigir quebra de referências ao renomear armazenamento de chaves — resolve o problema em que a renomeação de uma entrada do armazenamento de chaves quebra todos os inventários e modelos vinculados. (#3188)
• Corrigir API de senha do vault — permite definir e atualizar senhas do Ansible Vault por meio da API REST sem erros de restrição de chave duplicada. (#3413, #2773)

Pro #

• Integração com armazenamento de segredos externo — busca segredos em tempo de execução do HashiCorp Vault, Azure Key Vault, AWS KMS ou Bitwarden em vez de armazená-los no banco de dados do Semaphore. (#2248, #658)

Enterprise #

• Chaves de acesso globais — compartilha entradas do armazenamento de chaves entre projetos sem duplicação, com gerenciamento centralizado e vinculação entre projetos. (#110)
• Trilha de auditoria de acesso a segredos — registra todo o acesso e uso de entradas do armazenamento de chaves e variáveis secretas para conformidade e análise forense.

Fluxos de Trabalho #

O Semaphore atualmente trata cada modelo de tarefa como uma unidade independente — não existe uma forma integrada de encadear múltiplos modelos em um pipeline de execução multi-etapas. Esta funcionalidade introduz os Fluxos de Trabalho — grafos acíclicos direcionados (DAGs) de modelos de tarefas que são executados com ramificação condicional, passagem de variáveis entre etapas e portões de aprovação humana opcionais. O design se inspira nos AWX Workflow Job Templates, nos fluxos de trabalho do Rundeck e nos conceitos de pipelines do Jenkins/GitLab CI.

Community #

• Modelos de fluxo de trabalho — introduzir uma nova entidade de nível superior que define um DAG de nós de modelos de tarefas conectados por arestas direcionadas com condições (on_success, on_failure, always), permitindo pipelines de automação multi-etapas dentro de um projeto. (#3182, #2334, #1383, #836)
• Motor de execução de fluxos de trabalho — executar nós do fluxo de trabalho em ordem topológica, respeitando as condições das arestas e executando ramificações independentes em paralelo, com convergência ALL para nós com múltiplos pais. (#2281, #3088)
• Painel de execução de fluxos de trabalho — fornecer uma visão unificada da execução do fluxo de trabalho mostrando o grafo DAG com status por nó (pendente, em execução, bem-sucedido, falhou, ignorado), logs de nós clicáveis e tempos gerais.
• Passagem de variáveis entre nós — permitir que modelos de tarefas emitam variáveis de saída (através de um arquivo conhecido ou Ansible set_stats) que são automaticamente injetadas como variáveis extras nos nós subsequentes. (#3182)
• Agendamento de fluxos de trabalho e gatilhos de API — suporte para agendamento cron, execuções ativadas por API e gatilhos webhook para fluxos de trabalho, com variáveis de survey opcionais no nível do fluxo de trabalho. (#3088)

Pro #

• Editor visual de fluxos de trabalho — editor gráfico de arrastar e soltar para projetar fluxos de trabalho na interface, com validação DAG em tempo real, posicionamento de nós e seletores de condições nas arestas.
• Substituições por nó — substituir o inventário, credenciais, grupos de variáveis ou argumentos CLI de um modelo no nível do nó do fluxo de trabalho, permitindo reutilizar o mesmo modelo em diferentes ambientes dentro de um único fluxo de trabalho.
• Portões de aprovação — pausar a execução do fluxo de trabalho em pontos designados para aguardar aprovação humana, com tempos limite configuráveis, notificação aos aprovadores e ações de aprovação/rejeição da interface ou API.

Enterprise #

• RBAC de fluxos de trabalho — permissões granulares para criar, editar, executar e aprovar fluxos de trabalho, com atribuição de portões de aprovação baseada em funções e registro de auditoria.
• Fluxos de trabalho entre projetos — referenciar modelos de tarefas de outros projetos em um fluxo de trabalho, permitindo pipelines de automação em nível organizacional que abrangem projetos de infraestrutura, aplicação e monitoramento.
• Versionamento de fluxos de trabalho e rollback — manter um histórico de versões das definições de fluxos de trabalho com diffs, restaurar versões anteriores e registrar qual versão foi usada para cada execução.