Minha jornada no ServiceNow começou lá por 2017–2018 e, desde o primeiro momento, fiquei profundamente impressionado com a comunidade. A vasta troca de conhecimento, a riqueza de informações (gratuitas) e documentação disponíveis, e a disposição das pessoas do ecossistema ServiceNow em ajudar umas às outras eram verdadeiramente notáveis. Isso me inspirou a começar a contribuir ativamente. Comecei respondendo a perguntas, escrevendo artigos e mais. Pensei logo isso incrivelmente gratificante — uma maneira de expandir continuamente meu próprio conhecimento e habilidades, testar minha experiência e, o mais importante, retribuir o que aprendi. Avançando alguns anos, e minhas contribuições cresceram significativamente! Tive o privilégio de compartilhar e participar de mais de 100 artigos e blogs, +275 vídeos, podcasts, projetos colaborativos e muito mais. E a paixão continua tão intensa quanto no início. Abaixo, você encontrará uma coleção de artigos, vídeos e recursos, que são contribuições não apenas minhas, mas também de colegas profissionais que compartilham a mesma paixão por devolver à comunidade ServiceNow. Esses materiais visam fornecer insights valiosos, soluções e conhecimento que podem te ajudar na sua própria jornada em ServiceNow. Sinta-se à vontade para explorar e aproveitar esse crescente conjunto de expertise — essa é a nossa maneira de dizer “obrigado” pelo conhecimento e camaradagem que encontramos nesta incrível comunidade. E, recentemente (setembro/2025), essa paixão alcançou um novo patamar! Este último setembro/2025 & Dezembro/2025, tive a imensa satisfação de registrar e publicar meus primeiros livros na CBL (Câmara Brasileira do Livro), que já está disponível na Amazon. O livro, intitulado O Guia Definitivo para Certificações ServiceNow: Da preparação à Manutenção, é a consolidação de todo esse conhecimento prático e teórico. E o melhor: ele está disponível em português, além de edições em Inglês e Espanhol, para ajudar a comunidade globalmente. Summary Artigos/Posts publicados nas redes 2025 Dashboards Legados? Saiba como a Release Zurich simplificou a migração (20260108) SSC: Blindando sua Instância contra Vulnerabilidades de JQuery UI (20260109) 🚀 De Application Service para Service Instance: O que muda na Yokohama e CSDM 5.0 (20260112) 🛡️ Segurança em IA: Entenda o CVE-2025–12420 e como Proteger sua Instância ServiceNow (20260113) Onde posso iniciar meus estudos com ServiceNow? [video] (20260113) https://br.pinterest.com/pin/627759635604826125 (20260114) Onde posso iniciar meus estudos com ServiceNow? (20260116) 13º ServiceNow Developers Meetup Brazil: O Futuro da IA e Now Assist (20260115). Guia de Troubleshooting: Metodologia Técnica para Homologação de Ambientes (20260116). Framework de Suporte: A metodologia definitiva para troubleshooting no ServiceNow (). De Applications para Instance: Entenda a Mudança no ServiceNow [video] (20260120). Como Corrigir Vulnerabilidades de jQuery no ServiceNow (Hardening) [video] (20260121) ServiceNow CSDM: O Papel Fundamental do Application Service [video] (20260122)       Participe, entre nas comunidades, acompanhem os posts: https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://macul.medium.com/ https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board NowBridge. https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://join.slack.com/t/servicenowbrasil/shared_invite/zt-2sooa78s7-MWwcMxEdbktNjjIYRZfqHg https://www.linkedin.com/in/tiagomacul/ Conteúdos de interesse O Guia Definitivo para Certificações ServiceNow: Da preparação à Manutenção. English, Español ... View more

Como Ocultar o Botão “New” em Listas Relacionadas no ServiceNow (Sem Scripting) Você já precisou remover o botão “New” de uma lista relacionada específica, mas ficou com medo de alterar a UI Action Global e afetar todo o sistema?   Muitos desenvolvedores iniciantes tentam encontrar a UI Action “New” para aplicar uma condição, mas o problema é que esse botão geralmente é Global. Modificá-lo pode causar um efeito cascata indesejado em tabelas de Incidentes, Problemas e centenas de outras. A boa notícia? A ServiceNow oferece uma forma nativa e segura de fazer isso através do List Control. Por que não alterar a UI Action Global? A UI Action “New” é uma das engrenagens base da plataforma. Se você adicionar uma condição nela para atender a uma regra de negócio específica da tabela de Change Request, por exemplo, corre o risco de desativar o botão para usuários de outras áreas. O List Control permite que você aplique essa regra apenas ao contexto daquela lista específica. Passo a Passo: Omitindo o Botão “New” Para este exemplo, vamos imaginar que você queira ocultar o botão na lista relacionada de Change Requests dentro de um evento de recuperação (tabela sn_recovery_event ). Acesse o registro: Abra qualquer registro da tabela pai (ex: um evento de recuperação específico). Localize a lista: Role até a lista relacionada onde o botão “New” aparece. Configure o List Control: Clique com o botão direito no cabeçalho da lista (onde estão os nomes das colunas) e navegue até Configure > List Control .   Aplique a restrição: 4.No formulário que abrir, marque a caixa de seleção “Omit new button”.   Se precisar de algo mais específico (como ocultar apenas para certos perfis), você pode usar o campo “New role”. Dica Extra: Caso você não veja o campo “Omit new button”, ele pode estar oculto no formulário. Basta clicar com o botão direito no topo do formulário de List Control e usar o Configure > Form Layout para adicioná-lo. Quando usar cada opção? Omit new button: Remove o botão completamente para todos naquela lista. Roles: O botão aparece apenas para quem possui o papel (role) especificado. Omit new condition: Permite usar um pequeno script se a lógica de ocultar o botão for dinâmica (ex: ocultar apenas se o registro pai estiver fechado). Conclusão Seguir as melhores práticas de “Configuration over Customization” (Configuração sobre Customização) é o que diferencia um desenvolvedor Júnior de um Sênior. Usar o List Control mantém sua instância limpa, fácil de atualizar (upgradable) e segura. Gostou dessa dica técnica? No meu artigo detalhado no SNUG, eu explico outros papéis e responsabilidades que todo profissional de ServiceNow deve conhecer. https://www.servicenow.com/community/brazil-snug/perfis-profissionais-em-servicenow-um-guia-detalhado/ta-p/3365048 E se você quer dominar a segurança da plataforma, não deixe de conferir o meu livro: “A Jornada da Segurança no ServiceNow”. #ServiceNow #LowCode #BestPractices #ITSM #Developer #SNUG     Créditos da Adaptação Brasileira Este guia foi complementado por: Tiago Macul  @Itallo Brandão  Com o apoio da Comunidade NowBridge.       https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       ... View more

  Uma dúvida comum surge nas comunidades de ServiceNow:   "Change Models substituem os Change Types?".   A resposta curta é: Não. Eles trabalham juntos para oferecer flexibilidade sem perder a governança. 1. Change Types: O "O Quê" (Classificação) Os Change Types (Normal, Standard, Emergency) são a base do ITIL no ServiceNow. Eles servem para categorizar o risco e a urgência da mudança. Eles definem o comportamento padrão da plataforma. São usados para relatórios e auditoria (Compliance). 2. Change Models: O "Como" (O Guia de Jornada) Os Change Models são uma camada de abstração que apoia a criação da mudança. Em vez de o usuário ser forçado a um fluxo rígido baseado apenas no Tipo, o Modelo define: Transições de Estado: Quais passos são necessários para aquele cenário específico? Condições de Pré-preenchimento: O modelo pode já vir com campos configurados para facilitar a vida do solicitante. Flexibilidade: Um modelo pode ser do tipo "Normal", mas ter um fluxo de aprovação simplificado porque é focado em "Cloud Provisioning".   3. Eles são a mesma coisa? (Respondendo à sua dúvida) Não. Conforme a documentação oficial aponta: Os Change Types estão "dentro" do conceito de modelos: Cada Change Model é associado a um Change Type. O Modelo é o motor que guia a experiência do usuário, enquanto o Tipo é o rótulo que mantém a integridade do processo ITIL. Analogia Prática: Imagine que o Change Type é a categoria da sua CNH (Carro, Moto, Caminhão). O Change Model é o GPS: ele te dá o caminho específico para o seu destino, garantindo que você siga as regras daquela categoria, mas permitindo rotas diferentes dependendo para onde você vai.   4. Por que usar Change Models para apoiar a criação? Redução de Erros: O usuário não precisa saber toda a política de mudanças; ele escolhe o modelo "Troca de Switch" e o sistema guia o resto. Agilidade: Você pode criar modelos específicos para times de DevOps que precisam de menos burocracia, sem mudar a estrutura global de "Normal Change" da empresa. Visualização: A nova Landing Page de Change Management utiliza os Modelos para oferecer uma experiência muito mais intuitiva (estilo "catálogo") do que o antigo menu lateral     ... View more

Guia de Troubleshooting: Metodologia Técnica para Homologação de Ambientes   Resumo: Este guia estabelece o workflow técnico e as melhores práticas para identificação de causa raiz durante processos de homologação, atualizações ou falhas após migrações de ambientes na Now Platform. 1. Introdução: O Princípio da Clareza Antes de iniciar qualquer análise técnica (logs ou scripts), o time de suporte deve garantir que a “pergunta técnica” está correta. O erro mais comum no troubleshooting de homologação é tentar corrigir algo que não foi bem definido. Checklist de Definição (wwww): O que (what): Qual é o comportamento esperado vs. o comportamento atual? Onde (where): Ocorre em todos os registros ou em um específico? (Ex: Apenas no portal ou no backend?) Quem (who): Afeta todos os usuários ou apenas usuários com roles específicas? Quando (when): Começou após um clone, uma atualização de Store App ou uma mudança de configuração manual? Princípios de Definição: A Pergunta Correta: O que o cliente está tentando realizar e o que exatamente está falhando? Frequência e Escopo: O erro é consistente (acontece sempre) ou intermitente? Afeta um usuário específico, uma role ou a instância inteira? O Gatilho: Qual foi a última alteração no ambiente? (Ex: Clone de PROD para DEV, instalação de patch ou alteração de System Property). Estrutura de Reporte de Análise (Padrão S.T.E.P.) Para acelerar a comunicação entre níveis (N1 para N3), toda análise de homologação deve ser reportada seguindo: S (Status): O impacto atual no negócio. T (Trigger): O que dispara o erro. E (Evidence): Logs anexados e códigos de erro específicos. P (Payload): Exemplo de dados (Sys_id) usados no teste. A Correlação entre Metodologias: O QUE? → Corresponde ao S (Status) e T (Trigger) No S.T.E.P.: O Status define o impacto (o que parou) e o Trigger define a ação (o que foi feito para o erro aparecer). Exemplo: “O botão de aprovação sumiu (Status) após o utilizador clicar em ‘Guardar’ (Trigger).” 2. ONDE? → Corresponde ao P (Payload) e T (Trigger) No S.T.E.P.: O Payload indica o Sys_id e a tabela (onde o dado está). O Trigger indica o local funcional (Portal, Workspace ou Backend). Exemplo: “Ocorre na tabela u_request_final (Payload) dentro do Service Portal (Trigger)." 3. QUEM? → Corresponde ao P (Payload) e S (Status) No S.T.E.P.: No Status/Payload incluímos se o impacto é apenas para utilizadores com a role itil ou se é geral. Exemplo: “Apenas utilizadores com a role ‘approver_user’ (Payload) visualizam o erro de ‘Access Denied’ (Status).” 4.QUANDO? → Corresponde ao T (Trigger) e E (Evidence) No S.T.E.P.: A Evidência traz o timestamp dos logs (o momento exato). O Trigger traz o evento que disparou a falha. Exemplo: “O erro foi registado às 14:22 (Evidence) imediatamente após o submetimento do formulário (Trigger).”   2. Workflow de Investigação Técnica Para uma análise eficaz, o suporte deve seguir esta hierarquia de ferramentas: A. Análise de Logs (O “Rastro” do Sistema) Sempre verifique os Log Files antes de tentar reproduzir o erro. System Logs -> Errors/Warnings: Procure por erros de “Scope”, “Access Denied” ou “Null Pointer Exception” que ocorreram no exato momento do teste de homologação.   Transaction Logs: Verifique o tempo de resposta. Se o ambiente de homologação está lento, o Transaction Log dirá se o gargalo é no SQL, no Browser ou no Processamento de Rede.   B. Debugging de Sessão (O Cenário Real)   Utilize as ferramentas de Session Debug para isolar o problema sem afetar outros usuários: Debug Security: Essencial para homologação. Verifica se uma ACL (Access Control) nova está bloqueando a visualização de campos após a migração.   Debug Business Rules: Identifica qual script de servidor alterou um valor inesperadamente durante a homologação.     C. Scripts Server-Side e Client-Side Se o erro for funcional (um botão não funciona ou um cálculo está errado): Server-Side: Use o Script Debugger para percorrer o código linha a linha. Coloque breakpoints em Business Rules ou Script Includes suspeitas. Client-Side: Utilize o JavaScript Log and Field Watcher para entender se o erro está no navegador do usuário (Client Scripts ou UI Policies). D. Deleted Records D. Auditoria de Registros Excluídos (Deleted Records) Nem sempre o problema é o que foi alterado, mas sim o que deixou de existir. Em ambientes de homologação, é comum que registros de configuração sejam excluídos acidentalmente. System Deleted Records: Se um comportamento que funcionava parou subitamente, verifique a tabela de sys_metadata_delete . Ela rastreia componentes de aplicação (como campos, tabelas ou scripts) que foram removidos. Undelete: O Salva-vidas: A ServiceNow permite restaurar registros excluídos através do módulo “Deleted Records”. Se um registro de dados (como um usuário de teste ou um grupo de aprovação) sumiu durante a homologação, você pode recuperá-lo com todos os seus relacionamentos originais. Filtro de Auditoria: Use o histórico de auditoria ( sys_audit ) para identificar quem excluiu e quando, cruzando essa informação com o seu Checklist de Clareza.   E. Node Log File Download (A Caixa-Preta do Servidor) Quando os logs convencionais não apresentam erros, mas o comportamento do ambiente de homologação continua instável, é necessário descer ao nível do servidor. Acesso: System Logs > Utilities > Node Log File Download . Quando usar: Essencial para investigar falhas de integração (Outbound/Inbound), erros de autenticação (SAML/SSO), ou quando um job agendado (Scheduled Job) simplesmente não inicia. Diferencial: Diferente do log do sistema, aqui você tem acesso aos logs brutos do Java e da infraestrutura do nó atual, permitindo identificar erros que a interface do ServiceNow pode não capturar.   F. Evidence (Evidências e Diagnóstico de Infraestrutura) Além dos logs de erro, a evidência definitiva da saúde do ambiente de homologação é extraída diretamente do motor da instância. Logs e Screenshots: Anexe os erros específicos encontrados nos passos anteriores. O “Check-up” Final via stats.do : Como última e crucial evidência, execute o comando stats.do diretamente no navegador (URL da instância + /stats.do). Ele fornece o "DNA" do ambiente naquele exato momento: Versão e Build: Confirme se o patch level é exatamente o mesmo entre os ambientes comparados. Node ID: Identifique em qual nó o erro ocorreu (útil para descartar falhas isoladas de hardware/nó). Servlet Memory: Verifique se há pressão de memória no ambiente de homologação, o que pode causar comportamentos erráticos em scripts que funcionam em Produção. Connected Users: Valide a carga do ambiente no momento do teste. G. XMLStats.do (Análise de Dados Estruturados) Enquanto o stats.do é visual, o XMLStats.do fornece uma visão detalhada e estruturada da performance do nó. O que observar: Ele permite uma análise granular do uso de semáforos, transações de banco de dados e estatísticas do agendador (Scheduler). Uso em Homologação: É a ferramenta ideal para scripts de monitoramento ou para comparar rapidamente dois ambientes em formato de texto estruturado. Ele revela contagens de transações e tempos médios de resposta que ajudam a identificar se o ambiente de homologação está sob estresse incomum.     H. Threads.do (A Visão de Processamento em Tempo Real) O Threads.do é a ferramenta definitiva para identificar processos travados ou "zumbis". O que ele faz: Mostra exatamente o que cada “thread” (linha de processamento) do servidor está executando naquele milésimo de segundo. Diagnóstico de Travamentos: Se a homologação “congelou”, o Threads.do revela qual script ou transação está consumindo todo o processamento do nó. Ele mostra o tempo que cada thread está ativa, permitindo identificar processos de longa duração que estão bloqueando o ambiente.     3. Isolamento da Causa Raiz (A Técnica do “Ponto de Falha”) Durante a homologação de ambientes, use o método de exclusão: Desative e Teste: Desative a última customização feita. O erro persiste? Se sim, a falha é nativa ou de uma configuração anterior. Compare Ambientes: O comportamento em Produção é diferente de Homologação? Use o Compare Environments ou verifique as System Properties ( sys_properties ) – muitas vezes um ID de integração ou uma propriedade de segurança está diferente entre os ambientes. 4. Documentação da Solução (O Ciclo do Conhecimento) O troubleshooting só é considerado encerrado quando o aprendizado é compartilhado/documentado para evitar que o problema se repita no próximo ciclo de homologação. Fato: O que foi encontrado. Causa Raiz: Por que o erro ocorreu (ex: falha de permissão de Cross-Scope). Resolução: Passo a passo da correção aplicada. Documentação Imediata (KCS): Se a solução foi “óbvia” ou “fácil”, ela deve ser um artigo de KB. São as soluções simples que mais consomem tempo do suporte quando não documentadas. Feedback para Automação: Se um erro foi encontrado manualmente, avalie: “Podemos criar um teste no ATF (Automated Test Framework) para que este erro seja pego automaticamente na próxima vez?”   Referências de Apoio Desvendando o Suporte ServiceNow: Benefícios e Recursos Disponíveis A Engrenagem do Suporte de TI: N1, N2, N3, NOC e SOC “A metodologia acima é baseada nas melhores práticas globais de engenharia de suporte. Recentemente, descobri que a própria ServiceNow oferece um treinamento oficial que aprofunda exatamente estes pontos de Debugging e Logs, o que valida que estamos seguindo o caminho padrão ouro da plataforma.”     Créditos da Adaptação Brasileira Este guia foi complementado por: Tiago Macul  Com o apoio da Comunidade NowBridge.     https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       ... View more

Recentemente, em 12 de janeiro de 2026, a ServiceNow publicou os detalhes do CVE-2025-12420. Trata-se de uma vulnerabilidade crítica de escalação de privilégios que afeta especificamente implementações da AI Platform.   Este artigo detalha a falha e, mais importante, fornece os passos técnicos para você validar se sua instância recebeu a devida manutenção.   🔍 O que é o CVE-2025-12420?   A vulnerabilidade foi identificada na estrutura de agentes de IA. Ela permitiria que um usuário não autenticado realizasse operações de personificação (impersonation) dentro do contexto da AI Platform. Severidade: Crítica (CVSS v4.0). Status: Corrigida pela ServiceNow em 30 de outubro de 2025 para clientes hospedados (Hosted). Risco: Até o momento, não há evidências de exploração desta falha na prática.   🛠️ Auditoria Técnica: Como verificar sua instância De acordo com o KB2587317, você pode confirmar manualmente se a correção foi aplicada seguindo estes passos: Acesse a tabela de propriedades ( sys_properties.list ) e verifique se a propriedade sn_aia.aia_a2a_authentication_token existe. Acesse a tabela de verificação de tokens ( token_verification.list ) e localize o registro ‘A2A Default Auth’. Validação: O valor da propriedade no passo 1 deve coincidir exatamente com a string ‘Token’ do registro no passo 2. Atenção: Se a propriedade não existir ou os valores forem diferentes, abra um caso no Now Support com o assunto: “CVE-2025-12420”.   📦 Versões Corrigidas (Store Apps) Se você utiliza instâncias Self-Hosted ou gerencia versões da Store manualmente, certifique-se de estar nestas versões (ou superiores): Now Assist AI Agents (sn_aia): 5.1.18 ou 5.2.19 Virtual Agent API (sn_va_as_service): 3.15.2 ou 4.0.4   Referências e Créditos Descoberta e Relatório: Aaron Costello e AppOmni (via processo de divulgação coordenada). Fonte Original: ServiceNow Knowledge Base (KB2587317) e Comunicação Interna (COMM2414080). Adaptação para a Comunidade: Tiago Macul.       KB2587317 CVE-2025-12420 - AI Security Maintenance - October 2025 - Overview KB CVE-2025-12420: https://nvd.nist.gov/vuln/detail/CVE-2025-55182       https://www.youtube.com/@servicenowbr/ https://www.facebook.com/groups/servicenowbrasil https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board https://www.linkedin.com/groups/5134493/ https://www.servicenow.com/community/user/viewprofilepage/user-id/73505 https://github.com/Tiagomacul/ https://www.tiktok.com/@servicenowbr https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9 https://www.linkedin.com/in/tiagomacul/ https://www.linkedin.com/company/now-bridge/       #ServiceNow #Security #CyberSecurity #NowAssist #AIPlatform #CVE202512420 #AppOmni #TiagoMacul #nowbridge ... View more