Salesforce cancela a aposentadoria das permissões em Profiles: e agora, o que fazer com aquela migração pela metade?
O Knowledge Article 003834041 confirma o que muita gente já suspeitava: o fim das permissões em Profiles saiu do roadmap. Sem nova data, sem promessa de retorno.
Salesforce cancelou, de fato, o plano de aposentar permissões em Profiles que vinha sendo anunciado desde 2023. O artigo oficial de Knowledge é curto, mas o impacto de arquitetura de segurança para quem já começou a migração é grande.
Todo arquiteto de Salesforce que trabalhou em projeto de segurança nos últimos três anos ouviu a mesma frase em algum kickoff: "Profiles vão acabar, melhor já migrar tudo para Permission Set". Pois é. Essa frase, a partir de agora, precisa de um asterisco enorme. O Knowledge Article 003834041, publicado sob o título "Permissions in Profiles Retirement Cancelled", confirma que o plano de aposentadoria das permissões dentro de Profiles foi cancelado, não apenas adiado.
É diferente de tudo que a Salesforce já fez antes nesse tema. Historicamente a empresa empurra prazo, mas raramente cancela por completo um anúncio de fim de vida que já tinha data marcada. Vale reconstruir a linha do tempo, porque ela conta a história por trás da decisão.
Em janeiro de 2023 a Salesforce anunciou o fim de vida das permissões em Profiles, com prazo inicial em Spring '26. Praticamente um ano depois, a própria empresa já tinha amolecido esse compromisso: Cheryl Feldman, Director of Product Management, declarou publicamente que a Salesforce "no longer going to enforce the Spring '26 end of life date". E agora, segundo o texto atualizado do Knowledge Article, o recuo virou cancelamento definitivo, sem nova data no horizonte.
Por que a Salesforce recuou
O motivo declarado combina dois fatores que qualquer consultor que já tentou tocar essa migração reconhece na prática.
Primeiro, feedback de cliente. Muita organização grande, com dezenas de Profiles carregando lógica de anos, simplesmente não tinha capacidade operacional de reescrever todo o modelo de segurança dentro do prazo dado.
Segundo, e esse é o ponto mais técnico, ainda existem gaps de funcionalidade reais. Tem configuração que hoje só vive dentro de Profile e não tem equivalente direto em Permission Set, forçando gambiarra ou espera por novo recurso.
Isso não é surpresa para quem já tentou migrar de verdade. Atribuição de Lightning Record Page por combinação de app, tipo de registro e perfil do usuário é um exemplo clássico: essa amarração não fica no Profile, fica no metadata do CustomApplication, e some quando você cria aquele Profile "vazio" recomendado pela própria Salesforce como parte da estratégia de migração.
Resultado prático: usuário reclama que "a tela ficou estranha" depois da migração, e o time de suporte gasta duas semanas rastreando o motivo.
O que muda na prática de arquitetura
Aqui está o ponto que eu quero deixar bem claro, porque tem gente que vai ler essa notícia e vai relaxar: cancelamento de prazo não é cancelamento de boa prática.
O princípio de least privilege continua sendo a base correta de qualquer modelo de segurança em Salesforce, e Permission Set e Permission Set Group continuam sendo a ferramenta certa para implementar isso com granularidade, sem duplicar Profile para cada variação de acesso.
O que muda é a urgência artificial. Se você tem um projeto rodando hoje só porque "a Salesforce vai acabar com Profile em Spring '26", esse argumento caiu. Isso não significa parar a migração, significa recalibrar o discurso com o cliente: a motivação real nunca foi o prazo, foi segurança, manutenibilidade e escalabilidade do modelo de acesso.
Prazo artificial de vendor nunca deveria ter sido a única justificativa de negócio de um projeto de segurança, e agora fica evidente por que.
O risco de comunicação que ninguém está falando
Tem um efeito colateral que acho mais interessante do que a notícia em si: essa reversão corrói a credibilidade de qualquer futuro anúncio de fim de vida da Salesforce.
Historicamente a empresa atrasa prazo, como aconteceu recentemente com Salesforce for Outlook, adiado de 2024 para 2027, mas nunca tinha cancelado por completo um end of life já comunicado oficialmente ecossistema afora.
Da próxima vez que vier um comunicado de "isso vai ser descontinuado em tal release", vai ser difícil convencer cliente de que dessa vez é para valer.
Esse cancelamento pega em cheio três públicos diferentes dentro de um projeto Salesforce. Para arquitetos e squads de segurança que já tinham migração de Profile para Permission Set no backlog de 2026 com prazo justificado pelo end-of-life, o argumento de negócio muda. A migração continua correta tecnicamente, mas o "senão vai quebrar" deixou de ser verdade, e isso afeta priorização de sprint e conversa de budget com o cliente. Para quem já fez a migração parcial e ficou no meio do caminho, com Profiles "esqueléticos" e um monte de Permission Set Group tentando cobrir o gap, a notícia tira a pressão para terminar, mas não resolve os pitfalls que já apareceram no meio do processo, como atribuição de Lightning Page perdida ou integração vinculada a Profile específico. Para lideranças e PMs que usavam o prazo da Salesforce como argumento de negócio para justificar o projeto de hardening de segurança, esse argumento perdeu força e precisa ser substituído por um racional próprio, baseado em risco real e não em deadline de vendor.
Não consegui abrir o conteúdo completo do Knowledge Article 003834041 diretamente, porque a página carrega via JavaScript e o motor de busca só capturou o título e trechos de cookie banner. A confirmação do conteúdo e do título oficial ("Permissions in Profiles Retirement Cancelled") veio de múltiplas buscas que retornaram o próprio título do artigo, cruzada com a cobertura da Salesforce Ben, que cita diretamente a mudança no artigo de Knowledge e a fala da Cheryl Feldman, Director of Product Management. Recomendo validação humana abrindo o link direto no navegador antes de publicar, para confirmar redação exata do artigo oficial.
- Não pare a migração de Profile para Permission Set só porque o prazo sumiu. Reavalie a prioridade dela dentro do roadmap de segurança com base em risco real da sua org, não em deadline externo. - Se você já criou Profiles "vazios" como parte da estratégia recomendada pela Salesforce, audite especialmente Lightning Record Page assignments, integrações como Salesforce for Outlook e qualquer configuração de Dynamic Forms vinculada a Profile, porque são os pontos que mais geram chamado de suporte depois da migração. - Revise o discurso que você usa com o cliente. Troque "a Salesforce vai desativar isso" por "esse modelo reduz risco e facilita manutenção", porque o argumento de prazo caiu e o argumento técnico é o que sempre deveria ter sustentado o projeto. - Se sua organização parou a migração no meio, documente exatamente em que ponto ela está antes de decidir se retoma, pausa ou reverte parcialmente. Migração pela metade é o pior estado possível em modelo de segurança, porque mistura duas lógicas de acesso ao mesmo tempo. - Para quem lidera arquitetura, use esse episódio como case interno: prazo de vendor não deveria ser a única justificativa de um projeto de segurança. Justificativa boa é a que sobrevive a uma reversão de anúncio.
O maior risco aqui é a leitura rasa de "ufa, não precisa mais migrar". A Salesforce foi explícita ao dizer que o princípio de least privilege continua sendo best practice e que Permission Set continua sendo o bloco de construção recomendado, então times que usarem esse cancelamento como desculpa para não avançar em segurança estão trocando prazo por dívida técnica de outra natureza. Outro ponto de atenção é para quem está no meio da migração: Profile ainda não vai receber novos investimentos ou funcionalidades segundo o próprio comunicado, então mesmo sem prazo de fim de vida, ele continua sendo a plataforma legada dentro do modelo de segurança. Não é hora de voltar a criar lógica nova em Profile. Por fim, cuidado com a credibilidade de futuros anúncios de end-of-life da Salesforce em qualquer produto. Esse precedente de cancelamento total, e não apenas adiamento, é motivo real para tratar prazos futuros de descontinuação com ceticismo saudável até virarem enforcement de fato, e não só planejar migração baseada unicamente em comunicado oficial.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.