por que este campo está obrigatório? precedência no ServiceNow

#o sintoma

Você abre um registro no ServiceNow, tenta salvar, e um campo aparece como obrigatório. O detalhe incômodo é que ninguém lembra de ter marcado aquele campo como obrigatório no dicionário. Em outro formulário, o mesmo campo não se comporta assim. Em uma lista, talvez o comportamento seja diferente de novo.

Esse tipo de dúvida quase sempre é uma disputa de precedência. O estado final de um campo não vem de uma única configuração. Ele é resultado de camadas que podem permitir, exigir, esconder ou bloquear a edição.

#uma ordem útil de investigação

Não existe uma única fila universal para todo comportamento da plataforma, mas esta ordem ajuda a depurar a maioria dos casos em formulário:

Pense nessas camadas como fontes de autoridade diferentes. Algumas atuam no servidor e continuam valendo mesmo quando a interface não participa. Outras atuam no cliente e podem mudar durante a interação do usuário.

#ACL: primeiro veja se o usuário pode agir

ACL não costuma explicar diretamente um campo marcado como obrigatório, mas explica situações em que o usuário não consegue preencher ou alterar o valor. Se o campo está obrigatório e ao mesmo tempo sem permissão de escrita, o usuário fica preso.

O caminho prático é testar com o Debug Security Rules e comparar:

• a ACL da tabela;
• a ACL do campo;
• papéis herdados por grupos;
• scripts de ACL que dependem do registro.

#Data Policy: a regra que aparece no salvamento

Data Policy é uma boa suspeita quando o erro aparece ao salvar, inclusive em importações, integrações ou atualizações fora do formulário clássico. Ela roda no servidor e pode exigir um campo mesmo que a interface não tenha marcado visualmente o campo como obrigatório.

Ao investigar, confirme se a política está ativa, se a condição bate no registro e se existe alguma configuração para aplicar somente na UI. Quando a regra é server-side, ela é uma garantia de dados, não apenas uma dica visual.

#UI Policy: comportamento declarativo no formulário

UI Policy é frequentemente a resposta quando o campo muda de obrigatório conforme valores do próprio formulário. Ela é declarativa, fácil de encontrar e costuma ser preferível a um Client Script simples.

Verifique:

• tabela e herança;
• view aplicada;
• condição da política;
• ordem das políticas;
• ações de UI Policy para o campo;
• opção de reverter quando a condição deixa de ser verdadeira.

Quando duas UI Policies mexem no mesmo atributo do mesmo campo, a ordem e a condição final importam. O problema não é só "qual regra existe", mas qual regra está ativa no momento em que o usuário observa o formulário.

#Client Script: flexível, mas fácil de esconder

Client Script entra quando a lógica precisa reagir a eventos ou fazer algo que UI Policy não cobre bem. Por isso também é uma fonte comum de comportamento surpresa.

Procure chamadas como:

g_form.setMandatory('u_justificativa', true);
g_form.setReadOnly('u_justificativa', false);
g_form.setDisplay('u_justificativa', true);

Também vale procurar scripts em UI Scripts, Catalog Client Scripts quando for catálogo, Client Scripts herdados e lógica executada por onLoad, onChange ou onSubmit.

#dicionário: o padrão da tabela

O dicionário define o comportamento estrutural do campo. Se o campo é obrigatório no Dictionary Entry, ele tende a nascer obrigatório de forma ampla. Ainda assim, camadas acima podem afetar a experiência do formulário, especialmente com UI Policy e Client Script.

Use o dicionário para o que é verdade do modelo de dados. Use regras condicionais quando a obrigatoriedade depende do processo.

#um roteiro rápido

Quando alguém perguntar "por que este campo está obrigatório?", eu sigo este roteiro:

• reproduzo com o mesmo usuário, tabela, view e registro;
• verifico se o campo é gravável pelas ACLs;
• procuro Data Policies na tabela;
• reviso UI Policies ativas e suas ações;
• busco Client Scripts que alterem o campo;
• confirmo o Dictionary Entry;
• testo o salvamento, não apenas o asterisco no formulário.

O ponto principal é separar aparência de validação. O asterisco no formulário ajuda, mas o que decide se o registro salva pode estar no servidor. Quando você identifica em qual camada a regra vive, a correção deixa de ser um exercício de tentativa e erro.