7 erros comuns ao implementar Salesforce sem ajuda

Configurar o Salesforce parece fácil no primeiro dia. Você cria um campo, monta um Flow, dá acesso para a equipe e tudo funciona. O custo dos atalhos aparece meses depois, quando a org já cresceu e ninguém lembra por que aquela automação existe ou quem liberou aquele acesso. Depois de entregar projetos e arrumar org que gente apressada deixou pela metade, vi os mesmos erros se repetirem. Estes são os sete que mais custam.

Os erros mais comuns de quem implementa Salesforce sem ajuda são empilhar permissões no perfil, automatizar sem log, escolher mal entre Flow e Apex, mexer direto em produção, ignorar registros duplicados, deixar a visibilidade dos registros no improviso e tratar o projeto como concluído quando ele vai ao ar. Cada um parece pequeno no começo e vira dívida cara depois.

1. Empilhar tudo no perfil em vez de usar Permission Sets

O caminho fácil é dar tudo pelo perfil e ir marcando caixinhas conforme alguém reclama que não consegue fazer algo. Seis meses depois você tem um perfil gigante que ninguém entende e não consegue reaproveitar. O modelo moderno separa o acesso base do acesso por função em blocos, e é isso que Permission Set Groups resolvem quando o perfil incha. Comece pequeno, com um conjunto de permissões por responsabilidade, e você evita a bagunça quase impossível de desfazer depois.

2. Automatizar sem nenhuma forma de enxergar o que aconteceu

Uma automação que funciona no teste e falha em silêncio na produção é pior que nenhuma automação, porque você confia num processo que não está rodando. Quem configura sozinho quase sempre esquece de registrar o que a automação fez, e aí debugar vira adivinhação. Ter um mínimo de log no Flow para parar de debugar às cegas muda o jogo: quando algo falha, você lê o que aconteceu.

3. Escolher mal entre Flow e Apex

Os dois extremos custam caro. Tem quem programe tudo em código e acabe com uma org que só uma pessoa consegue manter. E tem quem force o Flow a fazer coisa demais, até virar um monstro lento e impossível de ler. A decisão de quando usar Flow ou Apex tem critério, não é questão de gosto. Errar isso não quebra nada no dia um, mas encarece toda mudança futura.

4. Mexer direto em produção

Esse é o mais perigoso. Sem um ambiente de teste e sem histórico do que mudou, cada ajuste é uma aposta e nenhum erro é reversível com tranquilidade. Você conserta uma coisa às pressas, quebra outra sem perceber, e perde o dia seguinte entendendo o que aconteceu. Mesmo quem está saindo dos Change Sets ganha muito ao aprender os primeiros passos do sf CLI para migrar mudanças com controle. Ter um lugar para testar antes e um registro do que foi alterado é o que separa uma correção de cinco minutos de um incêndio.

5. Ignorar a qualidade dos dados

A org entra no ar limpa e vai enchendo de duplicado sem ninguém olhar. Dois cadastros do mesmo cliente, três contatos com variações de nome, e o relatório de vendas deixa de bater. O time perde a confiança no número, o pior que pode acontecer com um CRM. Vale entender cedo como funciona a deduplicação de dados com matching fuzzy e criar a regra antes que a base fique grande demais para limpar na mão.

6. Deixar a visibilidade dos registros no improviso

Quem vê o quê é a decisão de segurança que mais dá dor de cabeça, e a que mais gente configura no chute. O resultado costuma ser um de dois extremos: ou todo mundo vê tudo, e você tem um problema de privacidade, ou ninguém vê nada, e a equipe vive pedindo acesso. Saber por que um usuário vê um registro no Salesforce, entre organização, sharing e propriedade do dado, evita as duas armadilhas. Parece burocrático até o dia em que um vendedor enxerga a carteira do concorrente interno.

7. Achar que o projeto acaba quando vai ao ar

A entrega não é o fim, é o começo da parte que ninguém orça. Depois do "foi ao ar" vem manutenção, ajuste de regra e usuário que usa de um jeito imprevisto. Quem planeja só até a virada de chave se surpreende com o custo do que vem depois, e por isso vale entender antes o que realmente pesa no preço de um projeto Salesforce. Software que fica no ar tem custo contínuo, e fingir que não tem é o erro que sustenta todos os outros.

O erro que engloba os outros: sem fonte de verdade

Um exemplo concreto de como esses erros se combinam. Na Vetra Distribuidora, a empresa fictícia que uso como org de demonstração deste portfólio, o desconto da venda era calculado em dois lugares ao mesmo tempo: na Oportunidade e na soma das linhas de produto. Cada um dava um número, e os dois brigavam. Não era bug de código, era falta de decisão: ninguém tinha definido qual campo mandava. A correção não foi programar mais, foi eleger uma fonte de verdade única e fazer o resto derivar dela. Quem implementa sozinho resolve o sintoma, dois cálculos diferentes, e não a causa, a ausência de dono do dado.

Perguntas frequentes

Dá para implementar o Salesforce sem consultor?

Dá, e muita empresa começa assim. O problema não é a configuração inicial, que a plataforma facilita, é o acúmulo de decisões erradas que ninguém revisa: permissão larga demais, automação sem log, produção mexida na mão. Cada uma parece pequena no começo e vira dívida cara quando a org cresce. Faça sozinho o que é simples e chame ajuda antes de decisões de arquitetura difíceis de desfazer.

Qual o erro mais caro ao implementar Salesforce sozinho?

Mexer direto em produção sem versionamento nem ambiente de teste. Sem sandbox e sem histórico do que mudou, cada ajuste é um risco e nenhum erro é reversível com segurança. É o erro que transforma uma correção de cinco minutos em um dia perdido tentando entender o que quebrou e por quê.

Como saber se a minha org de Salesforce está mal configurada?

Alguns sinais aparecem cedo: usuários com acesso a coisas que não deveriam ver, ninguém sabe explicar por que uma automação disparou, relatórios com registros duplicados e medo de mexer em qualquer coisa porque algo sempre quebra. Se a equipe evita a ferramenta em vez de confiar nela, a configuração cresceu sem governança.

Vale a pena refazer uma implementação de Salesforce mal feita?

Nem sempre precisa refazer tudo. Na maioria dos casos dá para arrumar em camadas: primeiro a segurança de acesso, depois a observabilidade das automações e por último a qualidade dos dados. Um diagnóstico honesto separa a dívida perigosa da imperfeição que pode conviver com o negócio por enquanto.