Winter '27 chegando: o countdown que separa quem se planeja de quem apaga incêndio
Datas de sandbox, pre-release org e release updates da Winter '27: o que realmente muda na rotina de quem administra e arquiteta orgs Salesforce
O calendário da Winter '27 já está fechado: pre-release org disponível a partir de 13 de agosto, sandbox preview no fim de agosto e produção rodando em ondas até outubro. Menos sobre o que a release traz e mais sobre como você vai chegar até lá sem sobressalto.
O calendário, sem enrolação
Todo ciclo de release tem o mesmo problema: a organização técnica sabe que a data existe, mas só lembra dela quando o Chatter já está cheio de gente perguntando por que um Flow parou de funcionar numa sexta-feira de manhã. Winter '27 não foge à regra, e o calendário que a Salesforce publicou para admins deveria estar no board de qualquer time de plataforma agora, não em setembro.
Vamos direto ao que interessa: datas, o que fazer com cada uma delas e onde normalmente as equipes tropeçam.
- 13 de agosto de 2026: abertura para criar (ou reaproveitar) seu pre-release Developer Edition org. Se você já tinha um da Summer '26, pode simplesmente logar de novo nele, não precisa recriar.
- 19 de agosto de 2026: as release notes completas da Winter '27 ficam disponíveis no Salesforce Help. É o primeiro documento realmente confiável, porque antes disso qualquer coisa que você ouvir é especulação de comunidade.
- 27 de agosto de 2026, até as 17h Pacific Time: prazo para completar (não só solicitar) criação ou refresh de sandbox se você quer que ela entre na janela de preview. Repare no detalhe: o Salesforce Help documenta o corte técnico às 18h PT, mas a orientação prática do time de admins é agir antes das 17h. Essa margem de uma hora existe porque perto do prazo a fila de sandboxes trava, principalmente full sandbox, que demora para copiar. Se não terminar a tempo, sua sandbox cai automaticamente para instância non-preview.
- 28 e 29 de agosto de 2026: fim de semana em que as sandboxes em instância preview recebem a Winter '27.
- Produção: rollout em ondas, cobrindo os fins de semana de 29 de agosto (primeira leva pequena), 3 de outubro e 10 de outubro de 2026. Sua data exata depende da instância e está no Trust.
Repare que isso te dá cerca de cinco semanas de sandbox rodando a nova versão antes mesmo da primeira onda de produção, e até seis ou sete semanas para quem está nas ondas de outubro. É tempo suficiente para testar de verdade, não só para "abrir e ver se quebrou".
Pre-release org não é sandbox de teste, é vitrine
Esse é o ponto que mais gente confunde. A pre-release org vem zerada, sem seus dados, sem metadata, sem customização nenhuma. Isso a torna completamente inútil para regressão, mas excelente para duas coisas bem específicas: explorar funcionalidade nova sem risco de estragar nada, e montar material de treinamento e capturas de tela para o time de negócio antes mesmo da sandbox preview existir.
Minha regra prática de sempre: explore na pre-release org, teste de verdade na sandbox preview. São ferramentas diferentes para momentos diferentes do ciclo, e tratar as duas como a mesma coisa é onde a maioria perde tempo.
Release Updates: o item que todo mundo ignora até doer
O Setup tem uma seção de Release Updates que vive esquecida até o dia em que uma automação para de funcionar sem aviso. Com a Winter '27 chegando, é hora de revisar o que está pendente, o que está atrasado e o que já foi arquivado.
Enforcement de release update não é sugestão, é comportamento que muda independente de você ter testado ou não. Se você é architect ou consultor responsável por múltiplos clientes, esse é o momento de rodar essa checagem em cada org sob sua responsabilidade, não só na sua própria.
Por perfil: o que priorizar agora
- Admin: marcar as datas de sandbox refresh no calendário do time, revisar Release Updates pendentes em cada org, e já reservar tempo de agenda para testar entre 30 de agosto e a data de produção.
- Architect / consultor: mapear quais orgs de cliente têm integrações herdadas (ETL antigo, scripts que ninguém mais mantém, conectores de marketing configurados há anos) que possam depender de comportamento que está sendo descontinuado. Autenticação é um ponto recorrente em releases recentes, então vale auditar fluxos OAuth mais antigos antes da janela de preview.
- Dev: atenção ao detalhe de que metadata criada ou editada usando recursos ou versões de API da Winter '27 não pode ser deployada em produção até a produção também estar na Winter '27. Isso significa manter o pipeline de deploy separado do trabalho de teste de release durante essa janela, senão você cria uma dor de cabeça de versionamento sem necessidade.
- PM / liderança de negócio: qualquer funcionalidade que já vem habilitada por padrão e muda comportamento visível para o usuário final precisa de comunicação prévia. Não é o usuário quem deve descobrir a mudança ao vivo em produção.
Minha leitura
O valor real desse tipo de calendário não está na novidade em si, está na disciplina de usar a janela. Ano após ano vejo o mesmo padrão: times que tratam a sandbox preview como item de checklist genérico, testam duas telas por alto e seguem em frente. E times que usam essas cinco, seis semanas para de fato validar Flow crítico, Approval Process, integração externa e permissionamento contra o comportamento novo antes que isso vire chamado de produção.
A Winter '27 ainda não tem suas release notes completas publicadas (chegam em 19 de agosto), então qualquer expectativa específica de feature de Agentforce, Data Cloud ou Revenue Cloud por enquanto é projeção, não fato. O que já é fato, e vale agir agora, é o calendário.
Comece por aí.
Esse tipo de calendário parece burocracia até o dia em que uma integração cai porque ninguém testou a tempo. Quem trabalha com múltiplos clientes ou orgs sabe que a janela entre sandbox preview e produção é o único momento real de validar automação, integração e comportamento de segurança antes que o usuário final sinta o impacto. Ignorar essas datas custa incidente em produção, não só desconforto de calendário.
Análise baseada no calendário oficial de datas publicado pela Salesforce para o ciclo Winter '27, cruzado com cobertura independente da comunidade sobre prazos de sandbox e produção. As release notes completas da Winter '27 ainda não foram publicadas no momento desta análise (previstas para 19 de agosto de 2026), então qualquer expectativa de feature específica de produto é interpretação e não deve ser tratada como confirmada.
1) Marque no calendário do time: 13/08 (pre-release org), 19/08 (release notes), 27/08 até 17h PT (deadline de sandbox refresh), 28-29/08 (sandbox preview) e sua data específica de produção via Salesforce Trust. 2) Reative ou crie sua pre-release org assim que abrir, e use-a só para exploração e material de treinamento, não para teste de regressão. 3) Priorize revisar Release Updates pendentes em Setup em cada org sob sua responsabilidade antes da janela de preview. 4) Se você tem integrações herdadas (scripts antigos, ETL, conectores de marketing), valide fluxo de autenticação contra o comportamento da nova versão assim que a sandbox subir. 5) Documente Flows, Approval Processes e Validation Rules críticos antes do upgrade para facilitar troubleshooting caso algo quebre.
Cuidado com a diferença entre 'solicitar' e 'completar' o refresh de sandbox: só o que estiver finalizado antes do corte entra na janela de preview, e a fila trava perto do prazo, principalmente para full sandbox. Fique atento também ao detalhe de que metadata criada com recursos ou API da Winter '27 não pode ser deployada em produção enquanto ela não estiver na mesma versão, isso pode travar seu pipeline se não for planejado. E não trate a pre-release org como ambiente de teste real: sem seus dados e customizações, ela não serve para validar regressão.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.