SERVICENOW INBOUND EMAIL

tiagomacul · 13m ago

SERVICENOW INBOUND EMAIL

Recebimento de e-mails e criação automática de Incidents no ITSM

Guia técnico completo | ServiceNow + caixa postal corporativa

Artigo técnico | Versão 2.0 | Novembro de 2026

Baseado em documentação oficial ServiceNow

Objetivo Demonstrar, de ponta a ponta, como uma mensagem recebida em uma caixa postal pode ser lida pelo ServiceNow, registrada em Email [sys_email], classificada e processada por uma Inbound Email Action para criar um Incident, incluindo testes, troubleshooting e recomendações arquiteturais.

Conteúdo

Introdução e visão geral
Arquitetura da solução
Caixa postal x Inbound Email Action
Configuração da conta de e-mail
Conexão, autenticação e segurança
Comportamento da mailbox
Habilitação do recebimento
O registro Email [sys_email]
Classificação New, Reply e Forward
Watermark e associação a registros
Criando a Inbound Email Action
Condições e roteamento
Script para criação do Incident
Identificação do Caller
Anexos
Teste ponta a ponta
Troubleshooting
Inbound Email Flow x Inbound Email Action
Considerações arquiteturais: quando usar e-mail
Arquitetura recomendada
Boas práticas e controles
Fluxo completo
Conclusão
Referências oficiais ServiceNow

1. Introdução e visão geral

Um cenário comum em implementações ServiceNow é permitir que usuários ou sistemas enviem mensagens para uma caixa postal corporativa e que essas mensagens sejam transformadas automaticamente em registros na plataforma. No IT Service Management (ITSM), um dos casos clássicos é a criação de Incident a partir de um e-mail recebido.

Usuário / Sistema

Caixa postal

ServiceNow

Inbound Processing

Incident

Figura 1 - Visão simplificada do cenário de Inbound Email para ITSM.

A capacidade de Inbound Email não é apenas um “script que lê e-mail”. Há camadas distintas: a infraestrutura de e-mail, a conta configurada no ServiceNow, o registro técnico da mensagem em Email [sys_email], a classificação da mensagem e, por fim, a automação que cria ou atualiza o registro de negócio.

Ponto-chave Receber e-mail no ServiceNow é uma capacidade nativa. A decisão arquitetural mais importante é definir quando o e-mail será apenas um canal de entrada e quando uma integração estruturada, como API, deve ser a interface principal.

2. Arquitetura da solução

Em uma implementação corporativa, a arquitetura pode ser representada pelas seguintes etapas:

Remetente

Mail Server
Microsoft 365 / Exchange

POP3 / IMAP

Email Account

Email [sys_email]

Inbound Action

Incident

Figura 2 - Arquitetura lógica de recebimento e processamento.

Camada	Responsabilidade
Mail Server	Receber a mensagem enviada pelo usuário ou sistema e mantê-la na mailbox configurada.
Email Account	Definir como o ServiceNow se conecta à mailbox externa.
Email [sys_email]	Persistir e registrar tecnicamente a mensagem recebida.
Inbound Processing	Identificar remetente, classificar New/Reply/Forward e procurar registro relacionado.
Inbound Email Action / Flow	Aplicar condições e lógica de negócio.
Incident [incident]	Registrar o ticket que será tratado pelo processo ITSM.

A ServiceNow também oferece infraestrutura padrão de e-mail associada à instância. Quando o requisito é utilizar uma caixa corporativa específica, uma conta externa pode ser configurada conforme os protocolos e mecanismos de autenticação suportados pela plataforma e pelo provedor de e-mail.

3. Caixa postal x Inbound Email Action

É fundamental separar o recebimento da mensagem do processamento de negócio.

3.1 Camada de recebimento

A camada de recebimento responde à pergunta: “Como o ServiceNow acessará a caixa postal?”. Exemplos de endereços seriam servicedesk@empresa.com ou incidentes@empresa.com. Essa camada está relacionada à configuração de Email Account e à infraestrutura do servidor de e-mail.

3.2 Camada de processamento

Depois que a mensagem é recebida e registrada, a plataforma precisa decidir o que fazer. Nessa camada entram Inbound Email Actions ou Inbound Email Flows. Para este laboratório, o mecanismo principal será uma Inbound Email Action criando um Incident.

Importante Inbound Email Flows têm precedência sobre Inbound Email Actions. Em ambientes que já utilizam flows de inbound, é necessário verificar se um flow consumiu a mensagem antes de concluir que a Inbound Email Action “não funcionou”.

4. Configuração da conta de e-mail

As contas de e-mail armazenam as informações necessárias para conexão com servidores externos. O registro técnico da conta fica associado à tabela sys_email_account.

4.1 Criar a conta

Na interface clássica, a administração das contas pode ser acessada em System Mailboxes > Administration > Email Accounts. O nome e a localização dos módulos podem variar conforme a release e a experiência de navegação habilitada na instância.

Figura 3 - Navegação para System Mailboxes > Administration > Email Accounts.

A opção Email Accounts abre a lista das contas configuradas para envio e recebimento. Em uma instância padrão podem existir contas fornecidas pela própria ServiceNow, como ServiceNow POP3 e ServiceNow SMTP. Para integrar uma caixa postal corporativa, crie uma conta específica em vez de alterar uma conta padrão sem uma decisão arquitetural explícita.

Figura 4 - Lista de Email Accounts com exemplos de contas POP3 e SMTP.

Na lista, observe principalmente Name, Active, Type, Server e Port. Para adicionar uma conta, selecione New. O protocolo de recebimento deve ser escolhido de acordo com o serviço de e-mail e com as políticas da organização.

Figura 5 - Formulário de criação de uma nova Email Account.

Campo	Como preencher / validar
Name	Nome administrativo claro para identificar a finalidade da conta.
Type	Selecione o protocolo suportado para recebimento, como POP3 ou IMAP, conforme disponibilidade da release e do servidor.
Authentication	Escolha o método de autenticação aprovado pela organização. Não presuma Password como padrão para ambientes corporativos.
Server	Hostname do servidor de e-mail fornecido pela equipe responsável pela mensageria.
User name / Password	Credenciais somente quando o método de autenticação selecionado exigir esses campos. Trate segredos conforme a política de segurança.
Connection Security	Configure a proteção de transporte compatível com o servidor e com a política corporativa.
Port	Porta correspondente ao protocolo e à segurança escolhidos; valide com a equipe de mensageria.
System Address Filter	Use quando houver requisito de filtragem de endereços do sistema, conforme o desenho da solução.
Active	Ative somente após validar parâmetros, autenticação, conectividade e impacto operacional.
Enable debug output	Use temporariamente para diagnóstico. A própria tela alerta que o log registra dados brutos trocados com o servidor; desabilite após o troubleshooting.

Importante: os valores de servidor, porta, segurança e autenticação mostrados em exemplos de tela não devem ser copiados para produção. Eles precisam refletir o provedor de e-mail, a release ServiceNow e as políticas de segurança da organização.

Acesse a área administrativa de Inbound Email / Email Accounts da sua release.
Selecione a opção para adicionar uma nova conta.
Escolha o protocolo de recebimento aplicável, como IMAP ou POP3.
Informe servidor, porta, endereço da mailbox e método de autenticação.
Salve a configuração e execute o teste de conexão disponível na interface.

Configuração	Exemplo / orientação
Name	Corporate Service Desk Inbound
Type	IMAP ou POP3, conforme arquitetura
Email	servicedesk@empresa.com
Server	Servidor definido pela equipe de mensageria
Port	Conforme protocolo e política corporativa
Security	TLS/SSL conforme política
Authentication	Método aprovado pela equipe de identidade/mensageria

Microsoft 365 Em ambiente corporativo, não assuma usuário/senha como solução definitiva. O método de autenticação deve ser validado com a equipe responsável pelo tenant, identidade, OAuth e políticas de segurança.

5. Conexão, autenticação e segurança

O desenho deve ser validado com as equipes de mensageria, identidade e segurança. O fato de a conexão técnica funcionar não elimina requisitos de governança.

Mailbox dedicada à integração, quando possível.
Autenticação alinhada às políticas corporativas e ao provedor de e-mail.
Princípio de menor privilégio para a conta utilizada.
Controle de remetentes e destinatários autorizados a acionar automações.
Tratamento de anexos, conteúdo sensível e mensagens maliciosas.
Auditoria de mensagens processadas e registros criados.

6. Comportamento da mailbox

Um ponto que precisa ser validado antes de colocar a solução em produção é o comportamento da leitura das mensagens na caixa externa. A documentação da ServiceNow descreve o processamento das mensagens pela conta configurada e recomenda atenção ao uso da mailbox por outros consumidores.

Recomendação Para uma integração corporativa, prefira uma mailbox provisionada especificamente para o ServiceNow, evitando concorrência com usuários ou aplicações que também dependam das mesmas mensagens.

Esse cuidado reduz ambiguidades de processamento e facilita suporte, auditoria e troubleshooting.

7. Habilitação do recebimento

Além de configurar a conta, o recebimento de e-mail precisa estar habilitado na instância. Entre as propriedades relacionadas ao mecanismo inbound está glide.email.read.active. A experiência administrativa também possui propriedades para identificação de replies, forwards, domínios confiáveis e comportamento de usuários não reconhecidos.

Item	O que validar
Inbound email habilitado	A instância está autorizada a ler mensagens recebidas.
Reply prefixes	Prefixos usados para reconhecer respostas, como RE:.
Forward prefixes	Prefixos usados para reconhecer encaminhamentos, como FW:/FWD:.
Trusted domains	Política aplicável para domínios/remetentes confiáveis.
Usuários desconhecidos	Definir se haverá criação automática ou tratamento como Guest, conforme política.

8. O registro Email [sys_email]

Quando a mensagem chega ao ServiceNow, o registro Email [sys_email] é a principal evidência técnica do processamento. Para troubleshooting, essa tabela deve ser verificada antes de investigar a lógica do Incident.

Informação	Uso no diagnóstico
From / sender	Identificar quem enviou a mensagem.
Recipients	Validar To/Cc e roteamento.
Subject	Verificar assunto e prefixos New/Reply/Forward.
Body / body_text	Conteúdo utilizado pela automação.
Headers	Analisar Message-ID, In-Reply-To e metadados.
Receive type	Confirmar New, Reply ou Forward.
State	Verificar se a mensagem ficou Ready, Processed ou foi ignorada.
Logs relacionados	Entender por que uma action foi executada ou ignorada.

O objeto global email disponibiliza propriedades úteis ao script, como email.to, email.direct, email.copied e email.body_text. A forma como body e body_text são preenchidos depende também do Content-Type recebido.

9. Classificação New, Reply e Forward

Antes de executar a automação, o ServiceNow classifica a mensagem. Essa classificação influencia diretamente quais Inbound Email Actions podem executar.

Tipo	Interpretação	Exemplo
New	Mensagem não reconhecida como resposta ou encaminhamento.	Problema para acessar aplicação
Reply	Resposta identificada por prefixo, watermark, In-Reply-To ou mecanismos relacionados.	RE: INC0012345 - Falha de acesso
Forward	Mensagem cujo assunto inicia com prefixo de encaminhamento reconhecido.	FW: Falha de acesso

Atenção a Forward O comportamento de mensagens Forward pode ser diferente de Reply. Se o negócio quiser que encaminhamentos atualizem registros existentes, os prefixos e a lógica precisam ser desenhados conscientemente e testados.

10. Watermark e associação a registros

Quando uma mensagem é reconhecida como Reply ou Forward, o ServiceNow pode tentar relacioná-la a um registro existente. Um mecanismo clássico é o watermark inserido em mensagens outbound. Quando não encontra watermark, a plataforma também pode procurar um número de registro no assunto ou corpo, conforme o fluxo de processamento.

Notificação do Incident

Watermark / número

Usuário responde

Inbound Email

Incident existente

Figura 6 - Associação de uma resposta a um registro existente.

Além de watermark e número, headers como In-Reply-To podem participar da identificação de uma resposta. O acesso do usuário ao registro também pode influenciar o processamento em cenários de reply.

Resultado desejado Novo e-mail → criar Incident. Resposta relacionada → localizar Incident existente e atualizá-lo, evitando a criação de um novo ticket para cada mensagem da conversa.

11. Criando a Inbound Email Action

Para o laboratório, criaremos uma ação responsável por transformar uma mensagem New em Incident.

As telas a seguir são capturas de uma instância ServiceNow e mostram a navegação e a estrutura real do formulário. Algumas delas utilizam a ação padrão “Create Enhancement” apenas como referência visual. Para o cenário deste artigo, os valores devem ser adaptados para criação de Incident conforme indicado abaixo.

Figura 11 - Navegação: System Policy > Email > Inbound Actions.

Figura 12 - Novo registro de Inbound Email Action. Neste artigo, a ação será configurada para Incident.

Figura 13 - Exemplo ServiceNow “Create Enhancement”, guia When to run. Use a tela como referência visual; adapte Target table, nome e condições para Incident.

Figura 14 - Exemplo ServiceNow “Create Enhancement”, guia Actions. O script exibido pertence ao exemplo de Enhancement e não deve ser reutilizado para Incident.

Configuração equivalente para o nosso exemplo: Create Incident from Email

Não altere a ação padrão “Create Enhancement”. Crie uma nova Inbound Email Action e configure-a especificamente para Incident. A tabela abaixo traduz os campos mostrados nas capturas para o cenário deste artigo.

Campo	Valor do exemplo	Finalidade
Name	Create Incident from Email	Nome claro para identificar a automação.
Target table	Incident [incident]	O registro criado será um Incident.
Action type	Record Action	Executa ações sobre um registro da tabela alvo.
Active	Marcado	Habilita a ação após a configuração e os testes.
Stop processing	Conforme desenho	Marque quando nenhuma outra action deva continuar após esta correspondência.
Type	New	Executa apenas para mensagens classificadas como novas.
Execution Order	100	Define a ordem relativa entre actions; menor valor executa primeiro.
Required roles	Em branco, salvo requisito específico	Evite restringir por role sem necessidade do processo.
From	Em branco ou remetente controlado	Use somente quando a action precisar aceitar um remetente específico.
Conditions	Restrinja destinatário/assunto quando aplicável	Evita que qualquer e-mail recebido crie Incident indiscriminadamente.

Exemplo de condição

Se a caixa for dedicada exclusivamente à criação de Incidents, a condição pode ser simples. Em ambientes com múltiplas contas ou automações, restrinja a action pelo destinatário e/ou por um padrão de assunto. Evite copiar a condição do exemplo de Enhancement (`email.subject.indexOf("Enhancement:") == 0`), pois ela pertence a outro caso de uso.

Script adaptado para Incident

// Inbound Email Action - Create Incident from Email
current.short_description = email.subject;
current.description = email.body_text;
current.contact_type = 'email';

// O ServiceNow identifica o remetente e disponibiliza o usuário no contexto
// quando há correspondência válida. Valide o comportamento na sua release.
if (gs.getUserID()) {
current.caller_id = gs.getUserID();
}

current.insert();\n

Importante: não utilize `gs.createUser(email.from)` automaticamente apenas porque ele aparece em um exemplo de outra Inbound Email Action. A criação automática de usuários a partir de remetentes deve seguir a política de segurança, trusted domains e governança de identidade da organização.

Navegue para System Policy > Email > Inbound Actions (o caminho pode variar conforme a experiência/release).
Selecione New.
Defina o Target table como Incident [incident].
Configure o tipo da mensagem como New.
Defina uma ordem coerente com as demais actions existentes.
Avalie o uso de Stop processing para impedir que outra action processe a mesma mensagem após a regra desejada.

Campo	Valor de exemplo
Name	Create Incident from Corporate Email
Target table	Incident [incident]
Action type	Record Action
Active	true
Type	New
Order	100
Stop processing	true

A plataforma avalia actions aplicáveis em ordem crescente. Uma action com menor Order é avaliada antes de outra com maior valor. Stop processing deve ser usado com consciência, pois altera o encadeamento de processamento.

12. Condições e roteamento

Não é recomendável permitir que qualquer mensagem recebida em qualquer conta crie indiscriminadamente um Incident. A action deve possuir critérios claros.

Destinatário ou mailbox esperada.
Domínio/remetente permitido, quando aplicável.
Assunto ou padrão de mensagem, se o cenário exigir.
Tipo New/Reply/Forward correto.
Papéis ou contexto do remetente, quando necessário.
Condições que evitem loops e mensagens automáticas indevidas.

// Exemplo conceitual de condição no script
if (email.direct && email.direct.toLowerCase().indexOf('servicedesk@empresa.com') >= 0) {
// processar mensagem destinada à mailbox do Service Desk
}

Evite fragilidade Condições baseadas apenas em texto exato do Subject podem quebrar quando o sistema remetente altera o assunto. Quando possível, use critérios mais estáveis e normalize comparações de texto.

13. Script para criação do Incident

Uma implementação simples pode utilizar o assunto como Short description e o corpo em texto como Description. O exemplo abaixo é didático e deve ser adaptado aos campos obrigatórios, regras de negócio e políticas do ambiente.

// Inbound Email Action - exemplo didático
current.short_description = email.subject;
current.description = email.body_text;
current.contact_type = 'email';

// O usuário identificado pelo processamento inbound pode ser usado
// conforme a política e o desenho do ambiente.
if (gs.getUserID()) {
current.caller_id = gs.getUserID();
}

current.insert();

Origem no e-mail	Destino no Incident
Subject	Short description
Body text	Description
Remetente identificado	Caller, conforme desenho
Canal	Contact type = Email
Attachments	Anexos associados ao registro, conforme processamento

Produção Antes de utilizar o script em produção, valide campos obrigatórios, assignment, categorização, ACLs, Business Rules, Data Policies, regras anti-loop, anexos e tratamento de remetentes desconhecidos.

14. Identificação do Caller

A plataforma tenta identificar o remetente por meio do endereço de e-mail e relacioná-lo a User [sys_user]. Quando existe correspondência, o processamento pode ocorrer no contexto desse usuário. Se não houver correspondência, o comportamento depende das propriedades e políticas configuradas, incluindo cenários de criação automática de usuário ou uso de Guest.

From: joao@empresa.com

Busca em sys_user

Usuário encontrado

Contexto inbound

Caller do Incident

Figura 11 - Exemplo de identificação do remetente.

Endereços de e-mail únicos em sys_user são importantes para reduzir ambiguidades. Também é necessário considerar ACLs: em respostas a registros existentes, o usuário identificado pode precisar ter acesso ao registro para que o processamento ocorra como esperado.

15. Anexos

Anexos recebidos por e-mail podem fazer parte do processamento inbound e ser associados ao registro criado. Isso é útil para screenshots, logs e evidências enviados pelo usuário ou por sistemas.

E-mail

screenshot.png
log.txt

Inbound Processing

Incident

Attachments

Figura 12 - Fluxo conceitual de anexos.

Segurança Em ambiente bancário, anexos exigem atenção especial a malware, conteúdo sensível, tamanho, tipos permitidos, retenção e controles de segurança já existentes na organização.

16. Teste ponta a ponta

O teste deve comprovar cada camada, e não apenas verificar se o Incident apareceu.

To: servicedesk@empresa.com
Subject: Teste ServiceNow - Falha de acesso

Não consigo acessar o sistema de testes.
Favor verificar.

Confirme que a mensagem chegou à mailbox corporativa.
Confirme que o ServiceNow leu a mensagem.
Localize o registro correspondente em Email [sys_email].
Valide Receive type e State.
Verifique os logs relacionados ao processamento inbound.
Confirme qual Inbound Email Flow ou Action processou a mensagem.
Abra o Incident criado e valide Caller, Short description, Description, Contact type e anexos.
Responda a uma notificação do Incident e valide se a resposta atualiza o registro esperado, quando esse comportamento fizer parte do escopo.

17. Troubleshooting

O diagnóstico deve ser executado em camadas. Começar diretamente pelo script da Inbound Email Action pode esconder problemas de conexão, classificação ou condição.

Etapa	Pergunta	Próxima verificação
1	A mensagem chegou à mailbox?	Mensageria / Microsoft 365 / Exchange
2	ServiceNow conseguiu ler a mailbox?	Email Account, autenticação e Email Reader
3	Existe registro em sys_email?	Se não, problema anterior ao processamento de negócio
4	Como foi classificada?	New, Reply ou Forward
5	Há Flow inbound aplicável?	Flows têm precedência sobre actions
6	A condition da action corresponde?	Type, target, condição e order
7	A action foi executada?	Logs relacionados ao Email
8	O script criou/atualizou o registro?	ACL, Business Rule, campos obrigatórios, script
9	O Incident está correto?	Mapeamento, caller, anexos, categorização

17.1 Quando a mensagem fica Ready ou é ignorada

Os logs do registro de e-mail podem indicar por que uma Inbound Email Action foi ignorada, por exemplo quando o tipo da mensagem não corresponde ao Type da action ou quando uma condição não é atendida.

17.2 Quando a conexão testa OK, mas nenhum e-mail chega

Além de autenticação e conectividade, versões atuais podem utilizar Email Account Groups no processamento do Email Reader. Se a leitura não ocorrer apesar de o teste de conexão funcionar, o estado e a configuração dos grupos de conta podem fazer parte do diagnóstico.

17.3 Body e body_text inesperados

A composição de body e body_text depende do Content-Type recebido. Mensagens text/html e text/plain podem resultar em geração automática de uma das representações. Ao diagnosticar formatação ou conteúdo ausente, verifique os headers e o Content-Type.

18. Inbound Email Flow x Inbound Email Action

Nas versões atuais, a ServiceNow permite automação inbound por flows e por Inbound Email Actions. Flows oferecem uma abordagem visual e reutilizável, enquanto actions são um mecanismo clássico e amplamente utilizado.

Aspecto	Inbound Email Flow	Inbound Email Action
Modelagem	Visual no Workflow Studio / Flow Designer	Configuração + script/ações
Reuso	Ações e subflows reutilizáveis	Mais dependente da implementação da action
Código	Pode reduzir necessidade de script	Pode utilizar script diretamente
Precedência	Processado antes das actions	Avaliada depois dos flows aplicáveis
Uso	Boa opção para novos desenhos orientados a flow	Útil para legado, OOB e cenários específicos

Decisão de arquitetura Para uma nova implementação, avalie primeiro se o requisito pode ser atendido de forma clara com Inbound Email Flow. Se a escolha for Inbound Email Action, documente a razão e mantenha a lógica simples e testável.

19. Considerações arquiteturais: quando usar e-mail

Tecnicamente, o ServiceNow pode receber mensagens de uma caixa postal corporativa. Porém, isso não significa que e-mail deva automaticamente ser escolhido como interface principal entre sistemas. A decisão deve considerar a natureza do produtor, o nível de estruturação dos dados, os requisitos de segurança, rastreabilidade, volume e tratamento de erros.

19.1 Quando e-mail faz sentido

O processo é naturalmente iniciado por pessoas via e-mail.
O sistema de origem não oferece integração estruturada viável no momento.
O e-mail é um canal transitório controlado durante uma migração.
Há necessidade de receber evidências ou mensagens humanas sem exigir um portal/interface adicional.

19.2 Quando avaliar API ou integração estruturada primeiro

O produtor é outro sistema corporativo.
Há payload estruturado e campos obrigatórios bem definidos.
É necessário retorno síncrono ou tratamento formal de erro.
Há volume elevado ou necessidade de idempotência.
A rastreabilidade de integração precisa ser determinística.
O contrato de integração precisa ser versionado e governado.

Recomendação arquitetural Posicionar Inbound Email como um canal válido e controlado, não como substituto automático de uma integração estruturada. Se o produtor da informação for um sistema, avaliar API/IntegrationHub antes de consolidar o e-mail como gatilho definitivo.

20. Arquitetura recomendada

Uma arquitetura corporativa pode suportar simultaneamente canais humanos e integrações de sistema, mantendo o Incident como destino comum.

Usuário
E-mail

Mailbox
corporativa

ServiceNow
Inbound Email

Incident / Case

Figura 13 - Canal humano por e-mail.

Sistema
corporativo

API / IntegrationHub

ServiceNow

Incident / Case

Figura 14 - Integração estruturada para sistemas.

O desenho final deve estabelecer qual canal é autorizado para cada produtor, como ocorre a autenticação, quais dados são obrigatórios, como duplicidades são evitadas e como falhas serão monitoradas.

21. Boas práticas e controles

Prática	Motivo
Mailbox dedicada	Reduz concorrência e facilita suporte.
Condições específicas	Evita criação indevida de tickets.
Order documentado	Evita conflitos entre actions.
Stop processing consciente	Evita múltiplos processamentos não intencionais.
E-mails únicos em sys_user	Melhora identificação do remetente.
Tratamento distinto de New/Reply/Forward	Evita duplicidades e atualizações erradas.
Monitoramento de sys_email	Cria evidência operacional para troubleshooting.
Preferir critérios estáveis	Evita dependência frágil de Subject exato.
Governança de anexos	Reduz riscos de segurança e dados sensíveis.
Avaliar Flow para novos desenhos	Pode reduzir customização e scripts.
Testar ACLs do remetente	Importante para replies e registros existentes.
Documentar fallback e erro	Essencial para operação e sustentação.

22. Fluxo completo

Usuário / Sistema

Mailbox

Email Account

sys_email

Classificação

Flow / Action

Incident

Figura 15 - Fluxo completo de Inbound Email.

O fluxo operacional completo é: a mensagem é recebida pela infraestrutura de e-mail; o ServiceNow acessa a mailbox; cria o registro técnico em sys_email; classifica a mensagem; identifica remetente e possível registro relacionado; avalia flows/actions; e finalmente cria ou atualiza o Incident.

23. Conclusão

Inbound Email é uma capacidade nativa e madura do ServiceNow para transformar mensagens recebidas em ações na plataforma. Para ITSM, pode ser utilizado para criar Incidents e para atualizar registros existentes a partir de respostas, desde que classificação, associação, segurança e condições estejam corretamente configuradas.

A solução de receber e-mails no ServiceNow é tecnicamente viável pensando em receber mensagens de uma caixa corporativa. A decisão de arquitetura deve, entretanto, distinguir comunicação humana de integração sistema-a-sistema. Quando o produtor for um sistema e houver alternativa estruturada, API ou mecanismos de integração devem ser avaliados antes de tornar e-mail o gatilho definitivo.

24. Referências oficiais ServiceNow

Email accounts - Contas SMTP/POP3/IMAP e configuração de contas de e-mail. Abrir referência oficial

Basic email setup - Configuração e infraestrutura padrão de e-mail. Abrir referência oficial

Inbound email - Administração de inbound email, contas, propriedades e ações. Abrir referência oficial

Inbound email actions - Funcionamento das Inbound Email Actions. Abrir referência oficial

Create an inbound email action - Procedimento para criação de Inbound Email Action. Abrir referência oficial

Inbound action type criteria - Critérios New, Reply e Forward. Abrir referência oficial

Inbound email action processing - Processamento, associação e identificação do remetente. Abrir referência oficial

Inbound email action examples - Exemplos oficiais de ações inbound. Abrir referência oficial

Automating system responses to inbound email - Inbound Email Flows e precedência em relação às actions. Abrir referência oficial

ServiceNow Developers - Inbound Email - Parsing, email variable, identificação do remetente, watermark e actions. Abrir referência oficial

KB0535493 - Reviewing emails getting ignored by inbound actions - Troubleshooting de actions ignoradas e logs relacionados. Abrir referência oficial

KB0681056 - body and body_text - Comportamento de body/body_text conforme Content-Type. Abrir referência oficial

KB3233915 - external inbox / account groups - Troubleshooting atual de leitura de mailbox e Email Account Groups. Abrir referência oficial

KB0957760 Inbound Email FAQ - Abrir referência oficial

Nota sobre releases Os nomes de menus e algumas telas podem variar entre famílias de release e experiências administrativas. Antes de executar o procedimento no ambiente do cliente, valide a documentação correspondente à release instalada e as políticas de segurança do tenant de e-mail.