artigo
carreira no ecossistema ServiceNow: o que muda de nível para nível
certificação não é a carreira, é só o carimbo — o que realmente separa um developer júnior de um architect é o escopo da decisão que você toma.
Tem uma pergunta que aparece toda semana em algum fórum ou grupo de ServiceNow: "tirei o CSA, e agora?". A resposta curta é sempre insatisfatória — depende. Mas a resposta longa é mais interessante, porque o que separa alguém que fica estagnado em "faz configuração" de alguém que vira referência técnica não é quantas certificações tem na assinatura do e-mail. É o tamanho da decisão que essa pessoa é capaz de tomar sozinha, com confiança, e defender depois.
o que realmente muda de nível para nível
Pega dois desenvolvedores com o mesmo tempo de casa. Um deles sabe a fundo os métodos de GlideRecord, decora atalho de teclado no Studio, resolve qualquer bug de Business Rule em vinte minutos. O outro sabe menos sintaxe, mas quando propõe uma solução já chega com os trade-offs na mesa: "dá para fazer com Flow Designer, mas se o volume passar de X registros por dia o Scheduled Job vai ser mais previsível, e aqui está o porquê". Adivinha quem sobe mais rápido.
Isso não é força de vontade nem "soft skill" abstrata. É consequência direta de em que nível de escopo cada um está pensando:
| Nível | Escopo da decisão | O que muda de verdade |
|---|---|---|
| Developer Jr. | uma task | Executar bem uma feature já especificada. Aprender a plataforma a fundo o suficiente para não reinventar a roda. |
| Developer Pleno | uma user story inteira | Assumir a solução do início ao fim: Script Include bem estruturado, code review, entender por que aquela abordagem e não outra. |
| Sênior / Tech Lead | uma sprint ou release | Pensar em ciclo de vida — o que essa decisão custa daqui a três upgrades? Mentoria técnica, governança de código. |
| Solution Architect | a aplicação inteira | ADR, AS-IS/TO-BE, conversa com stakeholder que não sabe o que é sys_id. Modelo de dados pensado para os próximos anos, não para a sprint atual. |
| Enterprise Architect | o portfólio, várias organizações | Decisão de make-vs-buy, visão de três a cinco anos, e voz nos canais em que o cliente influencia o roadmap da própria ServiceNow (advisory boards, Idea Portal). |
Repare que o eixo não é "quanto você sabe de scripting". Um Enterprise Architect não precisa saber mais JavaScript que um developer pleno — precisa saber decidir em que nível da plataforma cada problema deve ser resolvido, coisa que, aliás, é o fio condutor deste guia inteiro desde o primeiro capítulo.
Um jeito prático de testar em que nível você já está: pega a última decisão técnica não trivial que você tomou. Você conseguiu explicar o trade-off para alguém que não é técnico, em uma frase, sem soar evasivo? Se sim, você já está pensando no nível de escopo acima do seu cargo atual — só falta o cargo alcançar.
certificação é carimbo, não é a carreira
Vamos ser diretos: uma certificação sozinha não paga conta. Ela é evidência de que você estudou um escopo específico de forma estruturada, e isso vale alguma coisa — abre entrevista, filtra currículo, dá confiança para um cliente que não te conhece. Mas ela não substitui a cicatriz de ter debugado uma ACL que vazava dado em produção às 2 da manhã.
O caminho mais comum é: CSA (System Administrator) primeiro — é pré-requisito de fato para praticamente tudo que vem depois, mesmo que seu foco final seja 100% técnico. Dali em diante, duas rotas que não se excluem:
- CAD (Certified Application Developer) se seu trabalho é escrever aplicação customizada, script, lógica sob medida.
- CIS (Certified Implementation Specialist), um por produto — ITSM, Discovery, Human Resources, CSM, Security Incident Response — se seu trabalho é configurar e implementar um módulo específico bem feito. (IntegrationHub, vale notar, não tem CIS própria: o que existe ali é uma micro-certification, mais curta e não supervisionada.)
No topo fica o CTA (Certified Technical Architect), e aqui vale um ajuste fino em relação ao que muita gente pensa: não é uma prova que você faz depois de estudar sozinho. É um programa de aplicação — hoje estruturado em torno de um projeto capstone, sessões ao vivo e um conjunto de pré-requisitos que normalmente inclui CSA, CAD, pelo menos duas CIS e alguns anos de experiência real de implementação em campo. Não é o próximo boleto que você paga, é uma trilha que se prepara com antecedência.
a plataforma que não espera
Aqui tem uma particularidade do ecossistema ServiceNow que não existe em toda stack: a plataforma lança duas versões principais por ano, e por muito tempo o esquema de nomes foi cidade em ordem alfabética — Quebec, Rome, San Diego, Tokyo, Utah, Vancouver, Washington DC, Xanadu, Yokohama, Zurich. Aí o alfabeto acabou, e agora, em 2026, a ServiceNow reiniciou o ciclo com nomes de país: Australia chegou em maio de 2026, e Brazil é a release prevista para o fim do ano. Sim — se você trabalha com ServiceNow no Brasil, seu país literalmente vai dar nome a uma versão da plataforma que você usa todo dia (grafado em inglês, como todo nome de release). É a curiosidade boba que rende gancho de conversa, mas também é um lembrete sério: cada uma dessas releases traz funcionalidade nova, comportamento alterado e coisa depreciada.
Ficar para trás não é falta de talento, é falta de rotina. Na prática, três fontes já resolvem a maior parte do problema:
- Release Notes de cada versão, lidas antes do upgrade da sua instância, não depois que algo quebrou.
- PDI (Personal Developer Instance), gratuita em developer.servicenow.com — o ambiente mais barato do mundo para testar sem medo de derrubar produção. Regra de ouro: o que você for implementar em produção, teste antes na PDI. O tempo gasto ali quase sempre sai mais barato que a tentativa e erro no ambiente real.
- Comunidade (community.servicenow.com) — não só para pedir ajuda, mas porque explicar um problema técnico para outra pessoa é, de longe, a forma mais eficiente de descobrir a lacuna que você não sabia que tinha.
e agora?
Chegamos ao capítulo 13, o último do Guia Definitivo do Desenvolvedor ServiceNow — encerrando a trilha que passou por modelo de dados, Business Rules, Flow Designer, integração, segurança, performance, Service Portal, deploy, discovery e anti-padrões. Três sugestões concretas para depois de ler este:
- Se você ainda não tem PDI, crie uma agora em developer.servicenow.com — é gratuita e é o único ambiente onde "quebrar por curiosidade" não tem custo nenhum.
- Escolha uma área para se aprofundar nos próximos meses (ITSM, Discovery, HRSD, o que for mais próximo do seu dia a dia) e comece a preparação para a certificação correspondente — não as cinco ao mesmo tempo.
- Se você quer entender por que um campo obrigatório na UI Policy às vezes simplesmente não obriga nada, client script é o último recurso e precedência de campos fecham o assunto — são os dois artigos que cobrem o capítulo 5 do guia.