Permission Set Groups: o fim do perfil inchado no Salesforce

Toda org que cresce chega no mesmo ponto: são vinte, trinta perfis, quase todos clones de um perfil base com uma caixinha a mais ou a menos. Ninguém lembra por que "Vendas SP Pleno v3" existe, e mexer em qualquer um deles dá medo porque você não sabe quem depende do quê. O perfil, sozinho, não escala. É por isso que a própria Salesforce passou a tratar o permission set group como o caminho principal.

Um permission set group no Salesforce é um pacote que reúne vários permission sets e os atribui de uma vez a um conjunto de usuários. Em vez de clonar um perfil inteiro para cada variação de cargo, você combina blocos de acesso por função, e o acesso efetivo vira a soma dos grupos.

Por que o perfil virou antipadrão

O perfil tem uma limitação estrutural: cada usuário recebe exatamente um. Como ele carrega dezenas de configurações misturadas, permissão de objeto, de campo, de app, de aba, de sistema, qualquer diferença entre dois cargos obriga a nascer um perfil novo. O resultado é a proliferação silenciosa. Cada perfil clonado começa idêntico ao pai e, com o tempo, ganha vida própria. Seis meses depois você tem um emaranhado onde uma correção de acesso precisa ser repetida em quinze lugares, e onde ninguém consegue responder de cabeça o que um perfil concede. Empilhar tudo no perfil é, aliás, um dos erros comuns de quem implementa Salesforce sem ajuda. Isso vai direto contra o princípio de menor privilégio, porque o caminho mais fácil vira copiar um perfil que já tem acesso demais.

O que muda com o permission set group

O grupo inverte a lógica. Em vez de um objeto grande por usuário, você tem peças pequenas e reutilizáveis. Um permission set representa uma capacidade isolada, por exemplo "editar Oportunidade" ou "aprovar desconto". O grupo junta as capacidades que formam um cargo. E, diferente do perfil, um mesmo usuário pode receber vários grupos. Trocar alguém de função deixa de ser reconfigurar um perfil e vira adicionar ou remover um grupo. A permissão passa a ter nome, dono e propósito, o que também facilita muito responder de onde vem cada acesso de um usuário quando cai um ticket de auditoria.

Como montar grupos por função

A montagem que funciona parte da função de negócio, não da tela do Setup. O jeito prático é separar dois tipos de bloco. Primeiro, os permission sets de base, que quase todo mundo da área usa, como o acesso de leitura e edição nos objetos centrais de Vendas. Depois, os permission sets de capacidade, que representam um poder específico e sensível, como aprovar desconto acima de um limite ou modificar territórios. Um cargo vira a combinação de um bloco de base com os blocos de capacidade que ele realmente precisa.

Quando um grupo herda quase tudo de um conjunto, mas você precisa tirar uma permissão pontual só naquele contexto, entra o muting permission set. Ele remove a permissão dentro do grupo sem tocar no permission set original, então você não precisa clonar um conjunto inteiro só para retirar uma caixa marcada. É o ajuste fino que mantém os blocos limpos e reaproveitáveis.

Migração gradual, sem quebrar acesso

A pior forma de fazer essa transição é de uma vez, num sábado, torcendo para ninguém perder acesso na segunda. O caminho seguro é gradual e roda em paralelo. Você escolhe uma área, mapeia o que o perfil atual concede, recria essas permissões como permission sets nomeados por função e monta o grupo. Atribui o grupo a um usuário piloto que já tem o perfil antigo, valida que o acesso efetivo bate, e só então vai tirando as permissões do perfil e passando o resto da equipe para o grupo. O perfil nunca some de vez: ele continua responsável por algumas coisas que ainda vivem só nele, como layout padrão, horário de login e OAuth. A meta é o perfil enxuto, com o acesso morando nos grupos.

O que vi migrando na org de demonstração

Na Vetra Distribuidora, a empresa fictícia que uso como org de demonstração deste portfólio, o time de Vendas tinha começado a clonar perfil para cada combinação de região e alçada de desconto. Já eram quatro perfis quase iguais, com a mesma correção de FLS feita à mão em cada um. Quebrei isso em três grupos: Vendas Base, Aprovador de Desconto e Gestor de Território. O ganho concreto apareceu logo depois, quando um campo novo precisou de FLS: em vez de repetir a marcação em quatro perfis, editei um permission set e todos os grupos que o continham herdaram a mudança. Um lugar para tocar, não quatro. Para conferir se o acesso efetivo continuava igual ao do perfil antigo antes de desligar, usei o PermLens para comparar os dois usuários lado a lado e ver a origem de cada permissão. Sem esse retrato, a migração seria no escuro.

Perguntas frequentes

Qual a diferença entre perfil e permission set group?

O perfil é um por usuário e mistura muitas responsabilidades, então cada variação de cargo vira um clone. O permission set group reúne vários permission sets num pacote atribuível de uma vez, e um usuário pode receber vários grupos, o que permite combinar acesso por função sem duplicar configuração.

Um usuário pode ter mais de um grupo?

Sim, e é isso que faz o modelo escalar. Você monta um grupo por função e atribui os que o cargo precisa. O acesso efetivo é a soma, e mudar a função de alguém vira adicionar ou remover um grupo.

O perfil vai deixar de existir?

Não some, mas deixa de ser onde você concede permissão. Ele segue obrigatório para configurações que ainda vivem só nele, como layout padrão, horário de login e OAuth. A recomendação é manter o perfil enxuto.

Para que serve o muting permission set?

Ele remove uma permissão específica só dentro do grupo, sem alterar os permission sets originais. Serve para tirar uma permissão sensível de um contexto sem precisar clonar um conjunto inteiro.