Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
A Salesforce cancelou a retirada das permissões de perfis, segundo uma nota de suporte publicada em 6 de junho de 2026. Um artigo do Salesforce Ben de 14 de agosto transforma essa mudança em uma pergunta operacional mais útil: se a plataforma não vai mais obrigar a migração, como distribuir acesso sem voltar a multiplicar perfis e exceções por usuário? A resposta oficial continua praticamente a mesma. A Salesforce afirma que perfis não receberão novos investimentos e recomenda um modelo liderado por permission sets e permission set groups. O cancelamento remove a data de fim de vida; não transforma uma estrutura monolítica em uma solução modular.
A distinção importa porque cada usuário continua ligado a um único perfil, enquanto permission sets podem ser reutilizados e combinados. Quando uma organização clona perfis para representar cargo, região, produto e exceção, cada mudança precisa ser replicada em várias cópias. Com conjuntos granulares, uma capacidade pode participar de diferentes grupos sem duplicar sua definição. OrbTrail interpreta o ponto central assim: perfil deve ser o menor ponto de partida possível; permission set deve representar uma capacidade verificável; permission set group deve montar o pacote necessário para uma persona ou trabalho; e uma política deve decidir quando essa composição entra e sai da conta do usuário.
Esse desenho não é automaticamente simples. Dividir um perfil enorme em dezenas de conjuntos mal nomeados apenas desloca a confusão. O ganho aparece quando existe uma taxonomia estável, um proprietário para cada capacidade, critérios de concessão observáveis e um processo de revisão. A arquitetura precisa responder quatro perguntas sem investigação manual: o que este conjunto concede, qual grupo o reutiliza, por que esta pessoa o recebeu e quando o acesso deixa de ser necessário. Se uma dessas respostas depende da memória de um administrador, a organização ainda opera por exceção, mesmo que toda a metadata esteja em permission sets.
Deixe no perfil o que só ele controla
Defaults de app e record type, layouts, horas e faixas de IP permanecem na camada obrigatória.
Modele blocos reutilizáveis
Separe acesso de leitura, execução e privilégios sensíveis para que cada bloco tenha propósito e dono claros.
Componha o trabalho, não o organograma
Agrupe capacidades necessárias às tarefas; use muting somente para reduzir um conjunto dentro daquele grupo.
Conceda, expire e revogue por critério
Políticas de acesso e expiração transformam mudanças de função e acessos temporários em eventos auditáveis.
O perfil mínimo é uma fronteira, não um novo perfil universal
A orientação da Salesforce separa dois tipos de configuração. O perfil conserva itens que ainda dependem dele: defaults de app e record type, atribuição de page layout, login hours e login IP ranges. Permissões de sistema, objeto e campo, acesso a connected apps, classes Apex, páginas Visualforce, tabs e custom permissions devem migrar para permission sets quando a plataforma permitir. Para uma implementação nova, a referência oficial sugere começar pelo Minimum Access Profile. Isso não significa colocar todos os usuários no mesmo perfil sem analisar licenças, experiências e controles de login; significa impedir que o perfil volte a acumular capacidades que podem ser compostas fora dele.
Uma decomposição útil segue o trabalho. A publicação How I Solved It da Salesforce propõe uma camada Base para permissões comuns sem acesso a objetos ou campos, uma camada Read para navegar e ler um app sem incluir dados sensíveis, e uma camada Persona para o restante específico daquele trabalho. Não é uma norma universal, mas demonstra uma propriedade importante: o mesmo conjunto Read pode servir a Marketing e Vendas, enquanto cada persona recebe apenas seus privilégios particulares. Capacidades raras — publicar Knowledge, aprovar pagamentos ou administrar uma integração — podem continuar como conjuntos por tarefa, sem contaminar o grupo inteiro.
Muting reduz um grupo; não revoga acesso concedido por outro caminho
Permission set groups calculam a união dos conjuntos incluídos. Um muting permission set pode suprimir uma permissão nessa composição específica, facilitando o reúso de um conjunto mais amplo entre personas. A fronteira é crítica: o mute afeta somente aquele grupo. Se o mesmo usuário obtiver a permissão por seu perfil, por outro permission set ou por outro grupo, ela continua efetiva. Portanto, muting não deve ser tratado como uma negação global nem como substituto para descobrir todas as rotas de concessão. Antes de confiar nele para um campo sensível ou para Modify All, a equipe precisa verificar a visão combinada do usuário.
Esse comportamento também muda a decisão sobre granularidade. Criar um conjunto gigantesco e silenciar dezenas de itens em cada grupo gera uma matriz difícil de revisar; criar um conjunto por campo gera inventário impossível de governar. O ponto de equilíbrio é uma capacidade coesa, com risco semelhante e ciclo de mudança compartilhado. Um conjunto Read — Service Console pode reunir app, tabs, objetos e campos não sensíveis usados para navegação. Já exportar relatórios, visualizar dados criptografados ou executar uma ação privilegiada merece blocos separados, pois proprietário, aprovação e expiração podem ser diferentes.
A escala real começa quando mudança de função também remove acesso
User Access Policies estão geralmente disponíveis e podem conceder ou revogar permission sets, permission set groups, licenças de pacote, permission set licenses, grupos públicos e filas. Uma política automatizada pode executar quando um usuário é criado ou atualizado; uma política manual pode migrar uma população em operação controlada. A documentação do Trailhead descreve filtros sobre atributos do usuário e ações ordenadas, além do histórico de alterações recentes. Isso permite ligar acesso a critérios verificáveis — função, departamento, status ou outro atributo governado — em vez de depender de uma lista informal de pessoas.
O teste decisivo é a transferência interna. Quando alguém deixa Vendas e entra em Operações, a automação precisa remover o pacote anterior e conceder o novo, não apenas somar acesso. Concessões temporárias pedem Assignment Expiration em permission sets ou groups, para que o privilégio termine sem um chamado futuro. Em sandbox, a equipe deve simular admissão, promoção, mudança lateral, afastamento e desligamento; conferir licenças compatíveis; esperar a recalculação dos grupos; e validar o acesso efetivo, não apenas a presença da atribuição. A produção deve receber o mesmo roteiro, proprietário e evidência de rollback.
O cancelamento deve encerrar a corrida ao prazo, não o programa de redução de privilégio
A nota de cancelamento recomenda continuar a adoção de permission sets, permission set groups, User Access Policies e testes em sandbox. Salesforce Well-Architected vai além: pede conjuntos modulares, alinhamento dos grupos às capacidades do negócio, perfis usados minimamente e uma matriz de segurança que ligue pessoas e sistemas a personas. Isso converte a migração de um projeto técnico em um sistema operacional de acesso. Os indicadores úteis passam a ser cobertura por grupo governado, atribuições diretas sem justificativa, privilégios elevados com e sem expiração, usuários fora da matriz e tempo para remover acesso após mudança de função.
A conclusão da OrbTrail é deliberadamente menos dramática que o anúncio: nenhuma organização precisa migrar porque uma data de aposentadoria se aproxima, mas organizações maduras ainda precisam conseguir explicar acesso de forma reproduzível. Comece por uma persona e uma capacidade de risco, registre o acesso efetivo atual, monte o perfil mínimo e os blocos necessários, automatize concessão e revogação, teste os cinco eventos de ciclo de vida e só então repita. A arquitetura está pronta quando adicionar uma nova tarefa exige compor um bloco governado — não clonar outro perfil nem entregar uma permissão diretamente a alguém para sempre.
