Start a project
Menu
ServicesAll servicesCybersecurityCloud EngineeringApplication ServicesEnterprise PlatformsData & AnalyticsAI & Machine LearningInternet of ThingsMobilize Talent
PlatformsAll platformsIdentity and accessPrivileged access and secretsERP, HCM and financeCRM, ITSM and automationHealthcareInsurance and bankingData and integrationCloud and AIIndustrial, utilities and mainframeSkills matrix
Case studiesAll case studiesIdentity and accessPrivileged accessSecurity operationsCloud and infrastructureApplicationsERP and HCMCRM, ITSM and automationIndustry platformsData and analyticsAI and agents
IndustriesAll industriesEnergy, oil & gasHealthcare payersBanking & financial servicesInsurancePublic sectorManufacturingLocations
InsightsField notesLearning tracks
CompanyAbout CohashPortfolioSkills matrixCareersTrust and securityContact
Start a project
crm

Salesforce puts out a new release every season. We test your org against it before your users find what broke.

We configure and extend Sales Cloud, Service Cloud and the Salesforce Platform, and we set up Agentforce so agents only see what they should. Before each seasonal release reaches your users, we run it in a sandbox against your own Flows and integrations.

Talk to a Salesforce engineerWhat changed recently
platform dossierSalesforceCRM
Vendor
Salesforce
Current release
Winter '27, GA 12 Oct 2026
Agentforce default
On in orgs with Agentforce access, planned rollout from first week of Sep 2026
Default enablement cost
No extra charge, per Salesforce
release watch
  • Agentforce on by defaultSep 2026
  • Braze acquisition agreement20 Oct 2026
connects with
in short·15-second read

Cohash builds and looks after Salesforce orgs, from Flows and Apex to SSO and the feeds into Snowflake.

Winter '27 went GA on 12 October 2026, and Agentforce is being switched on by default in orgs with Agentforce access. We test each release in a preview sandbox and work out with you who should see agents.

you probably need this if
  • Each seasonal release breaks a Flow or an integration, and it's users who find out first.
  • Agentforce is already on in your org, but nobody's decided which users ought to see agents.
  • People who left months ago still hold active Salesforce licenses.
terms on this page RulesdefinitionThe JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.explained in a field note →sandboxdefinitionA non-production copy of your system that people test and train on. It eats into your storage just like production does.explained in a field note →
Ask an engineer facts checked 2026-11-03
how it runs
  1. 01Org health check
  2. 02Release testing in a preview sandbox
  3. 03Build through sandboxes and source control
  4. 04Agentforce pilot
  5. 05Handover
you keep
  • A release readiness report every season, with the regression test results so you can see what we ran
  • A list of who gets Agentforce in each org and through which permission set, for you to sign off
  • An inventory of the automation, with a plan to move each Process Builder and Workflow Rule to Flow
+ 2 more documents
who does it
Salesforce platform developer (Apex, LWC)Salesforce administratorSalesforce integration architect Salesforce Certified Platform Administrator Salesforce Certified Platform Developer
platforms
proof
20 case studies on this
background
Time to get under Copy, restoreblocked Sandboxadmin-only Sandboxdisabled Day 0 Day 90
field note · 15 minDynamics 365 storage limits start to bite on 9 November: what gets blocked, how to get out
salesforce · release timeline
  1. 31 Dec 2025 Workflow Rules and Process Builder support ended Support for Workflow Rules and Process Builder ended after 31 December 2025. If one of them breaks after a release, Salesforce won't help and won't fix the bug. Move that automation to record-triggered Flows before it's the thing that breaks.
  2. Sep 2026 Agentforce on by default Salesforce planned to start switching Agentforce on in existing orgs with Agentforce access on a rolling basis from the first week of September 2026. The Agentforce toggle in Setup is due to go later in Winter '27. If you aren't ready, the Einstein setting on the Einstein Setup page still turns the platform off, so decide who should see agents now.
  3. 12 Oct 2026 Winter '27 release Winter '27 went generally available on 12 October 2026. The big items were Agentforce Contact Center, now in more than 30 countries, appointment booking handled by Agentforce Voice, and orchestration of other vendors' A2A-compliant agents. Once your instance has upgraded, rerun your key Flows and integrations and check nothing quietly changed.
  4. 20 Oct 2026 Braze acquisition agreement Salesforce agreed on 20 October 2026 to buy Braze, at about $5.66 billion in enterprise value. Don't plan around it yet. Braze shareholders still have to vote, the close is expected in Salesforce's fiscal year 2028, and only then is Braze meant to strengthen Marketing Cloud's cross-channel personalization.
  5. today · Nov 09, 2026
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.

  1. chapter 01 · where it hurts

    Why teams reach out

    • Each seasonal release breaks a Flow or an integration, and it's users who find out first.
    • Agentforce is already on in your org, but nobody's decided which users ought to see agents.
    • People who left months ago still hold active Salesforce licenses.
  2. 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
  3. 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
  4. chapter 04 · where you end up

    What changes

    • At first only the pilot group sees Agentforce, through permission set groups that someone actually picked.
    • At quarter-end, Opportunity saves now run in an order people know.
    • A release readiness report every season, with the regression test results so you can see what we ran
    • A list of who gets Agentforce in each org and through which permission set, for you to sign off
what we do

Our Salesforce work

6 kinds of Salesforce work, each run by engineers who have done it on live tenants.

  1. 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.

  2. 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.

  3. 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.

  4. SSO through Okta or Entra ID, permission set group design, and user provisioning tied to your identity governance platform.

  5. Salesforce data flowing to and from Snowflake, Databricks or Microsoft Fabric through APIs, platform events or zero-copy options where they fit.

  6. 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.

talk to an engineer about this →
capability 02 / 06in production

Agentforce setup and governance

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.

talk to an engineer about this →
capability 03 / 06in production

Sales Cloud and Service Cloud configuration

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.

talk to an engineer about this →
capability 04 / 06in production

Identity and access for Salesforce

SSO through Okta or Entra ID, permission set group design, and user provisioning tied to your identity governance platform.

talk to an engineer about this →
capability 05 / 06in production

Integration with your data platform

Salesforce data flowing to and from Snowflake, Databricks or Microsoft Fabric through APIs, platform events or zero-copy options where they fit.

talk to an engineer about this →
capability 06 / 06in production

Org health checks and clean-up

A review of technical debt such as unused fields, overlapping automation, old Process Builder flows and broad profiles, with a ranked fix list.

talk to an engineer about this →
typical situations

Salesforce situations we walk into

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
  1. 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.

  2. What we dothe work

    First we list the users and permission sets that would get Agentforce, and map the objects and fields each planned topic would touch. Users move onto permission set groups before any agent goes live. We test agents in a sandbox on real cases, then switch them on for a pilot group.

  3. Afterwhere you end up

    At first only the pilot group sees Agentforce, through permission set groups that someone actually picked. Each topic reads the objects and fields its role needs and stops there. Who gets agents next is up to the business.

case file 02

Process Builders, Workflow Rules and two triggers all firing on Opportunity

composite · not a client story
  1. 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.

  2. 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.

  3. Afterwhere you end up

    At quarter-end, Opportunity saves now run in an order people know. Someone owns each Flow and the trigger handler. When a release breaks something, it shows up in the preview sandbox before users ever see it.

case studies

Salesforce case studies

All case studies
migration CRM, ITSM and automation

Replacing a homegrown or Siebel CRM nobody wants to touch with Salesforce or Dynamics 365

Outgrown a homegrown or Siebel CRM? We move its business rules, data and integrations to Salesforce or Dynamics 365, one business unit at a time.

read the case study
consolidation CRM, ITSM and automation

Merging multiple Salesforce orgs

Consolidating the Salesforce orgs that acquisitions and regional builds left behind, with data models, users, automation and integrations merged into one.

read the case study
upgrade CRM, ITSM and automation

Salesforce Workflow Rules and Process Builder to Flow

Moving Workflow Rules and Process Builder to Flow after end of support, consolidated per object and tested before the old rules are turned off.

read the case study
migration Identity and access

AD FS federation to Entra ID authentication

Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.

read the case study
upgrade Identity and access

Moving Auth0 Rules and Hooks to Actions before Auth0 switches them off

Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.

read the case study
AI rollout AI and agents

Microsoft 365 Copilot or Gemini Enterprise rollout with real adoption

Rolling out Microsoft 365 Copilot or Gemini Enterprise with oversharing fixed first, use cases tied to real tasks and adoption measured past login counts.

read the case study
approach

How a Salesforce engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Org health check

    We go through the automation, Apex, profiles, permission sets, integrations and security settings first. Then you get a ranked list of what to fix before any new work starts.

  2. step 02

    Release testing in a preview sandbox

    Every season we run your key Flows, Apex tests and integrations in a preview sandbox on the new release. Admins get a short note on what will change for their users.

  3. step 03

    Build through sandboxes and source control

    Nothing gets built straight in production. Config and code start in developer sandboxes and move up through a deployment pipeline, and a change that fails its tests stops there.

  4. step 04

    Agentforce pilot

    Each agent gets its topics, actions and data access written down. We test it on real cases, then switch it on for a small group before anyone else gets it.

  5. step 05

    Handover

    Your admins keep the runbooks and a written-down permission model. They also get a release checklist they can pick up again 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.

architecture

How Salesforce connects to identity, back-office data and your warehouse

Okta does the sign-in. SailPoint works out which permission sets each person should hold. Orders and accounts move both ways between Salesforce and the ERP, and sales and service data goes on to Snowflake or Databricks for the reports.

How Salesforce connects to identity, back-office data and your warehouse Okta does the sign-in. SailPoint works out which permission sets each person should hold. Orders and accounts move both ways between Salesforce and the ERP, and sales and service data goes on to Snowflake or Databricks for the reports. 01 · IDENTITY AND BACK OFFICE 02 · SALESFORCE ORG 03 · DATA PLATFORM SAML sign-in permission sets REST API sync records · cases change data capture zero copy share Okta SAML SSO · MFA SP SailPoint joiner · mover ·leaver ERP orders · invoices · products Sf Sales and ServiceCloud objects · Flows · Apex Agentforce agents topics · actions ·guardrails Snowflake reporting copy · marts Databricks ML features ·lakehouse © Cohash · cohash.com
01 · IDENTITY AND BACK OFFICE02 · SALESFORCE ORG03 · DATA PLATFORM Okta: SAML SSO · MFA Okta SAML SSO · MFA SailPoint: joiner · mover · leaver SailPoint joiner · mover· leaver ERP: orders · invoices · products ERP orders ·invoices ·products Sales and Service Cloud: objects · Flows · Apex Sales andService Cloud objects · Flows ·Apex Agentforce agents: topics · actions · guardrails Agentforceagents topics · actions ·guardrails Snowflake: reporting copy · marts Snowflake reporting copy ·marts Databricks: ML features · lakehouse Databricks ML features ·lakehouse SAML sign-in permission sets REST API sync change data capture zero copy share © Cohash · cohash.com
use cases

Typical Salesforce projects

The work teams usually bring us, and the platforms Salesforce has to talk to while we do it.

  1. SAL-01 Every seasonal release breaks a Flow or integration nobody remembered common request
  2. SAL-02 You'd like to try Agentforce, but not if agents can read data they shouldn't common request
  3. SAL-03 Salesforce users get added by hand and nobody ever removes them common request
  4. SAL-04 Sales and service data has to reach the warehouse on a schedule people can actually trust common request
  5. SAL-05 The org has years of overlapping automation and no one wants to touch it common request
  6. SAL-06 Nobody has moved the old Workflow Rules and Process Builders, though Salesforce support for them ended in 2025 common request
Salesforce · connected platforms
OktaMicrosoft Entra IDSailPointSnowflakeDatabricksMicrosoft FabricMicrosoft Dynamics 365
you keep

What a Salesforce engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • tests01

    A release readiness report every season, with the regression test results so you can see what we ran

    yours to keep
  • inventory02

    A list of who gets Agentforce in each org and through which permission set, for you to sign off

    yours to keep
  • inventory03

    An inventory of the automation, with a plan to move each Process Builder and Workflow Rule to Flow

    yours to keep
  • plan04

    Permission set group design, plus a plan for cleaning up old profiles

    yours to keep
  • inventory05

    A map of every integration, its API limits, who owns it and how failures get handled

    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.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • Salesforce Certified Platform AdministratorSalesforce
  • Salesforce Certified Platform DeveloperSalesforce
  • Salesforce Certified Platform App BuilderSalesforce
  • Salesforce Certified Platform Integration ArchitectSalesforce
roles we staff
  • Salesforce platform developer (Apex, LWC)
  • Salesforce administrator
  • Salesforce integration architect
  • Salesforce technical architect
  • Agentforce developer
  • Salesforce DevOps and release engineer
due diligence · salesforce

Questions to ask any partner, including us.

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.

  1. Q1

    Which of our users are going to see Agentforce once it's on by default?

    Winter '27 switches Agentforce on in orgs with Agentforce access, whether or not anyone asked. Permission sets and licenses decide who sees it, so look at them before users find agents on their own.

  2. Q2

    What do you actually test in the preview sandbox before a release hits our production org?

    Preview sandboxes get the release weeks before production. Without a test list for key Flows, Apex and integrations, that window goes unused.

  3. Q3

    What can each Agentforce topic and action actually read or change, and who signed that off?

    An agent can do whatever the permissions it runs with allow. Map each topic and action to the objects and fields it touches, and you'll see whether an agent can read or change more than its role needs.

  4. 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.

  5. Q5

    When someone joins or leaves, how does our IGA platform add or remove their Salesforce access?

    Permission set groups provisioned from SailPoint or Entra ID end manual assignment. Without that link, leavers keep access until someone files a ticket.

01When is the Salesforce Winter '27 release date?

Salesforce made Winter '27 generally available on 12 October 2026. Your production org doesn't move that day, though. Each instance upgrades in its own maintenance window, posted on Salesforce's Trust site, and preview sandboxes get the release weeks earlier, so that's when to test.

02What's new in Winter '27 that our Salesforce admins actually have to deal with?

The big items are Agentforce Contact Center, appointment booking through Agentforce Voice, and orchestration of other vendors' A2A-compliant agents. The one admins can't ignore is Agentforce switching on by default in orgs with Agentforce access. Check who can see agents, and use the Einstein setting on the Einstein Setup page if you need it off for now.

03What should we check now that Winter '27 is out?

Read the release notes for the clouds you license. Then rerun your key Flows, Apex tests and integrations and see what fails. Find out whether your org is one of those getting Agentforce switched on, and pick the users who should see agents. If an instance hasn't upgraded yet, its date is on Salesforce's Trust site.

04Agentforce is on by default now. Are we going to pay extra for it?

Salesforce says switching it on costs nothing extra and doesn't change billing. Using agents is a different matter. That still runs through your licenses and consumption terms, so we go through your contract and expected volumes with you before any agent goes live.

05How 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.

06Can you handle the identity side too, like SSO and MFA for Salesforce?

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.

07Can you take over an org another partner built?

Yes. The first step is an org health check of the automation, code, security settings and integrations. After that we sit down with you and agree what stays as it is, what gets fixed and what we rebuild.

services

Related services

Projects on Salesforce usually end up touching one of these, so they're worth a look.

you are hereSalesforce
fact-checked Checked against vendor and official documentation last checked 2026-11-03 content fingerprint 6415a4dc
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Salesforce is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies
useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it