artigo
antes de codar, ajuste o modelo mental
como pensar a plataforma antes de escolher entre configuração, automação, modelo de dados, segurança ou script.
#o sintoma
Alguém abre uma demanda e diz: "é simples, só precisa de um Business Rule". A frase vem com aquela confiança de quem ainda não viu um Business Rule simples virar o centro nervoso de uma operação inteira. Três meses depois, o script já atualiza campo, manda notificação, cria tarefa, valida regra de negócio, consulta integração, calcula SLA no improviso e ainda tem um comentário // TODO: revisar depois.
O problema não é o Business Rule. Ele é uma ferramenta excelente quando usado no lugar certo. O problema é começar a solução pelo artefato técnico, como se a plataforma fosse um editor de código com formulário em volta.
ServiceNow não é isso. ServiceNow é uma plataforma de modelo, processo, segurança, interface e automação. Código entra na conversa, mas raramente deveria ser a primeira pessoa a sentar na mesa.
#a armadilha do "funciona"
Em projeto real, "funciona" é uma medida muito pobre. Um script que resolve o caso feliz na tela do analista funciona. Um atalho que grava direto no campo certo funciona. Um fluxo que manda quinze e-mails porque ninguém configurou bem as condições também funciona, tecnicamente.
O problema aparece quando você tenta manter, auditar, promover, depurar ou atualizar a instância.
É como montar uma cozinha profissional e fritar tudo numa panela velha porque a panela estava mais perto. No almoço de terça talvez dê certo. No primeiro evento com 200 pessoas, alguém vai perguntar por que a chapa, o forno e a bancada de preparo foram ignorados. E a resposta "porque eu já sabia usar a panela" não fica bonita na retrospectiva.
No ServiceNow, essa panela velha costuma aparecer como:
- Client Script resolvendo regra que deveria ser Data Policy;
- Business Rule validando acesso que deveria estar em ACL;
- Script Include carregando regra simples que cabia em configuração;
- tabela customizada paralela a uma tabela nativa que já resolvia 80% do problema;
- campo criado com nome provisório que virou permanente, porque nada é mais permanente que o provisório em produção.
#a hierarquia mental
Antes de escolher a ferramenta, vale passar por uma ordem de raciocínio. Não é burocracia. É higiene técnica.
| pergunta | caminho preferencial | quando desconfiar |
|---|---|---|
| Dá para configurar? | campos, estados, choices, views, UI Policies, Data Policies | quando a solução vira script só para mudar comportamento padrão |
| Dá para automatizar declarativamente? | Flow Designer, regras nativas, notificações, SLAs | quando o fluxo fica ilegível ou tenta fazer lógica transacional pesada |
| O modelo de dados está certo? | extensão de tabelas, relacionamentos, referências, herança | quando você precisa compensar o modelo com scripts em todo lugar |
| A segurança está na camada certa? | roles, grupos, ACLs, critérios de acesso | quando a interface esconde algo, mas a API ainda permite acesso |
| Precisa codar mesmo? | Business Rules, Script Includes, APIs, jobs | quando a regra exige lógica que a plataforma não expressa bem |
Essa ordem não significa que código é proibido. Código é necessário, e às vezes é a escolha mais limpa. Mas ele deve entrar como decisão, não como reflexo muscular.
#configuração não é "menos técnica"
Existe um preconceito comum em times que vêm de desenvolvimento tradicional: se não tem código, parece simples demais. Aí o desenvolvedor quer "fazer direito" e transforma uma configuração de plataforma em lógica customizada.
Só que, em ServiceNow, configurar bem é uma habilidade técnica. Saber quando usar uma UI Policy em vez de Client Script, quando usar Data Policy em vez de validação no onSubmit, ou quando usar uma propriedade de sistema em vez de valor fixo no script, separa implementação sustentável de gambiarra com crachá corporativo.
Um exemplo prático:
- se um campo é obrigatório sempre que o estado for "Pendente", uma UI Policy pode resolver;
- se essa obrigatoriedade precisa valer também para importação, API e atualização em massa, Data Policy entra na conversa;
- se a regra depende de cálculo complexo, consulta em outra tabela e exceções por tipo de usuário, talvez um Business Rule faça sentido;
- se a regra é sobre quem pode gravar o campo, provavelmente você está falando de ACL, não de UI.
O mesmo requisito muda de camada conforme o contexto. Esse é o ponto. A ferramenta certa não nasce do nome do artefato pedido no chamado; nasce da responsabilidade da regra.
#um roteiro de decisão
Quando a demanda chega com cara de "só fazer um script", eu gosto de reduzir a ansiedade com cinco perguntas:
- Essa regra é sobre dado, processo, interface, segurança ou integração?
- Ela precisa rodar fora do formulário, como API, import set ou atualização em massa?
- Quem vai precisar entender isso daqui a seis meses?
- O que acontece no upgrade se esse comportamento depender de customização?
- Qual é o menor ponto da plataforma que expressa essa regra sem esconder a intenção?
Não é para transformar cada ajuste pequeno em cerimônia arquitetural. Ninguém precisa abrir um comitê para mudar o label de um campo. Mas quando a decisão cria comportamento duradouro, mexe em tabela central, altera permissão, dispara automação ou afeta volume alto de registros, pare antes de codar.
Essa pausa de dez minutos costuma economizar a sexta-feira à noite de alguém. Talvez a sua.
#exemplos de decisões que envelhecem bem
Algumas escolhas parecem pequenas no começo, mas envelhecem com dignidade:
| situação | decisão melhor | por quê |
|---|---|---|
| Regra visual simples no formulário | UI Policy | fica declarativa, fácil de localizar e menos frágil |
| Validação que precisa valer no servidor | Data Policy ou Business Rule | não depende do navegador participar |
| Reuso de lógica server-side | Script Include | evita duplicação e centraliza regra complexa |
| Nova funcionalidade de negócio | Scoped Application | isola o domínio e reduz sujeira no global |
| Decisão arquitetural controversa | ADR curto | registra o motivo antes que vire folclore de projeto |
| Permissão por perfil | ACL | segurança precisa estar no servidor, não na maquiagem da tela |
Perceba que a coluna do meio não diz "sempre". ServiceNow pune dogma quase tão rápido quanto pune descuido. A plataforma é cheia de exceções legítimas. Mas exceção legítima precisa de explicação. "Eu estava com pressa" não é explicação; é confissão.
#o cheiro de solução errada
Alguns sinais indicam que você está usando a camada errada:
- você precisa repetir o mesmo script em várias tabelas;
- o comportamento funciona no formulário, mas falha por API;
- ninguém sabe onde a regra está, só sabe que "em algum lugar ela roda";
- o script consulta muitos registros para compensar um relacionamento mal modelado;
- um campo chamado
u_temp_statusvirou base de relatório executivo; - a solução exige que o usuário "não faça daquele jeito", porque tecnicamente ela não impede.
Esses sinais não condenam a implementação automaticamente. Eles pedem investigação. Às vezes existe uma restrição real: prazo, licença, módulo indisponível, legado difícil, integração esquisita. Projeto real tem poeira no chão. O erro é varrer tudo para baixo do Business Rule e chamar de arquitetura.
#código como última milha, não como terreno inteiro
Quando o código entra depois de uma boa decisão de plataforma, ele fica menor e mais claro.
Um Business Rule que valida uma regra específica, chama um Script Include bem nomeado e roda com condição objetiva é bem diferente de um Business Rule que tenta ser motor de workflow, camada de segurança, normalizador de dados e terapeuta do processo.
O mesmo vale para Script Includes. Eles são ótimos para encapsular regra reutilizável. Mas se cada Script Include vira uma mini-plataforma paralela, com convenção própria, cache próprio, logging próprio e "framework interno" que só uma pessoa entende, você não simplificou. Você construiu outro produto dentro do produto.
ServiceNow já tem bastante plataforma. Use a que você comprou antes de inventar outra.
#um roteiro rápido
Antes de implementar a próxima demanda, siga este caminho:
- descreva a regra em uma frase sem citar ferramenta;
- identifique se a regra pertence a dado, processo, interface, segurança ou integração;
- procure primeiro a configuração nativa que expressa essa regra;
- confirme se o comportamento precisa valer fora da UI;
- escolha automação declarativa quando ela continuar legível;
- modele a tabela antes de compensar com script;
- coloque segurança em ACL e no servidor;
- escreva código quando a plataforma não representar bem a lógica;
- documente a decisão quando ela tiver impacto arquitetural.
O modelo mental correto não deixa você mais lento. Ele só tira aquela pressa falsa que cria retrabalho. ServiceNow recompensa quem pensa em camadas: configuração onde basta, automação onde ajuda, modelo de dados onde sustenta, segurança onde protege e código onde realmente precisa.
No fim, a pergunta não é "qual script eu escrevo?". A pergunta é "qual parte da plataforma deveria carregar essa responsabilidade?". Quando você acerta isso, o código que sobra tende a ser menor, mais legível e menos propenso a virar assunto constrangedor no próximo upgrade.