Adoção no Salesforce: como fazer um recurso virar hábito da equipe

Você entregou um componente ótimo: bem testado, bulkificado, resolve um problema real. Duas semanas depois, ninguém usa. O reflexo é achar que faltou treinamento, mas quase sempre o problema não está no código, e sim em onde ele mora. Um bom recurso numa aba perdida vira shelf-ware: prateleira empoeirada que ninguém abre.

O problema não é o componente, é o contexto

Adoção não se ganha pedindo para a equipe "lembrar de usar a ferramenta nova". Ganha-se colocando a informação no exato ponto em que a decisão acontece. Se o vendedor decide recompra olhando a Conta, é ali, no topo da record page da Conta, que o radar de recompra precisa aparecer, não numa aba separada que exige um clique extra e um ato de memória. A regra é simples: a distância entre o dado e a decisão tem que ser zero.

Componha na record page onde a decisão acontece

No Lightning App Builder, a record page (uma FlexiPage) é o seu principal ponto de alavancagem. Em vez de mais uma tela, você posiciona o componente na coluna e na altura em que o olho já está. Alguns princípios que uso na composição:

• Acima da dobra o que dispara ação; abaixo, o histórico e o detalhe. Ninguém rola para encontrar o que deveria estar decidindo.
• Visibilidade dinâmica de componente para esconder o que não se aplica àquele registro, em vez de poluir a página com blocos vazios.
• Uma record page por objetivo: perfis diferentes podem receber atribuições diferentes de página, então cada papel vê a versão que faz sentido para ele.

Foi exatamente essa a virada num projeto recente de organização de uma distribuidora: o mesmo componente LWC que antes vivia isolado passou a compor o topo da Conta, e o uso deixou de depender de disciplina do usuário. Se o seu componente ainda é uma engine que roda no escuro, vale ver como um dashboard de KPIs configurável ganha vida quando fica na frente de quem decide.

Unifique tudo num Lightning App

Recursos espalhados entre apps diferentes forçam o usuário a caçar. Um Lightning App dedicado resolve isso: você define a navegação (as abas e objetos que aquele papel realmente usa), fixa itens de utilidade na utility bar e pode usar actionOverrides para controlar a página inicial do app, a primeira coisa que a equipe vê ao entrar. O ganho não é estético: é reduzir o número de cliques e escolhas até a tarefa. Menos superfície, mais foco.

Visibilidade por permission set, com menor privilégio

Aqui mora o erro mais comum: liberar o app e os componentes empilhando permissões no perfil, de qualquer jeito, só para "funcionar". O resultado é gente vendo o que não deveria e um modelo impossível de auditar. A prática correta é separar duas coisas que costumam ser confundidas:

• Acesso de navegação: quem enxerga o app e as abas. Isso vai num permission set de visibilidade, atribuído ao papel que precisa.
• Acesso a dado: quem pode ler e editar cada objeto e campo. Isso é CRUD/FLS e sharing, e segue a lógica de menor privilégio: a pessoa recebe só o que o trabalho exige.

Manter esses dois planos separados deixa a adoção sustentável: você libera o recurso para um time inteiro atribuindo um permission set, sem reabrir a caixa de Pandora das permissões de perfil. Se a pergunta "por que fulano está vendo isso?" já te tirou o sono, o raciocínio de por que um usuário vê um registro no Salesforce é leitura obrigatória antes de sair distribuindo acessos.

Um checklist rápido de adoção

• O componente está na record page do objeto onde a decisão nasce, e acima da dobra?
• Existe um Lightning App que reúne só o que aquele papel usa, com uma home útil?
• A liberação é por permission set, separando navegação de dado?
• Alguém consegue explicar em uma frase por que aquele bloco está ali?

Se as quatro respostas forem sim, você não entregou uma tela: entregou um hábito. E hábito é o que transforma um projeto de Salesforce em resultado que a diretoria enxerga. Layout resolve parte da adoção, a outra parte vem de capacitar o time, e vale entender quanto custa treinar a equipe no Salesforce e por que não treinar sai mais caro antes de cortar essa linha do orçamento.