A Resposta Breve
Ações são o ponto onde um agente para de falar e começa a fazer, e é por isso que a maior parte do risco e do custo de manutenção está concentrada nelas. Existem quatro formas de implementação: Ações Padrão, Flow, Apex e External Services acionando uma API externa. A escolha entre elas não é uma questão de capacidade – quase todas as ações são possíveis em qualquer uma delas – mas sim de quem as manterá, com que rapidez podem ser alteradas e como são testadas.
A ordem de escolha recomendada é de cima para baixo: começar com uma Ação Padrão, passar para o Flow quando for necessária lógica de negócios, para o Apex quando a complexidade for real e para External Services quando a verdade estiver fora do Salesforce. Cada degrau para baixo na escala adiciona um custo de manutenção e, portanto, exige uma justificativa.
Tabela de Decisão
| Implementação | Quando é Apropriado | Quem Mantém | Custo da Opção |
|---|---|---|---|
| Ação Padrão | Recuperação, atualização de campo, abertura de Case, resumo de registro | Administrador da plataforma | Flexibilidade limitada para regras de negócios |
| Flow | Regras de negócios variáveis, várias etapas, validação | Administrador ou proprietário do processo | Desempenho em alto volume, tratamento de erros limitado |
| Apex | Lógica complexa, processamento massivo, controle de erros | Apenas desenvolvedor | Cada alteração requer ciclo de implantação e testes |
| External Services / API | Fonte da verdade fora do Salesforce | Equipe de integração | Dependência da disponibilidade, latência e versões de terceiros |
A Primeira Regra: Descrição Antes da Implementação
Antes de escolher a tecnologia, escreva a descrição da ação. Isso pode parecer processual, mas é o elemento que determina se o agente executará a ação correta. O agente não lê o código – ele lê a descrição e decide com base nela.
Uma boa descrição inclui três partes: o que a ação faz, em que situações usá-la e, explicitamente, em que situações não usá-la. A terceira linha é a que é esquecida, e é ela que impede o agente de ativar uma ação de crédito quando o cliente apenas perguntou sobre a política de devoluções.
Os parâmetros devem ser mínimos e de um tipo definido. Um parâmetro de texto livre onde o agente deve preencher um valor de uma lista fechada é um convite a erros; uma lista de valores definida resolve isso sem lógica adicional.
Quando Usar Flow e Quando Usar Apex
Flow é o padrão para regras de negócios porque é visível e permite que o proprietário do processo entenda o que está acontecendo. Para agentes, uma vantagem adicional é a velocidade de correção: quando se descobre que a ação não está verificando as condições de elegibilidade, a correção pode ser feita no mesmo dia.
Apex é justificado em quatro situações: lógica com muitas ramificações que tornam o Flow ilegível, processamento de grandes volumes em uma única leitura, necessidade de controle preciso no tratamento de erros e transações, e integração que requer processamento de resposta complexo. Fora dessas situações, o Apex principalmente eleva o custo da próxima mudança.
A escolha também está ligada a uma dívida técnica existente. Uma organização que já carrega milhares de linhas de Apex sem testes deve pensar duas vezes antes de adicionar outra camada – as considerações completas são apresentadas em Salesforce Flow vs. Apex.
Ações com Sistemas Externos
Esta é a área onde as falhas chegam ao usuário final. Três decisões devem ser tomadas antes da construção: qual é o tempo máximo de espera, o que o agente diz quando a chamada falha e se é permitido tentar novamente.
Idempotência é o conceito crucial. Uma ação de leitura pode ser repetida com segurança. Uma ação que cria um registro, envia uma mensagem ou cobra um cartão – uma nova tentativa pode gerar duplicidade. A solução é uma chave única para cada solicitação que o sistema receptor identifica, ou uma renúncia consciente à nova tentativa.
A Latência é uma consideração de experiência, e não apenas técnica. Uma chamada que leva alguns segundos é aceitável em um canal de chat se o agente disser que está verificando; uma chamada que leva mais tempo do que isso requer um caminho assíncrono – o agente confirma o recebimento e atualiza quando a resposta chega.
Os padrões de tratamento de falhas de integração são detalhados em Tratamento de Erros de Integração no Salesforce.
Permissões no Nível da Ação
Cada Ação deve ser restrita por uma permissão separada. O erro comum é conceder ao agente um perfil amplo que cobre todas as ações, impedindo que uma ação específica seja aberta para um grupo sem abrir todas.
Princípio de trabalho: permissão mínima para cada ação, validação dentro da ação e não apenas nas instruções para o agente, e verificação de que a ação respeita o contexto do usuário. Não se deve confiar que as Instruções impedirão a execução – as instruções são orientação, não controle.
Quando Dividir uma Ação
Uma ação que realiza três coisas é difícil de testar e difícil de aprovar. Um sinal para dividir: quando parte da ação requer aprovação humana e parte não, quando partes diferentes exigem permissões diferentes, ou quando uma falha no meio deixa o processo em um estado inconsistente.
A divisão encarece um pouco a orquestração, mas compensa: cada parte é testada separadamente, o agente pode fazer pausas entre as partes e as permissões são precisas. A regra prática – uma ação, um critério de decisão.
O planejamento dos pontos de parada entre as partes é detalhado em Human-in-the-Loop no Agentforce.
Cenário: Uma Organização que Voltou do Apex para o Flow
Uma empresa de serviços construiu seis Ações em Apex em um projeto piloto, assumindo que assim obteria controle total. Em dois meses, descobriu-se que quatro delas haviam alterado a lógica três vezes cada – não por bugs, mas porque as regras de negócios foram descobertas em uso. Cada alteração exigia um desenvolvedor, testes e um ciclo de implantação de vários dias.
Na segunda rodada, as duas ações que permaneceram em Apex eram aquelas com múltiplas chamadas a um sistema externo e processamento de resposta. As outras quatro foram migradas para Flow, e o administrador da plataforma assumiu a responsabilidade por elas. O tempo médio de correção caiu de dias para horas.
A lição não foi que o Apex é ruim, mas que, na fase em que as regras ainda estão sendo formuladas, o custo da mudança é mais importante do que o custo inicial de construção.
Riscos e Ações Preventivas
| Risco | Como se Manifesta | Ação Preventiva |
|---|---|---|
| Descrição da ação vaga | O agente executa a ação errada | Descrição com "quando sim" e "quando não" e parâmetros definidos |
| Nova tentativa cega | Registros ou cobranças duplicadas | Chave única para a solicitação ou renúncia ao Retry |
| Ampla permissão para o agente | Ação sensível acessível a qualquer usuário | Permissão separada para cada Ação e validação dentro da ação |
| Toda a lógica em Apex | Cada mudança de negócio se torna um projeto de desenvolvimento | Flow para regras variáveis, Apex para complexidade real |
| Ação que faz três coisas | Falha no meio deixa estado inconsistente | Divisão por critério de decisão e por permissão |
Métricas para Ações
| Métrica | O que Revela | Frequência |
|---|---|---|
| Taxa de sucesso da Ação | Percentual de execuções concluídas com sucesso | Semanal |
| Taxa de ação errada | Percentual de casos em que uma ação incorreta foi selecionada | Em cada versão |
| Latência mediana por ação | Se a experiência permanece razoável | Semanal |
| Taxa de falhas de integração | Estabilidade dos sistemas de destino | Semanal |
| Tempo médio de correção | Se a implementação escolhida permite mudanças rápidas | Mensal |
Quando for necessário acompanhamento no planejamento da camada de Ações e na sua adaptação à arquitetura existente, o serviço Agentforce e AI é o caminho prático a seguir.
Checklist para Cada Ação
- ☐ Descrição escrita com "o quê", "quando sim" e "quando não"
- ☐ Parâmetros mínimos e de tipo definido
- ☐ Implementação de nível mais alto suficiente para a necessidade selecionada
- ☐ Permissão separada definida para a ação
- ☐ Validação reside dentro da ação e não apenas nas instruções
- ☐ Determinado se a ação é idempotente e qual a política de Retry
- ☐ Tempo máximo de espera e mensagem de falha para o usuário definidos
- ☐ Múltiplas ações de decisão divididas
- ☐ Cenário de teste para falha e não apenas para sucesso existente