Winter '27 turned Agentforce on. We'll tell you what that means in your org.
We build and maintain Sales Cloud, Service Cloud and platform apps, and we review every seasonal release against your configuration. For Winter '27 that starts with Agentforce, which Salesforce now enables by default in orgs that have Agentforce access.
Identity providerOkta · Entra IDDirectory groupssales · service · admins
02 · Salesforce org
SalesforceSales Cloud · Service CloudPermission set groupssharing rules · field-level securityAgentforce agentstopics · actions
03 · Connected systems
ERP and billingorders · invoicesConnected appsOAuth scopes · integration users
04 · Data
WarehouseSnowflake · Data Cloud
SalesforceOktaMicrosoft Entra IDAuth0
in short·15-second read
Cohash implements, extends and maintains Salesforce, including Sales Cloud, Service Cloud, Flow and Agentforce.
Before each seasonal release we check the notes against your org. Winter '27, generally available on 12 October 2026, auto-enables the Agentforce platform in orgs with Agentforce access. We review who holds agent permissions, which data agents can reach, and which agents are actually activated.
you probably need this if
Winter '27 enabled Agentforce in your org and nobody has checked who can build agents.
Release notes arrive three times a year and no one reads them against your configuration.
Your org still runs Process Builder and Workflow Rules alongside newer Flows.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Salesforce Services, 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 services3 open
openWinter '27 enabled Agentforce in your org and nobody has checked who can build agents.
recurringRelease notes arrive three times a year and no one reads them against your configuration.
blockedYour org still runs Process Builder and Workflow Rules alongside newer Flows.
exposure
Winter '27 release reviewAgentforce setup and guardrailsAgent access to dataSales and Service Cloud buildsIdentity and SSOOrg health and technical debt
startrehearsehandover
Org review
Design
Build in sandboxes
Release and support
we are here
ready to hand over
Only named people build agents, and they do it in sandboxes.
There are a few Flows per object, running in an order everyone knows.
New starters get the same access as their peers on the first day, and leavers lose…
Release impact note for each seasonal release
chapter 01 · where it hurts
Why teams reach out
Winter '27 enabled Agentforce in your org and nobody has checked who can build agents.
Release notes arrive three times a year and no one reads them against your configuration.
Your org still runs Process Builder and Workflow Rules alongside newer Flows.
chapter 02 · what we change
How we solve it
Winter '27 release review
Agentforce setup and guardrails
Agent access to data
Sales and Service Cloud builds
Identity and SSO
Org health and technical debt
chapter 03 · how it runs
Our approach
Org review
Design
Build in sandboxes
Release and support
chapter 04 · where you end up
What changes
Only named people build agents, and they do it in sandboxes.
There are a few Flows per object, running in an order everyone knows.
New starters get the same access as their peers on the first day, and leavers lose Salesforce when their directory account goes.
Release impact note for each seasonal release
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Go through the release notes against your org. Sort out which changes affect you and which you can ignore. Write a test list for the sandbox.
Agent topics and actions designed around a real use case, permission sets that limit who can build and activate agents, and testing before anything faces a customer.
Agents act with the permissions you give them. We review sharing rules, field-level security and connected-app scopes so an agent can't reach records its users shouldn't.
Lead-to-cash and case management processes configured with Flow, with Apex only where configuration runs out.
We connect Salesforce to Okta or Entra ID with SAML or OpenID Connect, provision users just in time or through SCIM, and map permission set groups to directory groups.
Inventory the Process Builder and Workflow Rule leftovers, unused fields, Apex test coverage and integration users. Rank the fixes.
capability 01 / 06in production
Winter '27 release review
Go through the release notes against your org. Sort out which changes affect you and which you can ignore. Write a test list for the sandbox.
Agent topics and actions designed around a real use case, permission sets that limit who can build and activate agents, and testing before anything faces a customer.
Agents act with the permissions you give them. We review sharing rules, field-level security and connected-app scopes so an agent can't reach records its users shouldn't.
We connect Salesforce to Okta or Entra ID with SAML or OpenID Connect, provision users just in time or through SCIM, and map permission set groups to directory groups.
We pieced these together from Salesforce Services situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Agentforce enabled by Winter '27 and a test agent already in production
composite · not a client story
Beforethe situation
Winter '27 enabled the Agentforce platform in an org with Agentforce access. The org has hundreds of permission sets, nobody has checked which ones grant agent management, and a sales ops user has already built a test agent in production.
What we dothe work
Start with two lists, one of users who can manage or activate agents and one of existing agents with their topics, actions and running user. Move agent building to a sandbox. Restrict the permissions to a named group. Check what records each agent action can query through sharing and field-level security.
Afterwhere you end up
Only named people build agents, and they do it in sandboxes. What data each agent can reach is on paper. An agent reaches production through the usual release process, like any other change.
case file 02
Workflow Rules and Process Builder still firing on Opportunity and Case
composite · not a client story
Beforethe situation
Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025. An older org still runs dozens of each on Opportunity and Case, mixed with record-triggered Flows on the same objects.
What we dothe work
Export active rules and processes per object and map their execution order against the existing Flows. Use Migrate to Flow as a starting point, consolidate into a small number of before-save and after-save Flows per object, and test with the same records in a full sandbox.
Afterwhere you end up
There are a few Flows per object, running in an order everyone knows. Admins debug in one place, and nothing that matters relies on a feature Salesforce won't fix.
case file 03
Okta SSO in place, but users still created by ticket
composite · not a client story
Beforethe situation
Users sign in to Salesforce through Okta SAML, but accounts are still created by an admin working a ticket. Leavers keep active Salesforce users for weeks, and people with the same job hold different permission set assignments.
What we dothe work
Reconcile active Salesforce users against HR data once. Then turn on SCIM provisioning from Okta or Entra ID, map directory groups to permission set groups by role, and deactivate users when the directory account is disabled.
Afterwhere you end up
New starters get the same access as their peers on the first day, and leavers lose Salesforce when their directory account goes. The access review becomes a review of directory groups.
Where Salesforce sits between your directory, agents and data
Users sign in through your identity provider and get permission set groups from their directory groups. Agentforce agents and integrations act inside the same sharing model, and Salesforce data lands in the warehouse for reporting.
01 · Identity
Identity providerOkta · Entra ID → Salesforce · SAML or OIDC SSO
Directory groupssales · service · admins → Permission set groups · SCIM or JIT mapping
02 · Salesforce org
SalesforceSales Cloud · Service Cloud → ERP and billing · quotes and orders→ Warehouse · replicate objects
Directory groups → Permission set groups: SCIM or JIT mapping
Permission set groups → Salesforce: access
Permission set groups → Agentforce agents: agent permissions
Agentforce agents → Salesforce: records via actions
Salesforce → ERP and billing: quotes and orders
Connected apps → Salesforce: OAuth token
Salesforce → Warehouse: replicate objects
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Org review
We measure metadata, permissions, integrations and data volumes first. The plan has to fit the org you actually have.
step 02
Design
Process designs, data model changes and agent use cases agreed with business owners and your Salesforce admin.
step 03
Build in sandboxes
Changes built and tested in sandboxes, moved through source control and a deployment pipeline.
step 04
Release and support
Go-live, then a review before each seasonal release so you're not surprised in production.
you keep
What you're left with
We write these for your Salesforce Services setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Release impact note for each seasonal release
yours to keep
report02
Agentforce permission and data-access review
yours to keep
report03
Org health report with ranked fixes
yours to keep
code04
Deployment pipeline and source-controlled metadata
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 Services work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who in our org can create and activate Agentforce agents right now?
Winter '27 auto-enables the Agentforce platform in orgs with Agentforce access. That doesn't deploy any agents. It does mean anyone holding the right permissions can now build one in production.
Q2
Which records can each agent action reach, and which user does it run as?
Agents get the permissions they're given. Run one as a broad integration or admin user, and the sharing rules that keep people out of records won't keep the agent out.
Q3
What do you test in our preview sandbox before a seasonal release?
Preview sandboxes get the release before production does. Ask to see the test list they run there, and how findings get to your admin in time.
Q4
How much of our automation still runs on Workflow Rules and Process Builder?
Both lost support on 31 December 2025. They still run, nobody fixes their bugs, and mixed with Flows on the same object you can't easily say what runs first.
Q5
Is our metadata in source control, and who is allowed to deploy to production?
Change sets leave no history, and neither do direct production edits. Keep metadata in source control, deploy through a pipeline, and you can roll back and see who changed what.
01Winter '27 switched Agentforce on in our org. Do we need to do anything?
Salesforce says enabling the platform doesn't deploy any agents and costs nothing extra. Building and activating agents still takes deliberate setup. We'd still check which users have permission to manage agents, and whether any agents already exist in your org, before someone builds one in production.
02When did Winter '27 become generally available?
Your sandboxes and production orgs move when Salesforce's published schedule says, so look up your instance dates on Salesforce Trust. Winter '27 was announced as generally available on 12 October 2026.
03Can you connect Salesforce to our data warehouse?
Yes. We move Salesforce data into Snowflake, Databricks or Microsoft Fabric and model it for reporting, and we can push results such as scores or segments back to Salesforce.
04Do you only do new implementations?
No. Much of our Salesforce work is extending or cleaning up orgs that already run the business, and reviewing releases before they land.
05Should we still migrate Workflow Rules and Process Builder to Flow?
If any are still active, yes. Support ended on 31 December 2025, so they'll keep running with whatever bugs they have. We list the active ones, use Migrate to Flow where its output is clean, and hand-build the rest.
related
Often paired with
Projects on Salesforce Services usually end up touching one of these, so they're worth a look.
