Customizações Salesforce Sem Código: Guia Prático para Iniciantes

Sabe o que me fascina no Salesforce? O quanto você pode construir sem escrever uma única linha de código. Automações, validações, interfaces customizadas — tudo com clicks. Já parou pra pensar no poder que isso coloca nas suas mãos?

Essa filosofia tem até nome: "Clicks, Not Code". E não é só um slogan. A Salesforce investiu pesado em ferramentas declarativas que permitem que profissionais sem background em programação criem soluções poderosas. Na prática, um Admin habilidoso resolve 80-90% das necessidades de negócio sem tocar em código.

Neste guia, vou te mostrar as customizações mais importantes que você pode fazer sem código — e que são exatamente o que a prova de certificação Admin cobra. Se você está estudando para a cert ou quer melhorar suas habilidades de Admin, esse conteúdo é pra você. Bora fazer uma duck debugging session declarativa?

Por que a Salesforce prioriza ferramentas declarativas?

Três razões práticas:

Manutenção: Configurações declarativas são mais fáceis de manter e documentar do que código. Qualquer Admin pode entender e modificar um Flow. Já um trigger em Apex precisa de um Developer — e se aquele Developer sair da empresa, outro Developer precisa entender o código antes de modificar. Com configuração declarativa, a manutenção é mais democrática.

Atualizações: Quando a Salesforce lança uma nova versão (3x por ano — Spring, Summer e Winter releases), as ferramentas declarativas se atualizam automaticamente. Código customizado pode quebrar e precisa de manutenção a cada release. Empresas com muitas customizações em código gastam semanas testando e ajustando a cada release. Empresas com customizações declarativas gastam horas.

Velocidade: Criar um campo customizado leva 2 minutos. Escrever a mesma funcionalidade em código pode levar horas (incluindo testes unitários). Para a maioria das necessidades, declarativo é simplesmente mais rápido.

A regra de ouro é: use código apenas quando a ferramenta declarativa não resolve. E na prática, as ferramentas declarativas resolvem a grande maioria das necessidades. Antes de pedir ajuda a um Developer, pergunte a si mesmo: "isso pode ser feito com clicks?" Explica para mim como se eu fosse um pato... o que exatamente você precisa que aconteça? Muitas vezes, ao descrever o problema em voz alta, você percebe que a solução declarativa existe.

Custom Fields: os tipos que você precisa conhecer

Campos são a unidade básica de dados no Salesforce. Cada campo tem um tipo que define que tipo de informação ele armazena. Escolher o tipo certo é fundamental — mudar depois pode ser complicado.

Text: Texto livre. Até 255 caracteres para Text simples, até 131.072 para Long Text Area. Use Text para nomes, descrições curtas, identificadores. Use Long Text Area para notas e observações detalhadas. Existe também Rich Text Area que permite formatação (negrito, itálico, links).

Number: Números inteiros ou decimais. Defina casas decimais na criação. Use para quantidades, scores, ratings. Atenção: se o número é um identificador (CPF, CNPJ, CEP), use Text — não Number — porque números não preservam zeros à esquerda.

Currency: Valores monetários. Herda a moeda da org ou do registro (para orgs multi-currency). Use para preços, orçamentos, valores de contrato. Não use Number para valores monetários — Currency formata automaticamente com símbolo de moeda e separadores.

Date / Date-Time: Datas com ou sem horário. Date para datas simples (data de nascimento, data de vencimento). Date-Time para quando o horário importa (data e hora de uma reunião, prazo exato de entrega). Atenção com timezones: Date-Time armazena em UTC e converte para o timezone do usuário.

Picklist: Lista de opções predefinidas. Single select (escolhe uma) ou multi-select (escolhe várias). Excelente para padronizar dados e evitar erros de digitação. Use para Status, Categoria, Prioridade, Região. Picklists podem ser restringidas (só aceita valores da lista) ou não restringidas (aceita valores fora da lista via API).

Checkbox: Verdadeiro ou falso. Útil para flags e controles. "Ativo?", "VIP?", "Enviou contrato?". Simples e eficiente. O valor padrão é sempre "unchecked" (falso).

Formula: Campo calculado que puxa dados de outros campos. Não é editável diretamente — o valor é calculado automaticamente em tempo real. Extremamente poderoso. Exemplos: calcular idade a partir da data de nascimento, calcular margem de lucro a partir de custo e preço de venda, mostrar "Atrasado" ou "No prazo" baseado na data de vencimento.

Lookup / Master-Detail: Relacionamentos entre objetos. Lookup é uma referência simples — como uma chave estrangeira opcional. Master-Detail cria uma dependência forte (se o pai é deletado, os filhos também são, e o field é obrigatório). A escolha entre Lookup e Master-Detail impacta o comportamento de sharing, roll-up summaries e cascade delete.

Roll-Up Summary: Só disponível em Master-Detail. Soma, conta, calcula mínimo ou máximo dos registros filhos. Exemplo: num objeto Pedido (pai) com Itens de Pedido (filhos em Master-Detail), um Roll-Up Summary pode somar automaticamente o valor total de todos os itens. É automático e em tempo real.

Boas práticas de naming

O nome do campo no Salesforce gera automaticamente um API Name. Boas práticas que separam profissionais organizados de amadores — e o Quack já viu orgs com naming tão bagunçado que dava vontade de chorar:

• Use nomes descritivos: "Data de Vencimento" em vez de "DV" ou "Dt_Venc"
• O API Name usa underscores: Data_de_Vencimento__c
• Inclua o sufixo __c em campos customizados (isso é automático, não adicione manualmente)
• Mantenha consistência: se um campo é Data_Criacao__c, não crie outro como Dt_Atualizacao__c ou dataFinal__c. Escolha um padrão e siga para todos os campos
• Use Help Text em todo campo customizado — explique o que o campo significa e como deve ser preenchido. Isso reduz chamados de suporte e treina os usuários naturalmente
• Não crie campos que você não vai usar. Cada campo adicional é complexidade. Menos campos bem pensados é melhor que muitos campos "por via das dúvidas"

Custom Objects: quando e como criar

Objetos são as "tabelas" do Salesforce. Cada objeto armazena um tipo de dado. Account, Contact, Opportunity, Case, Lead são objetos padrão que vêm com a plataforma.

Quando criar um Custom Object:

• Você precisa rastrear algo que nenhum objeto padrão faz
• Exemplo: Projetos, Equipamentos, Eventos, Reclamações, Contratos, Produtos Internos
• A informação tem seu próprio ciclo de vida (é criada, modificada, eventualmente arquivada)
• Precisa de relatórios específicos sobre esse tipo de dado

Quando NÃO criar um Custom Object:

• A informação cabe como campos extras num objeto existente
• Exemplo: adicionar "Segmento" em Account é melhor que criar um objeto "Segmentos" com um registro por conta
• Você está duplicando funcionalidade que um objeto padrão já oferece

Como criar:

1. Vá em Setup → Object Manager → Create → Custom Object
2. Defina o Label (nome visível para o usuário) e o Plural Label
3. O Object Name (API name) é gerado automaticamente — revise para garantir que está limpo
4. Ative a opção "Allow Reports" (quase sempre útil) e "Allow Activities" (se faz sentido ter tarefas associadas)
5. Escolha o tipo de Name field: Text (nome livre como "Projeto Alpha") ou Auto Number (PRJ-0001, PRJ-0002...)
6. Configure o Deployment Status como "Deployed" quando estiver pronto para os usuários verem

Standard vs Custom Objects:

• Standard: vêm com o Salesforce (Account, Contact, Opportunity, Case, Lead). Já têm campos, relacionamentos e funcionalidades pré-configuradas
• Custom: você cria conforme a necessidade. Totalmente flexíveis
• Standard objects não podem ser deletados, mas podem ser extensivamente customizados (novos campos, layouts, automações)
• Custom objects terminam com __c no API name: Projeto__c

Page Layouts e Compact Layouts

Page Layouts controlam quais campos aparecem na página de um registro, em que ordem e com que organização visual. É a interface que o usuário vê quando abre um registro.

Dicas para Page Layouts eficientes:

• Coloque os campos mais importantes no topo — o usuário não deveria ter que rolar a página para ver informações essenciais
• Agrupe campos relacionados em seções com títulos claros: "Informações Básicas", "Dados Financeiros", "Datas Importantes"
• Use colunas de 2 (o padrão) para aproveitar o espaço horizontal
• Use o campo "Read-Only" no layout para campos que o usuário não deve editar (mas pode ver)
• Remova campos que não são usados — menos poluição visual = mais produtividade do usuário
• Coloque related lists relevantes no final da página (Contatos relacionados, Atividades, Histórico)

Compact Layouts: Definem quais campos aparecem no "card" resumido do registro — aquele que aparece no topo da página e em lookups (quando você passa o mouse sobre um link de registro). Coloque apenas 4-5 campos essenciais: os que o usuário precisa ver num relance rápido sem abrir o registro.

Record Types + Page Layouts: Você pode ter diferentes page layouts para diferentes tipos de registro. Exemplo: uma Oportunidade de "Venda Nova" mostra campos diferentes de uma Oportunidade de "Renovação". Isso é feito combinando Record Types com Page Layout Assignments.

List Views: organizando seus dados

List Views são listas filtradas de registros. Todo usuário pode criar as suas, e Admins podem criar views públicas para todo o time.

Como criar uma List View útil:

1. Vá para um objeto (ex: Oportunidades)
2. Clique na engrenagem → New
3. Defina filtros (ex: "Stage equals Negotiation" AND "Amount greater than 50000")
4. Escolha quais colunas exibir — menos é mais, mostre só o essencial
5. Defina a visibilidade (só para você, para um grupo específico, ou para todos)

Dicas:

• Crie views por cenário: "Minhas Oportunidades Abertas", "Fechamentos Este Mês", "Oportunidades Paradas há 30+ dias"
• Use filtros combinados (AND/OR) para refinar resultados
• Ordene por campos relevantes (data de fechamento, valor, prioridade)
• Use inline editing para atualizar campos direto da list view sem abrir cada registro
• Charts na list view (ícone de gráfico) dão visualização rápida dos dados filtrados

Validation Rules: garantindo qualidade de dados

Validation Rules impedem que dados inválidos sejam salvos. São essenciais para manter a qualidade da informação — e são um dos temas favoritos da prova de certificação.

Uma Validation Rule funciona assim: você define uma fórmula que retorna TRUE ou FALSE. Se retorna TRUE, o registro não é salvo e o usuário vê a mensagem de erro que você configurou. Parece contra-intuitivo, não? Pense assim: a fórmula descreve a condição de erro. Se a condição de erro é verdadeira, o Salesforce bloqueia.

Exemplos práticos:

Campo obrigatório condicional: Se o Stage é "Closed Won", o campo "Motivo da Vitória" precisa estar preenchido:

AND(
  ISPICKVAL(StageName, "Closed Won"),
  ISBLANK(Motivo_Vitoria__c)
)

Mensagem de erro: "O campo 'Motivo da Vitória' é obrigatório quando o Stage é 'Closed Won'."

Formato de email:

NOT(REGEX(Email_Secundario__c, "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}"))

Dica: essa validation só deve rodar se o campo não estiver em branco. Use AND com NOT(ISBLANK()) para evitar bloquear registros com o campo vazio.

Valor mínimo: Desconto não pode ser maior que 30%:

Desconto__c > 0.30

Data no passado: Data de Entrega não pode ser anterior a hoje:

Data_Entrega__c < TODAY()

Fórmulas úteis em Validation Rules:

• ISBLANK() — Verifica se campo está vazio
• ISPICKVAL() — Verifica valor de picklist (necessário porque picklists não podem ser comparadas com =)
• REGEX() — Valida padrões (email, telefone, CEP)
• AND(), OR(), NOT() — Combinação lógica
• TODAY() — Data atual (útil para "data não pode ser no passado")
• $User.ProfileId — Perfil do usuário atual (útil para exceções: "essa regra não se aplica a Admins")
• PRIORVALUE() — Valor anterior do campo (útil para impedir mudanças: "Status não pode voltar de Fechado para Aberto")

Boas práticas para Validation Rules:

• Sempre escreva mensagens de erro claras e orientativas — diga ao usuário o que ele precisa fazer, não só o que está errado
• Teste todas as combinações possíveis antes de ativar em produção
• Documente a lógica em anotações ou help text
• Cuidado com Validation Rules que conflitam com Flows ou data loads — elas se aplicam a TODAS as formas de criação/edição de registros

Flow Builder: automação sem código

O Flow Builder é a ferramenta mais poderosa do arsenal declarativo. Com ele, você automatiza praticamente qualquer processo. Se o Quack pudesse escolher UMA habilidade para um Admin dominar, seria Flows. Sem sombra de dúvida.

Tipos de Flow mais usados:

Record-Triggered Flow: Dispara quando um registro é criado, atualizado ou deletado. É o substituto dos antigos Process Builders e Workflow Rules.

Exemplo: quando um Case é criado com prioridade "Alta", enviar notificação para o gerente e criar uma tarefa de follow-up para o analista.

Subtipos importantes:

• Before Save: Executa antes do registro ser salvo. Mais rápido e eficiente. Ideal para fast field updates (atualizar campos no mesmo registro sem usar DML).
• After Save: Executa depois do registro ser salvo. Necessário quando você precisa do ID do registro ou quando precisa criar/atualizar OUTROS registros.

Screen Flow: Cria formulários interativos para os usuários. É como construir um wizard ou um formulário multi-step.

Exemplo: um wizard de onboarding que coleta informações do novo funcionário em etapas: dados pessoais → endereço → documentos → equipe. No final, cria os registros necessários automaticamente.

Screen Flows podem ser adicionados a Lightning Pages, Quick Actions, Experience Cloud pages ou executados como standalone.

Scheduled Flow: Executa em horários programados. É como um cron job visual.

Exemplo: todo dia às 8h, verificar oportunidades sem atividade há 30 dias e criar uma tarefa de follow-up para o owner. Ou: toda segunda-feira, enviar email com resumo das métricas da semana anterior.

Autolaunched Flow: Executado por outro processo (outro Flow, Apex, Process Builder, API). Não tem telas — é pura lógica backend.

Quando usar Flow vs processo manual:

• Se a ação acontece sempre da mesma forma → Automatize com Flow
• Se a ação requer julgamento humano → Mantenha manual (ou use Approval Process)
• Se a ação envolve mais de 3 passos repetitivos → Flow economiza tempo
• Se o erro humano é frequente e custoso → Flow elimina o risco

As ferramentas do Setup que você precisa dominar

Object Manager: Central de configuração de objetos, campos, layouts, triggers e validations. É onde você passa a maior parte do tempo como Admin. Aprenda a navegar aqui de olhos fechados.

Schema Builder: Ferramenta visual que mostra objetos e relacionamentos como um diagrama de entidade-relacionamento. Excelente para entender a estrutura de dados da org e para apresentar para stakeholders não-técnicos. Também permite criar objetos e campos diretamente no diagrama.

Lightning App Builder: Construtor drag-and-drop de páginas. Permite criar home pages, record pages e app pages customizadas sem código. É como um "Wix para Salesforce" — você arrasta componentes, configura propriedades e publica. Componentes disponíveis incluem: listas, gráficos, rich text, flows embutidos, relatórios, componentes customizados.

Setup Menu: O coração da administração. Aprenda a navegar pelo Setup usando a barra de busca (Quick Find). É muito mais rápido do que clicar nos menus. Quer achar configurações de email? Digite "Email" na Quick Find. Quer ver os Profiles? Digite "Profiles". Domine o Quick Find e você será 3x mais rápido no Setup.

Exercício prático: construa um rastreador de projetos

Para colocar tudo em prática, aqui vai um exercício que combina todas as customizações que vimos. Faça isso na sua org de Developer Edition — é hora de quack it out e colocar a mão na massa:

1. Crie um Custom Object chamado "Projeto" com campos: Nome (Text), Status (Picklist: Planejamento, Em Andamento, Pausado, Concluído, Cancelado), Data Início (Date), Data Fim (Date), Responsável (Lookup para User), Orçamento (Currency), Prioridade (Picklist: Alta, Média, Baixa)

2. Adicione campos de fórmula: Duração (Date Fim - Date Início em dias), Status Cor (retorna "🟢" para Em Andamento, "🟡" para Pausado, "🔴" para Atrasado)

3. Adicione uma Validation Rule: Data Fim não pode ser anterior a Data Início. Mensagem: "A Data Fim deve ser igual ou posterior à Data Início."

4. Configure o Page Layout: Organize os campos em seções: "Informações do Projeto", "Datas", "Status e Prioridade". Adicione related lists relevantes.

5. Crie List Views: "Meus Projetos Ativos" (Status = Em Andamento, Responsável = eu), "Projetos Atrasados" (Data Fim < hoje AND Status ≠ Concluído), "Todos os Projetos"

6. Crie um Record-Triggered Flow: Quando o Status muda para "Concluído", atualiza a Data Fim com a data atual automaticamente (before save)

7. Monte relatórios e dashboard: Projetos por Status (gráfico de pizza), Timeline de projetos (gráfico de barras por mês), Orçamento total por status (summary report)

Se você completar esse exercício, já tem material para portfólio, um entendimento prático das ferramentas mais importantes da plataforma, e uma base sólida para a prova de certificação.

O poder do Salesforce está em transformar processos complexos em soluções simples — e você não precisa de uma linha de código para isso. Quack check final: se você entendeu os conceitos deste post e praticou o exercício, você já está muito mais preparado do que imagina. Agora vai lá e constrói.

---

Perguntas Frequentes (FAQ)

Se Flows fazem tudo, por que existe Apex?

Flows resolvem a maioria dos cenários, mas têm limitações. Integrações complexas com APIs externas (callouts HTTP com lógica sofisticada), processamento em massa com regras de negócio intrincadas, customizações avançadas de interface (Lightning Web Components) e operações que precisam de performance extrema ainda exigem código. A regra é: comece declarativo e só vá para código quando o declarativo comprovadamente não resolver. Na prática, um bom Admin resolve 80-90% dos cenários sem código.

Posso quebrar minha org com customizações?

Na Developer Edition, pode experimentar à vontade — é seu laboratório pessoal. O Quack já quebrou muita coisa em Developer Edition e sobreviveu para contar a história. Em orgs de produção, sempre teste em sandbox primeiro. Validation Rules podem bloquear operações legítimas se não forem bem pensadas (ex: uma validation que impede data loaders de funcionar), e Flows mal configurados podem criar loops infinitos ou atualizar dados incorretamente. Mas nada que uma boa prática de teste não resolva. Regra: nunca coloque nada em produção sem testar extensivamente em sandbox.

Quantos campos customizados posso criar?

O Salesforce tem limites (governor limits). Em orgs Enterprise Edition, o limite é de 500 campos customizados por objeto. Na prática, se você está chegando perto de 200+ campos num único objeto, provavelmente precisa repensar sua arquitetura de dados — talvez dividir em objetos relacionados. Menos campos bem planejados é sempre melhor que muitos campos desnecessários. Cada campo adicional é complexidade de manutenção, confusão para usuários e potencial poluição de dados.

Flow Builder substituiu Process Builder e Workflow Rules?

Sim. A Salesforce oficialmente recomenda usar Flow Builder para todas as automações novas. Process Builder e Workflow Rules ainda funcionam em orgs existentes, mas não recebem mais atualizações ou novas funcionalidades. A Salesforce inclusive oferece uma ferramenta de migração ("Migrate to Flow") para converter automações antigas. Se você está aprendendo agora, foque 100% em Flows — não perca tempo com ferramentas obsoletas.