Se você chegou aqui procurando como mudar um limite de alçada de aprovação no Salesforce, a resposta curta é: depende de onde a alçada está configurada. E é justamente esse "depende" que costuma virar um chamado para o time técnico. Vamos ao prático primeiro, e depois ao que ninguém costuma contar.

Uma alçada de aprovação é o valor a partir do qual uma proposta, um desconto, um limite de crédito ou um comissionamento precisa de aprovação de um nível acima. No Salesforce, esse valor normalmente mora em um de três lugares:

1. No Approval Process, dentro dos critérios de entrada (entry criteria) ou nos critérios das etapas (step criteria). Para mudar o valor, você edita o critério, o que em geral exige desativar o processo de aprovação, ajustar e reativar.

2. Em um campo de fórmula ou custom field que alimenta esse critério. Mudar a alçada significa mexer na fórmula que calcula ou compara o valor.

3. Em um Flow, quando a lógica de aprovação foi montada via automação, com o valor embutido em um elemento de decisão ou em uma variável.

Em qualquer um dos três, a alteração tende a passar por um administrador ou desenvolvedor, validação em sandbox e deploy para produção. Em operações com governança madura, isso vira um change request com fila, teste e janela de publicação.

Funciona. Mas repare no que aconteceu: mudar um número de negócio (a alçada) virou, na prática, mudar configuração de sistema. Três consequências aparecem quando esse número muda com frequência.

A primeira: a área de negócio não consegue mudar sozinha. Cada ajuste de alçada por campanha, sazonalidade ou política nova depende de quem tem acesso técnico. O dono da política não é o dono da regra.

A segunda: não sobra histórico limpo da regra. Se daqui a seis meses alguém perguntar "qual era a alçada aplicada no dia 12 de março, e quem mudou?", a resposta vira arqueologia de change set e memória institucional, não uma consulta direta.

A terceira: a lógica cresce e esbarra em limite. Conforme as exceções se acumulam (alçada diferente por produto, por região, por canal, por faixa de risco), a automação fica pesada e começa a esbarrar nos governor limits do Salesforce.

Nenhuma dessas consequências é defeito da plataforma. O Salesforce é um CRM excelente, e o motor de aprovação dele resolve muito bem cadeias simples e estáveis. O problema aparece quando a alçada deixa de ser estável: quando ela é, na verdade, uma regra de negócio viva, que muda na velocidade do mercado e não na velocidade do deploy.

A separação que resolve isso é conhecida em arquitetura de software: a regra de negócio não deveria depender de código (nem de configuração de uma plataforma de CRM) para mudar. Ela vive em uma camada de decisão própria, que o Salesforce consome via API. Quando a alçada muda, o analista de negócio altera a regra nessa camada, testa e publica. O Salesforce continua sendo o CRM. A decisão sobre o que precisa de aprovação passa a ter versão, autor, critério e timestamp registrados a cada chamada, com rollback sem redeploy.

Na prática, isso muda duas coisas. Muda quem controla a regra: sai do time técnico, entra na área que entende a política. E muda o que você consegue mostrar numa auditoria: não o log de um sistema, mas a decisão com o critério exato que a gerou.

Vimos esse mesmo movimento em contextos bem diferentes. Uma financeira que recalibra alçada de crédito por perfil de risco a cada trimestre. Um varejo que muda o teto de desconto por categoria em toda campanha. Uma seguradora que ajusta a alçada de aceitação por ramo. Uma área de vendas que revisa a regra de comissionamento a cada ciclo de meta. Em todos, a alçada não era configuração de sistema; era decisão de negócio que tinha mudado de endereço para o lugar errado.

Sendo direto sobre o contrário: se a sua alçada é uma só, raramente muda e não tem exceção, o Approval Process nativo do Salesforce dá conta, e adicionar uma camada externa é complexidade sem retorno. A conta muda quando a regra é volátil, ramificada e precisa ser auditável por exigência. Aí o custo de manter isso dentro do CRM aparece, e ele aparece em fila de TI e em perguntas de auditoria sem resposta rápida.

A pergunta útil, no fim, não é "como altero a alçada no Salesforce". É "com que frequência essa alçada muda, e quem deveria poder mudá-la". A resposta a essa segunda pergunta costuma dizer se a regra está no lugar certo.

Aprofundamos onde cada regra de negócio deveria morar no e-book [Onde mora a regra de negócio], e mostramos como a camada de decisão opera ao lado dos seus sistemas em [IA em decisões críticas].