Salesforce Summer '26 brings updates to Agentforce, Flow, permissions, Slack, and data. Use this admin checklist before production release dates.
Salesforce Summer '26 is a release readiness exercise, not a feature shopping list. Admins should test the parts of Salesforce that already carry revenue, service, compliance, and reporting work.
Salesforce announced the Summer '26 product release with availability listed for June 15. That date covers the headline AI features — it is not your instance upgrade date. The announcement calls out Agentforce, multi-agent orchestration, Slack-first workflows, real-time data activation, and AI-powered customer engagement.
The Salesforce Summer '26 release notes are the source admins should work from. Do not plan from headlines alone. Release notes can change during the release window, and Salesforce updates roll out by instance.
The sandbox preview opened the weekend of May 8, alongside the first production wave. The remaining production upgrades land June 5 and June 12–13, depending on your instance. Before you schedule production validation, check three things:
- Whether your preview sandbox is already on Summer '26. It probably is.
- Your production instance release date — June 5 or June 12–13 for most orgs.
- The latest release note updates for the clouds and features you use.
A checklist created in April may miss changes added in May or June. If your instance is in the June 5 wave, the testing window left is measured in days, not weeks.
Salesforce Summer '26 release checklist for admins
Start with the business processes that break loudly.
For most mid-market orgs, that means Lead, Contact, Account, Opportunity, Case, and the custom objects used for intake, onboarding, renewals, compliance, or fulfillment. The release matters less than the process attached to it.
Use this order:
| Workstream | What to check | Primary owner |
|---|---|---|
| Release timing | Sandbox and production dates by instance | Salesforce admin |
| Flow | Record-triggered, scheduled, and screen flows | Admin or developer |
| Permissions | Permission sets, profiles, and app access | Salesforce admin |
| Agentforce | Objects, fields, actions, and approval rules | Ops and IT |
| Slack workflows | Approvals and notifications outside Salesforce | Ops lead |
| Training | Screenshots, job aids, and release notes for users | Admin |
This should fit into one sprint for a stable org. If it cannot, the release is probably exposing a backlog that already existed.
Test Salesforce Flow before production
Flow is the first place to look because it touches daily work. A small change in automation behavior can create duplicate tasks, skipped approvals, bad ownership, or incorrect status values.
Do not test every flow the same way. Rank flows by business impact.
Start with:
- Record-triggered flows on Lead, Contact, Account, Opportunity, Case, and core custom objects.
- Scheduled flows that update owner, status, renewal date, compliance status, or lifecycle stage.
- Screen flows used by sales, service, onboarding, field operations, or finance.
- Flows that call Apex, send outbound messages, publish platform events, or update records across objects.
- Flows built during Workflow Rule or Process Builder migrations.
For each critical flow, test with real process paths:
- Create and convert a lead.
- Update an opportunity stage.
- Generate a quote if quoting is in scope.
- Create a case from each active intake channel.
- Reassign case ownership.
- Close a case with required fields.
- Run scheduled automation against test records.
- Confirm downstream reports still show the expected values.
Admin testing finds technical issues. User testing finds process issues. Both are needed.
Review permission sets and profiles
Permission work is rarely clean in a mid-market Salesforce org. Many teams carry cloned profiles, legacy permission sets, one-off access exceptions, and former admin privileges that nobody has reviewed in years.
Summer '26 is a good time to clean the access model, but keep the scope controlled.
Start with the top 10 permission sets by assigned user count. For each one, document:
- What object permissions it grants.
- What field permissions it grants.
- Which apps and tabs it exposes.
- Which users have it.
- Who owns the business reason for that access.
- Whether the permission set is still needed.
If nobody can explain a permission set, do not delete it immediately. Remove it from new-user assignment first. Then test with a small user group before retiring it.
Also review profile changes in the enhanced profile interface if your org uses it. Some release coverage has noted clearer permission dependencies. That can help admins see related access impacts while making changes. It does not replace an access matrix.
At minimum, your access matrix should list the permission set name, target role, objects granted, sensitive fields included, approval owner, and last review date.
Set Agentforce rules before enabling actions
Salesforce is positioning Summer '26 around Agentforce and AI-assisted work. That does not mean every feature belongs in production on day one.
Agentforce work should start with operating rules.
Define:
- Which objects an agent can read.
- Which objects an agent can update.
- Which fields are excluded.
- Which actions need human approval.
- Which user or queue owns the record after the agent acts.
- Which logs show what the agent did.
- Which team reviews exceptions.
Be specific about excluded fields. Examples include Social Security number, health data, compensation, bank details, policy numbers, and internal risk notes. The exact list depends on your org and industry.
The same rule applies to write actions. If an agent can update Opportunity Stage, Case Status, Lead Status, Next Step, Renewal Date, or a compliance field, document the approval path before enabling it.
A useful first Agentforce use case is narrow. It has a named object, a named user group, a known data boundary, and a clear fallback when the agent cannot complete the work.
Treat Slack workflows as process design
Slack-first workflows can reduce context switching. They can also hide important process steps if the Salesforce record is not updated correctly.
A Slack approval is not a data model. Salesforce still needs clean fields, timestamps, owners, and audit history.
Before moving work into Slack, answer these questions:
- Which approval can happen in Slack.
- Which approval must remain in Salesforce.
- Which Salesforce field changes after approval.
- Which record stores the approval timestamp.
- Which user is shown as the approver.
- Which report proves the process happened.
- Which exception path applies when Slack is unavailable.
Do not move regulated, high-risk, or audit-heavy steps into Slack until reporting and record history are clear.
Update admin documentation
Release testing without documentation creates repeat work.
If a screen flow changes, update the user guide. If a permission set changes, update the access matrix. If an Agentforce action can change a record, document the object, fields, approval rule, and exception owner.
Keep the documentation short:
| Document | Minimum update |
|---|---|
| Release checklist | Instance dates, tested processes, defects, signoff |
| Flow inventory | Flow name, object, trigger, owner, last test date |
| Access matrix | Permission set, users, objects, sensitive fields |
| Agentforce rules | Objects, fields, actions, approvals, logs |
| User notes | Screenshots and changed steps only |
One page per area is enough for most teams.
What not to do for Summer '26
Do not buy more AI capacity because a release note sounds useful. Tie each feature to a named process first.
Do not rebuild working automation only because a builder experience changed. Touch automation when there is a maintenance reason, a risk reduction reason, or a measurable user impact.
Do not let release testing live only with the admin. The person who owns the work should test the work.
Do not skip documentation because the change feels small. Small permission and automation changes are often the ones that create support tickets later.
What admins should do this week
Pick five business-critical processes and test them in sandbox against the Summer '26 release notes.
Use this list:
- Lead creation and conversion.
- Opportunity stage update and approval.
- Case creation from each intake path.
- Scheduled flow or batch job tied to operations.
- One Agentforce or Slack workflow candidate, with data boundaries documented.
LOVALTO's recommendation is direct: test the work your users depend on, define AI and Slack boundaries before production, and update the access matrix before the release reaches users.