A Pergunta Fundamental: O Que Determina o Acesso de um Usuário?
Quando alguém pergunta "como um usuário obteve acesso a este campo", a resposta correta é quase sempre uma combinação: o Profile estabelece o acesso básico, os Permission Set Groups atribuídos adicionam capacidades por função, e, ocasionalmente, um Permission Set individual trata de uma exceção específica. O problema na prática é que a maioria das organizações constrói essa combinação de forma inversa – começam com um Profile abrangente que contém quase tudo e, em seguida, "corrigem" problemas pontuais com permissões individuais que ninguém se lembra de remover.
Um modelo de permissões saudável é construído na direção oposta: um Profile o mais restrito possível, que define principalmente licenciamento, acesso padrão a aplicativos e características de login; e toda a capacidade de trabalho real – quais objetos, quais campos, quais ações – é transferida para Permission Sets e Permission Set Groups. É importante esclarecer: este artigo aborda apenas os níveis de Object, Field e System Permissions. Questões de visibilidade de registros entre usuários – OWD, Role Hierarchy, Sharing Rules – são discutidas no Guia de Visibilidade e Compartilhamento, pois representam uma camada de decisão separada com suas próprias compensações (trade-offs).
As Três Unidades e Suas Funções
| Unidade | O Que Ela Determina | Quantas um Usuário Pode Ter | Quando Utilizá-la |
|---|---|---|---|
| Profile | Licenciamento, visibilidade padrão de aplicativo, Page Layout, Login Hours/IP | Exatamente um | Diferenças de infraestrutura entre tipos de usuário |
| Permission Set | Permissões de Objeto, Campo, Apex Class, Guia (Tab) - apenas adiciona | Quantas forem necessárias | Uma capacidade única e relevante para algumas funções |
| Permission Set Group | Empacotamento de vários Permission Sets sob um único nome, com a opção Muting | Quantos forem necessários | Uma combinação fixa de permissões que representa uma função de trabalho completa |
A diferença entre um Permission Set e um Permission Set Group não é apenas técnica – é organizacional. Um Permission Set individual é adequado para uma única capacidade focada ("acesso a relatórios financeiros"). Um Permission Set Group é adequado quando se deseja atribuir um "pacote de trabalho" completo a um departamento ou função, e mantê-lo em um único local quando ele muda.
Estrutura de Decisão: Onde uma Nova Permissão Deve Pertencer
Quando surge uma solicitação para adicionar acesso, a primeira pergunta não é "a qual Profile adicionar", mas sim a qual unidade a permissão pertence estruturalmente:
- Esta permissão caracteriza todos os usuários com o mesmo tipo de licença? Se sim, este é um lugar para o Profile, desde que se refira a todos os titulares da licença e não a um subconjunto.
- Esta é uma capacidade de trabalho que um grupo de funções específico sempre precisa junto com permissões adicionais? Se sim, este é um lugar para o Permission Set Group, mesmo que precise primeiro ser dividido em vários Permission Sets separados para permitir uma combinação flexível.
- Esta é uma permissão pontual e temporária para um único usuário ou uma exceção? Se sim, um Permission Set autônomo, atribuído manualmente e verificado na auditoria periódica.
- A permissão deve negar algo a um usuário específico dentro de um grupo amplo? Aqui entra o Muting Permission Set dentro de um Permission Set Group – a única ferramenta no Salesforce que permite reduzir uma permissão sem tocar no Profile ou desmontar o grupo.
A regra que previne a maior parte da "deriva" (drift): nunca edite um Profile para resolver um problema de um único usuário. Se a correção for definida como uma exceção, ela passa por um Permission Set que é documentado e tem uma data de revisão.
Lista de Verificação (Checklist) para Construir um Modelo de Permissões do Zero
- ☐ As funções de trabalho reais (e não os departamentos organizacionais) foram mapeadas e cada função recebeu um nome claro.
- ☐ Para cada função, foi definida uma lista de capacidades necessárias nos níveis de objeto, campo e Apex Class.
- ☐ Foram construídos Permission Sets focados em uma única capacidade, não um "monte de permissões" genéricas.
- ☐ Cada função recebeu um Permission Set Group que agrupa as capacidades relevantes.
- ☐ Os Profiles foram reduzidos para abranger apenas diferenças de licenciamento e infraestrutura.
- ☐ Foi definido um processo para casos excepcionais: quem aprova um Permission Set pontual e por quanto tempo.
- ☐ Foi estabelecida uma frequência de auditoria (pelo menos trimestral) que compara permissões ativas com a função atual.
- ☐ Foi definido um único Responsável (Owner) pela manutenção do modelo de permissões frente às mudanças na estrutura organizacional.
Cenário Organizacional: Uma Seguradora com Três Unidades de Vendas
Suponhamos uma seguradora de médio porte com cerca de trezentos usuários Salesforce, divididos em três unidades: vendas diretas, vendas através de agentes e sinistros. Antes do projeto, a empresa tinha doze Profiles diferentes, alguns deles cópias quase idênticas criadas para "corrigir" uma única permissão para um pequeno grupo. Um resultado típico: quando um novo agente era contratado, ninguém sabia ao certo qual Profile dos doze era o mais adequado para ele, e a resposta na prática era "copie de alguém semelhante".
A equipe de arquitetura reconstruiu o modelo: apenas três Profiles, de acordo com o tipo de licença (Sales Cloud completo, Community para agentes externos, Service Cloud para sinistros). Acima disso, sete Permission Set Groups por função de trabalho real – representante de vendas, gerente de equipe de vendas, agente externo, gerente de agentes, avaliador de sinistros, gerente de sinistros e uma função de mediação que lida tanto com vendas quanto com sinistros. Cada Permission Set Group foi composto por Permission Sets focados, como "acesso a apólices ativas" ou "aprovação de reembolso até um limite definido", de modo que pudessem ser recombinados quando uma nova função fosse criada sem precisar construir a permissão do zero.
O resultado mensurável: o tempo de configuração de um novo usuário diminuiu de vários dias (que incluíam verificação manual de qual Profile era adequado) para algumas horas, e o número de solicitações de suporte do tipo "não tenho acesso ao campo X" caiu pela metade no trimestre seguinte à transição, porque a maioria dessas solicitações resultava de um Profile que não incluía a capacidade e não estava claro a quem recorrer para correção.
Riscos Comuns e Ações Preventivas
| Risco | Como se Manifesta na Prática | Ação de Prevenção |
|---|---|---|
| Profile se torna uma ferramenta de correção pontual | Multiplicidade de Profiles quase idênticos, cada um para um pequeno grupo | Transferir cada permissão pontual para um Permission Set e reduzir Profiles apenas para licenciamento |
| Field-Level Security inconsistente | O mesmo campo exposto em um lugar e restrito em um lugar comparável | Documentar uma matriz centralizada de FLS para cada campo sensível e verificá-la em cada Release |
| Permissões "pegajosas" após mudança de função | Usuário que mudou de função mantém permissões da função anterior | Processo de desvinculação da função (offboarding) que remove o Permission Set Group antigo antes de adicionar um novo |
| System Permissions muito amplas (View All Data, Modify All) | Concedidas "para economizar tempo" e não removidas posteriormente | Aprovação dedicada e data de expiração para cada permissão de sistema ampla |
| Ausência de responsável pelo modelo de permissões | Cada equipe adiciona permissões sem uma visão geral | Um único Responsável (Owner) que aprova cada novo Permission Set ou Group antes da implantação |
Métricas para Avaliar a Saúde do Modelo
| Área | O Que Medir | Frequência de Verificação |
|---|---|---|
| Redundância Desnecessária | Número de Profiles ativos em relação ao número de tipos de licença reais | Trimestral |
| Precisão da Permissão | Percentual de usuários cujas permissões correspondem à função registrada no RH | Trimestral |
| Exceções Abertas | Número de Permission Sets pontuais sem data de revisão | Mensal |
| Permissões Amplas | Número de usuários com View All Data / Modify All Data sem justificativa documentada | Mensal |
| Tempo de Configuração | Tempo médio desde a solicitação de novo acesso até a atribuição completa | Contínuo |
Na primeira versão do monitoramento, é aconselhável limitar-se a três das cinco métricas e expandir somente após ter uma linha de base confiável. Uma métrica sem um responsável e uma data de verificação tende a desaparecer do relatório após o primeiro mês.
Como Isso se Integra à Arquitetura Mais Ampla
Um bom modelo de permissões é uma condição prévia, não um substituto, para o planejamento da visibilidade de registros (OWD, Role Hierarchy, Sharing Rules) – os dois tópicos se complementam, mas são resolvidos separadamente. Uma organização que tenta resolver um problema de visibilidade expandindo o Profile, ou vice-versa, geralmente descobre que a solução é frágil assim que a estrutura organizacional muda. Quando a organização transita entre múltiplos Orgs e um único Org, o modelo de permissões é uma das coisas que precisam ser remapeadas – uma expansão sobre o assunto aparece no Guia Single Org vs. Multi Org do Salesforce. E quando a permissão em si depende de uma lógica condicional complexa, é aconselhável avaliar se a implementação pertence a um Flow ou a um Apex, conforme detalhado no Guia Flow vs. Apex do Salesforce.
Em organizações que executam processos orientados a eventos entre sistemas, é essencial garantir que as permissões dos usuários de serviço (Integration Users) sejam construídas de acordo com o mesmo princípio – um Permission Set focado e não um Profile amplo com "System Administrator" como padrão conveniente. Este tópico se conecta ao planejamento mais amplo da comunicação entre sistemas, descrito no Guia de Arquitetura Orientada a Eventos para Salesforce.
Conclusão
Um modelo de permissões que resiste ao teste do tempo é construído de baixo para cima: capacidades focadas em Permission Sets, agrupamento delas por função de trabalho real em Permission Set Groups, e um Profile que mantém um papel mínimo de licenciamento e infraestrutura apenas. A indicação clara de falha é a proliferação de Profiles criados para resolver problemas pontuais – cada Profile adicional desse tipo é uma dívida que se acumula até que ninguém se lembre por que ele existe. Quando a capacidade interna para construir ou limpar um modelo existente é insuficiente, serviços de arquitetura de CRM oferecem um caminho prático para um início focado.