Salesforce ships a release every season. Your org should still make sense after each one.
We configure and extend Sales Cloud, Service Cloud and the Salesforce Platform, and set up Agentforce with guardrails. Each seasonal release gets tested in a sandbox before your users see it.
Auto-enabled in orgs with Agentforce access in Winter '27
Existing org rollout
Rolling, from the first week of Sep 2026
release watch
Winter '27 release12 Oct 2026
Agentforce enabled by default
connects with
in short·15-second read
Cohash implements, extends and maintains Salesforce orgs.
We build Flows and Apex, integrate Salesforce with identity providers and data platforms like Snowflake, and set up Agentforce agents with clear permissions and topics. For Winter '27, generally available on 12 October 2026, we review the release notes against your org, test in a preview sandbox and plan for Agentforce being switched on by default.
you probably need this if
A Flow or integration breaks after each seasonal release, and users are the ones who notice.
Agentforce is switched on for your org and nobody has decided which users should see agents.
People who left months ago still hold active Salesforce licenses.
12 Oct 2026Winter '27 release Generally available 12 October 2026. Adds Agentforce Contact Center, autonomous scheduling with Agentforce Voice and third-party agent orchestration. source ↗
today · Oct 22, 2026
no date yetAgentforce enabled by defaultWinter '27 turns Agentforce on for eligible orgs and removes the Agentforce setup toggle. Rolling enablement of existing orgs began in September 2026.source ↗
the story · salesforce estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Salesforce estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · salesforce estate3 open
openA Flow or integration breaks after each seasonal release, and users are the ones who notice.
recurringAgentforce is switched on for your org and nobody has decided which users should see agents.
blockedPeople who left months ago still hold active Salesforce licenses.
exposure
Seasonal release readinessAgentforce setup and governanceSales Cloud and Service Cloud…Identity and access for SalesforceIntegration with your data…Org health checks and clean-up
startrehearsehandover
Org health check
Release testing in a preview…
Build through sandboxes and…
Agentforce pilot
Handover
we are here
ready to hand over
Only the pilot group sees Agentforce at first, through permission set groups someone…
Opportunity saves run in a known order at quarter-end.
Release readiness report each season, with regression test results
Agentforce enablement review listing eligible orgs, users and permission sets
chapter 01 · where it hurts
Why teams reach out
A Flow or integration breaks after each seasonal release, and users are the ones who notice.
Agentforce is switched on for your org and nobody has decided which users should see agents.
People who left months ago still hold active Salesforce licenses.
chapter 02 · what we change
How we solve it
Seasonal release readiness
Agentforce setup and governance
Sales Cloud and Service Cloud configuration
Identity and access for Salesforce
Integration with your data platform
Org health checks and clean-up
chapter 03 · how it runs
Our approach
Org health check
Release testing in a preview sandbox
Build through sandboxes and source control
Agentforce pilot
Handover
chapter 04 · where you end up
What changes
Only the pilot group sees Agentforce at first, through permission set groups someone chose.
Opportunity saves run in a known order at quarter-end.
Release readiness report each season, with regression test results
Agentforce enablement review listing eligible orgs, users and permission sets
what we do
Our Salesforce work
6 kinds of Salesforce work, each run by engineers who have done it on live tenants.
We check every release against your org's customizations, Winter '27 included. Regression tests run in a preview sandbox, and admins get a short list of what changes for users.
Agents built with defined topics, actions and data access, tested against real cases before activation. We also review which orgs and users are affected by Agentforce auto-enablement.
Objects, page layouts, Flows and queues set up around how your teams actually sell and support customers, with Apex only where declarative tools fall short.
SSO through Okta or Entra ID, permission set group design, and user provisioning tied to your identity governance platform.
Salesforce data flowing to and from Snowflake, Databricks or Microsoft Fabric through APIs, platform events or zero-copy options where they fit.
A review of technical debt such as unused fields, overlapping automation, old Process Builder flows and broad profiles, with a ranked fix list.
capability 01 / 06in production
Seasonal release readiness
We check every release against your org's customizations, Winter '27 included. Regression tests run in a preview sandbox, and admins get a short list of what changes for users.
Agents built with defined topics, actions and data access, tested against real cases before activation. We also review which orgs and users are affected by Agentforce auto-enablement.
Objects, page layouts, Flows and queues set up around how your teams actually sell and support customers, with Apex only where declarative tools fall short.
We pieced these together from Salesforce situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Agentforce about to switch on in an org built on broad profiles
composite · not a client story
Beforethe situation
An org shared by three business units relies on a few broad profiles instead of permission sets. Agentforce is about to be on by default, and nobody has checked which users would see agents or what data their topics could reach.
What we dothe work
We list which users and permission sets get Agentforce access and map the objects and fields each planned topic would touch. Users move to permission set groups before agents go live. Agents are tested in a sandbox on real cases, then enabled for a pilot group.
Afterwhere you end up
Only the pilot group sees Agentforce at first, through permission set groups someone chose. Each topic reads the objects and fields its role needs and nothing past them. Who gets agents next is a business decision.
case file 02
Process Builders, Workflow Rules and two triggers all firing on Opportunity
composite · not a client story
Beforethe situation
Every Opportunity save sets off Process Builders, Workflow Rules and two Apex triggers written by different admins. Saves hit CPU limits at quarter-end, and each seasonal release brings a new failure.
What we dothe work
We map the automation on Opportunity in execution order and consolidate it into a few record-triggered Flows with entry criteria. Heavy logic moves into one Apex trigger handler. Each change runs against regression tests in a preview sandbox before the next release.
Afterwhere you end up
Opportunity saves run in a known order at quarter-end. The Flows and the trigger handler each have an owner, and the preview sandbox catches release breakage before users do.
We don't start a step until the last one has produced something you can check.
step 01
Org health check
We review automation, Apex, profiles, permission sets, integrations and security settings, then rank what to fix before new work starts.
step 02
Release testing in a preview sandbox
Each seasonal release is checked against your key Flows, Apex tests and integrations in a preview sandbox. Admins get a short note on what changes for users.
step 03
Build through sandboxes and source control
Configuration and code move from developer sandboxes to production through a deployment pipeline, so production only receives changes that passed tests.
step 04
Agentforce pilot
Agents get defined topics, actions and data access, are tested against real cases, and go live for a small group before anyone else.
step 05
Handover
Your admins keep runbooks, a documented permission model and a release checklist they can reuse next season.
ai on salesforce
Where AI fits on Salesforce, and where it needs guardrails.
Salesforce's AI is Agentforce. Winter '27 became generally available on 12 October 2026 and switches Agentforce on by default in eligible orgs. Salesforce also hosts MCP servers now, so agents outside Salesforce can work with CRM data. Most of the engineering is about permissions. Someone has to decide which users see agents and what each topic and action can touch, and which external clients get an OAuth app.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Salesforcedoes the work
Salesforce runs official Hosted MCP Servers. A client connects through an External Client App with OAuth, and every call runs as the authenticated user. So CRUD, field-level security and sharing rules still apply. Our agents get their own integration users with narrow permission set groups, and we log each tool call.
Agentforce agents, topics and actions
Agentforce agents are built from topics and actions over your Salesforce data, and Winter '27 adds Agentforce Contact Center plus autonomous scheduling with Agentforce Voice. An agent can only act through the permissions it runs with. So we map the objects and fields behind each topic, move users onto permission set groups, and test agents on real cases in a sandbox before any pilot group sees them.
Agentforce on by default
Winter '27 turns Agentforce on in eligible orgs, and the setup toggle goes away. Existing orgs have been enabled on a rolling basis since September 2026. We work out which users and permission sets get access and settle it with the business. That way users don't find agents on their own first.
Salesforce Hosted MCP Servers
Hosted MCP Servers reached general availability in April 2026 for Enterprise Edition and above. There are standard servers for SObject data, Data 360 and Tableau. Flows, Apex actions and Prompt Builder prompts can be exposed by admins as custom tools. We pick the tools each client may call, and give every client its own External Client App.
AI-assisted Apex and Flow clean-up
Developer Edition orgs now include the Agentforce Vibes IDE alongside hosted MCP servers. We use AI coding tools like this to document old Apex and Flows, draft unit tests and find overlapping automation before a release. Every change still goes through review and a preview sandbox.
How Salesforce connects to identity, back-office data and your warehouse
Okta handles sign-in and SailPoint decides who gets which permission sets. Salesforce exchanges orders and accounts with the ERP, and sales and service data flows on to Snowflake or Databricks for reporting.
01 · Identity and back office
OktaSAML SSO · MFA → Sales and Service Cloud · SAML sign-in
SailPointjoiner · mover · leaver → Sales and Service Cloud · permission sets
ERPorders · invoices · products → Sales and Service Cloud · REST API sync
02 · Salesforce org
Sales and Service Cloudobjects · Flows · Apex → Agentforce agents · records · cases→ Snowflake · change data capture→ Databricks · zero copy share
Agentforce agentstopics · actions · guardrails
03 · Data platform
Snowflakereporting copy · marts
DatabricksML features · lakehouse
Read the diagram as text
Okta → Sales and Service Cloud: SAML sign-in
SailPoint → Sales and Service Cloud: permission sets
ERP → Sales and Service Cloud: REST API sync
Sales and Service Cloud → Agentforce agents: records · cases
Sales and Service Cloud → Snowflake: change data capture
Sales and Service Cloud → Databricks: zero copy share
use cases
Typical Salesforce projects
The work teams usually bring us, and the platforms Salesforce has to talk to while we do it.
SAL-01Every seasonal release breaks a Flow or integration nobody remembered
common request
SAL-02You want to try Agentforce without exposing data agents shouldn't see
common request
SAL-03Salesforce users are provisioned by hand and never removed
common request
SAL-04Sales and service data needs to reach your warehouse on a schedule people trust
common request
SAL-05The org has years of overlapping automation and no one wants to touch it
common request
These are working documents, written against your configuration, so your team can run them without us.
tests01
Release readiness report each season, with regression test results
yours to keep
report02
Agentforce enablement review listing eligible orgs, users and permission sets
yours to keep
inventory03
Automation inventory with Process Builder and Workflow Rule migration plan
yours to keep
plan04
Permission set group design with a profile clean-up plan
yours to keep
code05
Integration map with API limits, owners and failure handling
yours to keep
talent and delivery · salesforce
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Salesforce work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which of our users will see Agentforce once it's switched on by default?
Winter '27 auto-enables Agentforce in orgs with Agentforce access. Who sees it depends on permission sets and licenses, and that should be reviewed before users find agents on their own.
Q2
How will you regression-test each seasonal release before it reaches production?
Preview sandboxes get the release weeks before production. Without a test list for key Flows, Apex and integrations, that window goes unused.
Q3
What data can each Agentforce topic and action reach, and who signed off on it?
Agents act through the permissions they run with. Mapping topics and actions to objects and fields shows whether an agent can read or change more than the role it serves.
Q4
How will you consolidate our Process Builders and Workflow Rules?
Overlapping automation on one object causes CPU-limit errors and unpredictable order. Moving to record-triggered Flows helps only if the logic is mapped and merged first.
Q5
How will Salesforce access be granted and removed through our IGA platform?
Permission set groups provisioned from SailPoint or Entra ID end manual assignment. Without that link, leavers keep access until someone files a ticket.
01What should we check before Winter '27 reaches our production org?
Read the release notes for the clouds you license, then run your key Flows, Apex tests and integrations in a preview sandbox. Check whether your org is eligible for Agentforce auto-enablement and decide which users should see agents. Salesforce publishes the exact upgrade date for each instance on its Trust site.
02Does Agentforce cost extra now that it's on by default?
Salesforce has said auto-enablement itself carries no extra charge. Agent usage is still governed by your licenses and consumption terms, so we review your contract and expected volumes with you before agents go live.
03How long does a Salesforce implementation take?
It depends on the number of clouds, the volume of data to migrate, and how many systems need integration. A focused Sales Cloud rollout is much smaller than a multi-cloud program with a legacy CRM migration. We size it after a short discovery.
04Do you also handle Salesforce identity and security?
Yes. This is core work for us. We set up SSO and MFA, design permission set groups, and connect Salesforce to SailPoint or Entra ID so that access gets granted and removed without anyone doing it by hand.
05Can you take over an org another partner built?
Yes. We start with an org health check covering automation, code, security settings and integrations, then agree with you what to keep, fix and rebuild.
services
Related services
Projects on Salesforce usually end up touching one of these, so they're worth a look.
