artigo
Flow Designer: a planta baixa que substitui o encanamento escondido
Os quatro componentes do Flow Designer, a regra dos 3-5 linhas no Run Script, o Execution Detail e por que o debate contra o Workflow Editor já acabou.
#a planta baixa contra o encanamento escondido
Tem uma conversa que se repete em todo projeto ServiceNow: "preciso automatizar essa aprovação" e o desenvolvedor já abre um Business Rule. Não é errado — mas quase sempre é a ferramenta errada para o trabalho. Business Rule é encanamento dentro da parede: eficiente, mas invisível. Quando algo vaza, você precisa abrir a parede para descobrir onde.
Flow Designer é a planta baixa do mesmo processo. Você vê o que vai acontecer antes de acontecer, e depois vê exatamente o que aconteceu — com timestamp e valor de cada etapa. Disponível desde o release Kingston (2018) e mecanismo preferencial para tudo que é novo já há vários releases, ele foi desenhado para automação de processo, não para lógica de campo isolada.
#os quatro blocos de montar
Um Flow bem estruturado não é uma sequência gigante de steps genéricos — é composto por quatro tipos de peça, cada uma com um propósito específico:
| componente | o que é | reutilizável? | quando criar |
|---|---|---|---|
| Flow | processo de negócio completo, disparado por um trigger | não — específico de um processo | um por processo distinto: aprovação de mudança, onboarding, alerta de SLA |
| Subflow | sequência de steps com inputs/outputs tipados, chamada de dentro de Flows | sim — feito para isso | quando a mesma lógica se repete em 2+ Flows: enviar notificação, criar task, validar usuário |
| Action | unidade atômica de trabalho, nativa (OOB) ou custom | sim — chamada por Flows e Subflows | quando as actions nativas não cobrem o caso, você cria uma Custom Action |
| Trigger | condição que dispara o Flow: registro criado/atualizado, agendamento, evento | não se aplica | configurado uma vez por Flow — com o máximo de especificidade possível |
O trigger merece atenção redobrada porque é o componente mais fácil de configurar errado sem perceber o custo.
#como fica um flow bem estruturado na prática
Um Flow segue o mesmo princípio que já vale para Business Rule: responsabilidade clara em cada step, lógica complexa delegada para fora, sequências repetidas extraídas para reuso. A diferença é que aqui a extração vira um componente de primeira classe — o Subflow — em vez de uma convenção de código.
Pega o caso clássico de aprovação de Change Request:
TRIGGER: Record — change_request
Condição: state muda para "Assess"
Run mode: Always
STEP 1 — Look Up Records (action nativa, sem código)
Tabela: sys_user_group
Filtro: u_responsible_for CONTAINS "change_management"
Output: cab_groups
STEP 2 — Flow Logic: For Each
Para cada group em cab_groups:
STEP 2a — Subflow: "Create Approval Request"
Inputs: record=trigger.current, approver_group=group
Output: approval_result
STEP 3 — Flow Logic: If/Else
Condição: approval_result.state = "approved"
Se aprovado:
STEP 3a — Update Record: state = "Authorized"
STEP 3b — Subflow: "Send Notification" (template=change_authorized)
Se rejeitado:
STEP 3c — Update Record: state = "Rejected"
STEP 3d — Subflow: "Send Notification" (template=change_rejected)Repara no que faz esse desenho ser bom antes mesmo de rodar: trigger com condição específica, busca de grupo feita com Look Up Records em vez de script, e as duas peças que se repetem — pedir aprovação e mandar notificação — viraram Subflows chamáveis de qualquer outro processo que precise da mesma coisa. Ninguém vai copiar e colar essa lógica em três Flows diferentes; ela mora em um lugar só.
#a válvula de escape que vicia fácil
Nem tudo cabe numa action nativa. Para isso existe o step "Run Script" — e ele é legítimo. O problema não é usá-lo, é o que as pessoas colocam dentro dele quando ele "só essa vez" vira o lugar de trinta linhas de lógica de negócio.
// ❌ lógica inline no Run Script step — difícil de testar, impossível de reutilizar
var incSysId = fd_data.trigger.current.sys_id;
var gr = new GlideRecord("cmdb_rel_ci");
gr.addQuery("child", incSysId);
gr.addQuery("type.name", "Runs on::Runs");
gr.query();
var affectedServers = [];
while (gr.next()) {
affectedServers.push(gr.getValue("parent"));
}
// ... mais 30 linhas que deveriam estar num Script Include ...Essa versão funciona — até o dia em que alguém precisa da mesma análise de impacto num Business Rule ou numa API REST, e descobre que ela está presa dentro de um step que só existe dentro desse Flow específico. Sem ATF, sem reuso, sem teste isolado.
// �
o step tem 3 linhas; a lógica de verdade mora no Script Include
var svc = new IncidentImpactAnalyzer();
var result = svc.getAffectedCIs(fd_data.trigger.current.sys_id);
fd_data.affected_servers = result.servers;
fd_data.affected_services = result.services;A regra prática: se o Run Script step está passando de 3-5 linhas, isso é sinal — não de que o step precisa de mais espaço, mas de que a lógica precisa de um Script Include. O mesmo Script Include, aliás, fica disponível para qualquer outro Flow, Business Rule ou API que precise da mesma análise depois.
#o superpoder que faltava nos Business Rules
Se tem uma feature que sozinha já justificaria migrar processos antigos, é o Execution Detail: um log visual e completo de cada execução, com o estado de cada step, os valores exatos de input e output, e o timestamp de início e fim de cada operação.
Compara com o hábito de debugar Business Rule: adicionar gs.info(), salvar, reproduzir o cenário, ler o log, tirar o gs.info(). No Flow Designer você abre o Execution Detail da execução que já aconteceu e vê tudo.
- erro no flow: vá direto ao step que falhou e olhe os inputs — na maioria das vezes é um valor nulo ou de tipo inesperado.
- comportamento incorreto, mas sem erro: compare os outputs de cada step em sequência até achar onde o valor esperado virou outra coisa.
- flow lento: os timestamps por step apontam o culpado. Um Run Script levando 10 segundos é sinal de query sem índice ou de lógica que deveria estar assíncrona.
#flow designer vs workflow editor: não tem debate
Se você ainda encontra quem pergunta "Flow Designer ou Workflow Editor para esse novo processo?", a resposta já é dada há vários releases pela própria ServiceNow: Flow Designer para tudo que for novo.
O Workflow Editor continua recebendo correção de bug para não quebrar o que já existe — mas não recebe investimento em funcionalidade nova. Começar um processo novo nele hoje tem o mesmo cheiro de abrir um projeto novo em uma tecnologia que a própria fabricante já anunciou como legado.
| critério | Flow Designer | Workflow Editor |
|---|---|---|
| status | preferencial há vários releases | suportado para legado, não recomendado para novo |
| visibilidade de execução | Execution Detail completo | log limitado, debug por tentativa e erro |
| reuso de lógica | Subflows com inputs/outputs tipados | sem equivalente |
| integração externa | spokes do IntegrationHub como actions nativas | scripting manual em cada integração |
| processos novos | use sempre | não inicie nada aqui |
| processos legados | migre quando houver janela no roadmap | mantenha rodando, não expanda |
#e agora?
- Escolha um Business Rule existente com mais de uma responsabilidade (validar + notificar + atualizar outro registro) e desenhe como ele ficaria como Flow com Subflows separados — é o exercício mais rápido para sentir a diferença.
- Monte esse Flow do zero na sua instância de dev: trigger com condição específica, um Look Up Records, um Subflow reutilizável. Force um erro de propósito e abra o Execution Detail — depois de ver o nível de detalhe uma vez, fica difícil voltar a debugar só com log.
- Se você mantém algum Flow com Run Script step passando de 5 linhas, esse é candidato direto a virar Script Include — o mesmo raciocínio que já vale para Business Rule.
- Antes de automatizar qualquer coisa com Flow Designer, vale revisitar precedência de campos e business rules: o Flow decide o processo, mas ainda depende dos mesmos campos e das mesmas regras de timing por baixo.