Auditoria de Context Definitions no Setup Audit Trail
Agora dá para rastrear quem mudou o quê nos context definitions do Context Service.
O Setup Audit Trail passou a registrar criação, atualização e exclusão de context definitions e seus componentes relacionados. Isso fecha uma lacuna de governança que existia desde que o Context Service ganhou espaço em cenários de Data 360 e Industries.
O que é
O Setup Audit Trail agora captura ações de criação, atualização e exclusão em context definitions e nas configurações relacionadas a elas: context nodes, attributes, tags, mappings e filters. Também registra criação e exclusão de transforms dentro do Context Service.
Ou seja, qualquer alteração estrutural em um context definition, desde adicionar um novo atributo até remover um mapping ou apagar um transform, fica documentada no log de auditoria padrão do Salesforce, o mesmo lugar onde você já consulta mudanças em campos, perfis e permission sets.
O histórico de alterações fica retido por 180 dias, o que dá uma janela razoável para investigar problemas de configuração ou responder a requisitos de governança que peçam evidência de quem alterou o quê e quando.
Por que importa
Context definitions viraram peça central para quem monta agentes com Agentforce, engines de recomendação ou automações que dependem de dados hidratados a partir do Data 360. O problema é que, até aqui, uma mudança em um context node ou em um filter podia quebrar silenciosamente o comportamento de um agente ou de um fluxo, sem deixar rastro claro de quem fez o quê. Já vi esse tipo de quebra silenciosa custar um dia inteiro de investigação numa org de cliente, só para descobrir que alguém tinha removido um mapping sem avisar ninguém.
Com o Setup Audit Trail cobrindo esse escopo, arquitetos ganham um ponto único de troubleshooting quando algo para de funcionar depois de uma alteração de configuração. Isso também ajuda em ambientes regulados, onde times de compliance exigem histórico documentado de mudanças em qualquer peça que alimenta decisões automatizadas ou IA generativa. Não é uma feature vistosa, mas resolve uma dor real de quem já teve que reconstruir manualmente o que mudou em um context definition para explicar um incidente.
Como se preparar
- Revise periodicamente o Setup Audit Trail das orgs que usam Context Service, especialmente antes e depois de releases ou deploys que toquem context definitions.
- Combine essa auditoria com processos de change management: se você já documenta mudanças em Flows e Apex, inclua context definitions, transforms e filters no mesmo checklist.
- Lembre que a retenção é de 180 dias. Se precisar de histórico mais longo para auditoria, exporte os logs periodicamente para um repositório externo.
- Se você dá suporte a agentes do Agentforce ou automações que dependem de hierarquias hidratadas via Context Service, use o audit trail como primeira parada ao investigar comportamento inesperado após uma mudança de configuração.
Nível de aplicação: Baixo
É apenas passiva ativação de rastreamento de auditoria, sem configuração complexa ou impacto funcional em processos existentes.
Considerações de arquiteto
- Inclua context definitions, transforms e filters no mesmo checklist de change management já usado para Flows e Apex.
- Estabeleça rotina de revisão do Setup Audit Trail antes e depois de deploys que toquem Context Service, para correlacionar incidentes com mudanças específicas.
- Se sua governança exige histórico acima de 180 dias, monte um processo de exportação periódica dos logs para um repositório externo desde já.
- Trate o audit trail como primeira parada de troubleshooting quando agentes do Agentforce ou automações que dependem de hierarquias hidratadas via Context Service apresentarem comportamento inesperado.
Pegadinhas:
- A retenção fixa de 180 dias pode não ser suficiente para requisitos regulatórios mais rígidos, exigindo exportação manual antecipada.
Este artigo faz parte do guia Flow na Winter '27, um item oficial por artigo. Fonte: release notes de Automation.