Criar formulário e lógica de negócios

  • Versão de lançamento: Yokohama
  • Atualizado 30 de jan. de 2025
  • 2 min. de leitura
  • A próxima etapa no design de uma aplicação é criar lógica. A lógica inclui a lógica do formulário (o que as pessoas podem e não podem ver/usar em um formulário) e a lógica de negócios (regras que controlam o que acontece com os dados quando eles são inseridos).

    IA agênica

    Crie aplicações com a ajuda da IA de agente. Para obter mais informações, consulte Use a IA dinâmica para criar e editar aplicações.

    Scripts e modificações

    Antes de escrever qualquer código, esteja ciente do impacto nos upgrades e na adoção de novos recursos da ServiceNow. Deve-se ter cuidado especial ao modificar artefatos e processos de linha de base.

    Considere o seguinte antes de criar scripts:

    • Avalie o requisito. A lógica é crítica para o funcionamento do app?
    • Determine se a ServiceNow pode ser configurada para atender ao requisito sem código.
    • Aproveite opções como Flow Designer, Virtual Agent e Políticas de IU para aproveitar os recursos da plataforma sem escrever código.
    • Abordagens de lógica com pouco código e sem código são mais fáceis de depurar e fazer upgrade.

    Exemplos de quando o script é apropriado:

    • Como criar ações do Flow Designer
    • Como criar uma REST API com script
    • Criação de lógica para aplicações com escopo em Inclusões de script
    • Personalizando e criando widgets para o Portal de serviços

    Avalie o requisito de negócios e considere uma rota sem código antes de usar uma solução com script.

    Esteja ciente dos aprimoramentos da ServiceNow. Por exemplo, na versão orlando, as conversas do Virtual Agent têm mais opções sem código do que London. Leia as notas de versão e outras publicações. Obter certificação e manter-se atualizado com suas certificações.

    Para entender melhor quando personalizar, revise o Playbook de sucesso da Inovação em escala na Central de sucesso do cliente.

    Modificando o comportamento padrão

    No passado, uma das estratégias usadas era copiar o artefato para atualizar e desativar o original. A abordagem de copiar/desativar não é mais recomendada devido aos seguintes problemas:

    • Os desenvolvedores não podem saber se um artefato desativado foi atualizado sem pesquisa.
    • Dois arquivos, o original e a cópia, precisam ser mantidos. A manutenção duplica sempre que uma personalização é feita.
    • A cada versão, o registro personalizado se torna mais antigo.
      • Os clientes não recebem os aprimoramentos incluídos em uma nova versão.
      • Uma nova versão pode contar com a atualização do registro original.
      • Os desenvolvedores podem fazer mais mudanças para compensar o registro original que está inativo.

    Um script em que somente o sinalizador Ativo é alterado será atualizado, mas o script não aparecerá na lista ignorada. Com a estratégia de copiar e desativar, um desenvolvedor tem menos visibilidade sobre personalizações e não pode avaliar ou reverter facilmente para a versão de linha de base.

    Em vez de copiar e desativar o artefato original, edite o artefato diretamente. O Mecanismo de upgrade da ServiceNow adicionará a versão mais recente ao histórico de versões e informará que o artefato foi ignorado. Os desenvolvedores podem ver que uma nova versão está disponível com o upgrade.