DEV Community: Ashapura Softech INC

Salesforce Workflow Rules Are Retired: How to Move Your Automation to Flow

Ashapura Softech INC — Wed, 16 Sep 2026 10:55:28 +0000

Salesforce workflow rules still run in a lot of orgs, but they are now a retired tool. New workflow rules could not be created from Winter '23, and Salesforce ended support for workflow rules and Process Builder on 31 December 2025. Existing rules may keep firing, but they get no fixes and no new features. Every new automation capability lands in Flow.

This is a practical guide to what that means for an admin or developer who still has workflow rules in production.

Workflow types in Salesforce, and where each one lives now

Old tool	What it did	Where that job lives now
Workflow rule	Field updates, email alerts, tasks, outbound messages on one object	Record-triggered flow
Process Builder	Multi-step logic, related record updates, invoking Apex	Record-triggered flow
Approval process	Multi-step approvals	Still supported, can be launched from Flow
Time-dependent workflow action	Actions X days before or after a date	Scheduled path on a record-triggered flow
Outbound message	SOAP call on record change	Still available as a Flow action

Flow vs workflow rules: what you gain

Before-save updates. A record-triggered flow set to "Fast Field Updates" runs before the record is saved, which is much faster than a workflow field update and does not trigger another save cycle.

Related records. Workflow rules could only update the record itself or its master in a master-detail relationship. Flow can create, update and delete any related records.

One place for logic. Flow can call Apex, subflows and external services, so logic that used to be split across workflow rules, Process Builder and triggers can sit in one ordered set of flows per object.

A real example, rebuilt

The classic rule: when an Opportunity is Closed Won, stamp a date field, email the account owner, and create a follow-up task 30 days later.

Setup, Flows, New Flow, Record-Triggered Flow.
Object: Opportunity. Trigger: created or updated. Entry condition: StageName equals Closed Won, run only when the record is updated to meet the condition.
Before-save path (Fast Field Updates): an Update Triggering Record element that sets Won_Date__c to {!$Flow.CurrentDate}.
After-save flow (a second flow, or the same flow set to "Actions and Related Records"): a Send Email action or your existing email alert.
Add a Scheduled Path 30 days after Close Date with a Create Records element for the Task.
Debug, test in a sandbox, activate, then deactivate the old workflow rule.

Migrating without breaking things

Run the Migrate to Flow tool in Setup for simple rules. It handles field updates and email alerts well. Review everything it generates.
Inventory first. List every active workflow rule and Process Builder per object, because two tools firing on the same object make migration order matter.
Consolidate per object. Aim for one before-save and one after-save flow per object where you can, and use Flow Trigger Explorer to check order.
Test with realistic data volumes. Bulk updates through Data Loader are where badly built flows hit limits.
Deactivate the old rule the same day the flow goes live, or both will run and you will get double emails and double tasks.

The full version of this guide, with more automation examples for Sales Cloud, is on our blog.

Salesforce Core, Advanced or Max: Who Is Watching the Flex Credits?

Ashapura Softech INC — Wed, 16 Sep 2026 09:34:13 +0000

Salesforce replaced Enterprise, Unlimited and Agentforce 1 with three new editions on 3 September 2026: Core at $195, Advanced at $395 and Max at $550 per user per month. Most of the commentary so far compares the feature lists. For the people who actually build and run the org, the more useful question is a different one: who is going to watch the credits?

Every edition now ships with a Flex Credits balance. Core includes 500,000, Advanced 1 million and Max 2.75 million. That number reads like capacity. It is not. It is a starting balance, and how fast it drains depends on what you build, not on which edition you bought.

The full breakdown of the three editions, the pricing and what moved into the bundle is in our Salesforce Core, Advanced and Max editions guide. This post is about the part that lands on the admin and developer side.

Treat credits like API limits, not like licences

Licences are counted once a year. Credits are consumed every time an agent takes an action. That makes them behave much more like API call limits or storage than like seats, and they need the same kind of attention:

A named owner. Someone on the platform team should be responsible for consumption, the same way someone already watches API usage.
A baseline before go live. Run the agent workflows in a sandbox with realistic volumes and record what one case, one lead or one request actually costs.
Alerts, not surprises. Set a threshold well below the included balance and review it monthly for the first quarter.

If you have not worked through how the credit model itself is priced, our explainer on Agentforce pricing and Flex Credits covers the mechanics.

Design decisions change the bill

Two orgs on the same edition can burn credits at very different rates. The drivers we see most often:

How many actions an agent takes per request. An agent that looks up the account, checks the case history and then drafts a reply is three actions, not one.
Whether automation re-triggers the agent. A record-triggered flow that calls an agent on every update will consume far more than one that fires on a status change only.
How clean the grounding data is. Duplicate and stale records mean more retries and longer reasoning. Our Agentforce readiness checklist covers the data work that should happen first.

Outcome-based pricing is a different budget line

Help Agent, available in Advanced and Max, is priced on resolutions rather than per user. That means part of the service budget now moves with case volume. Finance should see that line separately, and the definition of a resolution should be agreed in writing before the contract is signed.

What to ask for before signing

A consumption projection built from your own workflows and volumes, not an industry average.
Written confirmation of what happens to legacy edition pricing at renewal. Salesforce has said existing pricing is unchanged, but renewal quotes follow the new structure.
If you are on Agentforce 1, the no-cost upgrade to Max, requested now rather than at renewal.
A separate budget for implementation. The licence line and the build line get approved by different people.

Where this leaves the build team

Agent configuration is no longer a separate phase that happens after the CRM is live. With Agentforce bundled into every tier, scoping agent actions, guardrails and credit monitoring becomes part of the core implementation plan. If you are choosing someone to help with that, these nine questions for an Agentforce implementation partner are a good filter, and our Salesforce cloud services page shows how we approach it.

Ashapura Softech is a certified Salesforce, Zoho, Microsoft and Odoo implementation partner.

Claude Commerce Agents: the ERP and CRM readiness checklist

Ashapura Softech INC — Wed, 09 Sep 2026 07:17:58 +0000

Anthropic's Claude Commerce Agents blueprint is open source under Apache 2.0, and the demo runs in an afternoon. That part is genuinely easy. The part nobody writes about is that the blueprint deliberately stops at your systems, and everything past that line is your ERP, your CRM and your data model.

We implement CRM and ERP integrations for a living, so this is the list we actually walk through with a client before quoting anything. Twelve things. Nine of them have nothing to do with AI.

What your CRM has to give it

1. Session identity resolved by your host application. The agent inherits an authenticated shopper. It never decides who the user is. Guest checkout, two email addresses on one account, and B2B users buying for three different ship-to locations all have to resolve to one answer before the agent says anything account specific.

2. Order and returns state readable live. Not last night's extract. Partial returns, exchanges and in-flight refunds included, because those are the questions customers actually ask. Anthropic's shopping agent is designed to answer service questions in the same conversation as shopping ones, which is the best thing in the release and also the thing that exposes your data model fastest.

3. Account and contract pricing resolvable per customer. If the agent can only see list price, it will quote list price to a customer sitting on a negotiated rate. In B2B that is not a bug report, it is a phone call from your largest account.

4. Memory scoped, with a written retention rule. What the agent may remember between sessions, for how long, and how a customer gets it deleted. Decide this before launch, not after the first request.

What your ERP has to give it

5. Revenue, margin and returns defined the same way everywhere. Two systems that disagree on margin produce an agent that confidently reports the wrong number, in a sentence, with no visible sign it is wrong.

6. On-hand and committed stock, current. Committed matters as much as on-hand. An agent that only sees on-hand will promise stock that is already allocated.

7. Cost data to reason against, and price floors it cannot cross. The floor belongs in your system, enforced server side. Not in a prompt.

8. Product attributes as structured fields. Size, material, compatibility, voltage. As fields, not buried in a paragraph of marketing copy.

9. A campaign calendar queryable by product. Otherwise the agent recommends a discount on something you are already promoting.

What has to be true across both

10. Every merchant write staged for human approval. The reference implementation is built this way. Keep it that way when you extend it.

11. Credentials held server side in the host application. The agent calls your backend methods. It does not hold keys to your ERP.

12. A test set of real edge cases before pilot. Partial returns, price exceptions, shared logins, discontinued SKUs. This is the part that gets cut, and it is the part that decides whether the pilot survives contact with real customers.

The honest read

There are no platform connectors in the blueprint. Not for Salesforce Commerce Cloud, not for Odoo, Zoho or Dynamics, and none are needed: each backend method is code your team writes that calls your service server side. Which means the timeline is set almost entirely by the state of your product, inventory and customer data, not by the agent code.

If you cannot tick nine of these twelve today, the first phase of a Claude Commerce Agents project is a data and integration project, not an AI project. Be sceptical of any estimate that does not start with a data assessment.

The long version, with the capability-to-system mapping, the failure mode nobody plans for, what it costs to run and how we would sequence a pilot, is here: https://ashapurasoftech.com/blog/claude-commerce-agents-erp-crm-requirements/

When Salesforce Health Cloud Is the Wrong Answer

Ashapura Softech INC — Wed, 09 Sep 2026 06:45:52 +0000

Most articles about Salesforce Health Cloud are written to sell it. This one is not. We implement Health Cloud for a living, and a fair share of our discovery calls end with us telling the buyer not to buy it yet.

Four situations come up often enough to be worth writing down.

1. Nobody is actually going to work a case

Health Cloud is built around case-based work. A care coordinator picks up a member, works a queue, escalates, documents, closes. The whole data model assumes somebody is doing that job every day.

If the real requirement is appointment reminders for a few hundred patients, there is no case work happening. The scheduling and messaging module inside the existing EHR does that job for a fraction of the cost and none of the integration effort. Buying a care management platform to send reminders is the healthcare equivalent of buying a CRM to store a mailing list.

The test is simple. Name the person who will open the application on Monday morning and work through a list. If that person does not exist on the org chart, the platform will sit unused.

2. The EHR interface is not in the contract

This is the one that quietly destroys project budgets.

Every Health Cloud project that matters involves moving clinical data in and out of an EHR. The cost of that work has almost nothing to do with Salesforce and almost everything to do with what the EHR vendor allows. If the organisation has HL7 or FHIR access under its existing agreement, the integration is a known quantity. If it does not, the timeline now includes a commercial negotiation with a vendor who has no reason to hurry.

We ask for the interface terms before quoting, not after. A buyer who cannot produce them is not ready to sign a fixed price, and any partner who quotes one anyway is guessing with the buyer's money.

3. Sales Cloud already covers it

Some organisations arrive at Health Cloud because a consultant told them healthcare needs a healthcare product. Sometimes that is right. Sometimes they already run Sales Cloud, the workflow in question is referral tracking or provider relationship management, and the honest answer is to extend what they own.

The distinction worth holding onto: Health Cloud earns its licence when you need the clinical data model, the care management objects and the consent structures. It does not earn it when you need a pipeline with healthcare-sounding field names. Custom-building the clinical model on Sales Cloud is usually the more expensive mistake, but so is licensing a clinical model nobody will populate.

4. Data governance has not been decided

Who is allowed to see which fields. How long records are retained. Who signs off access reviews and how often.

These are policy questions. They get answered by a compliance officer, a privacy lead and a clinical director sitting in a room. They do not get answered by a configuration workshop, and an implementation partner cannot answer them on the customer's behalf without inventing policy.

Projects that start before those answers exist do not fail loudly. They stall in UAT, when somebody from compliance sees the sharing model for the first time and asks a question nobody has a decision on. Then the build gets reworked with the go-live date unchanged, which is where quality goes to die.

Why say any of this out loud

Because the alternative is worse for everyone. A partner who never says no ends up with unhappy references and rework nobody is paid for, and a buyer who never hears no ends up owning a platform their team quietly works around.

The four checks above cost one conversation. Skipping them costs a quarter.

If you want the longer version of how we scope this work, including the integration routes and the HIPAA controls we configure, it is written up here: https://ashapurasoftech.com/blog/salesforce-health-cloud-implementation-services/

The Four Ways Zoho Actually Connects to Other Software

Ashapura Softech INC — Tue, 08 Sep 2026 05:50:38 +0000

Most "Zoho integration" conversations start in the wrong place. Someone asks whether Zoho connects to Shopify, or QuickBooks, or the ERP the warehouse team refuses to give up. The answer is almost always yes. The useful question is which of the four routes you should use, because picking the wrong one is the single most common reason an integration project costs more than it should.

Here are the four, and where each one stops.

1. Native in-suite links

Zoho applications share one underlying data layer. CRM, Books, Desk, Inventory, Projects and the rest connect to each other with a settings toggle and a field mapping screen. No connector to install, nothing to maintain.

Best for: teams standardising on the Zoho suite.
Where it stops: Zoho to Zoho only. The moment an outside system is involved, you are on one of the other three routes.

2. Zoho Marketplace extensions

A prebuilt connector installed into a Zoho app and configured with field mapping. Marketplace lists extensions for well over a thousand applications, including all the ones you would guess: Shopify, WooCommerce, QuickBooks, Xero, Mailchimp, Stripe, Slack, Microsoft Teams, Twilio.

Best for: the common pairings. If your integration is one that thousands of other companies also need, someone has already built it.
Where it stops: the field mapping is fixed by whoever built the extension. If your process needs a field the extension does not carry, you are back to route 4.

3. Zoho Flow

A no code builder. Something happens in one app (the trigger), and a chain of actions follows in others. Flow connects to several hundred apps directly and to anything else through webhooks.

This is where most of the interesting work lives, because real business processes cross three or four tools rather than two. A useful example: a deal moves to Closed Won in Zoho CRM, so Books raises the invoice, Projects opens the delivery project, and Slack tells the team. Three handovers that used to be done by hand, gone.

Best for: multi step workflows that cross departments.
Where it stops: three places, and it is worth knowing them before you start.

High volume record sync. Flow fires per event. Moving thousands of records on a schedule belongs in a proper integration job or a direct API call, not in a workflow tool.
Complex conditional logic. Once a flow carries more than a handful of branches it becomes hard to test and harder to hand over to the next person. A Deluge function inside CRM is usually cleaner.
Two way sync with conflict rules. If both systems can edit the same field, you need an agreed source of truth and a conflict policy. A one directional flow does not give you either.

4. Custom API and Deluge

Direct calls against the Zoho REST APIs, or server side Deluge functions running inside Zoho itself. This is the route for the legacy system, the industry specific platform, the ERP that nobody has written a connector for.

Best for: anything with an API and no connector.
Where it stops: it needs a developer, and it needs maintaining. That is a real cost, not a footnote.

What most companies actually end up with

A mix. Native links inside the suite, one or two Marketplace extensions for the obvious tools, Zoho Flow for the workflows that cross departments, and a small amount of custom API work for the one system nothing else talks to.

Where to start

Order the work by how much manual re-entry each connection removes, not by how interesting it is to build.

In most companies the finance link goes first, because invoice and payment data is re-keyed daily and mistakes there cost money directly. Commerce usually comes second, then marketing, then support and telephony. Leave the custom API work until the standard connectors are live, because that is the point at which you find out what is genuinely missing rather than what you assumed would be.

What breaks integrations after they go live

Three things, in order of how often they actually happen:

Someone adds or renames a field on one side without telling the other.
An API credential expires and nobody owns renewing it.
A duplicate detection rule silently rejects incoming records, and nobody notices until a month of data is missing.

None of those are technical problems. They are ownership problems. Agreeing who owns field changes before the build starts is worth more than any amount of extra engineering afterwards.

Ashapura Softech Inc. is a certified Zoho, Salesforce, Microsoft and Odoo implementation partner based in Irving, Texas. The longer version of this piece, with the full integration map by system, is on our blog: The Power of Zoho Integration with Third-Party Apps.

HIPAA Checklist for Salesforce Health Cloud Integration

Ashapura Softech INC — Tue, 08 Sep 2026 04:19:42 +0000

Salesforce Health Cloud has become the hub for patient relationships, care coordination and EHR integration. That also makes it a place where a misconfigured role or an unencrypted API call turns into a HIPAA problem.

This is the checklist we work through on Health Cloud deployments, covering user roles, Shield encryption, integration security, logging, AI workflows and retention.

Why compliance breaks during integrations

Health Cloud centralises clinical and non-clinical data, so the volume of PHI in one place grows fast. Every workflow that reads, writes or transmits PHI is a potential exposure point: telehealth, EHR sync, FHIR endpoints, predictive analytics.

The common failure modes are misconfigured API permissions, unencrypted transfers, no monitoring on bulk exports, and AI features processing raw PHI because nobody scoped the inputs.

Step 1: User roles and profiles

Misconfigured access is the single most common source of PHI exposure.

Assign permissions strictly by job responsibility. Care coordinators, providers, billing and admins each get only the objects and fields they need
Lock down high risk objects: CarePlan, RiskAssessment, ClinicalData, PatientCard. Remove View All and Modify All from anyone who does not genuinely need it
Use permission sets rather than per user tweaks, so audits are readable
Review access quarterly, not annually

Step 2: Salesforce Shield

Platform Encryption on PHI fields, attachments and EHR identifiers. Choose deterministic or probabilistic based on whether you need to filter on the field
Event Monitoring for logins, exports and API interactions, with alerts on abnormal behaviour
Field Audit Trail for a historical record of changes to PHI, which is what auditors actually ask for

Step 3: Data classification

Map every field holding sensitive data: medical record numbers, patient identifiers, care notes
Use Salesforce data classification to automate tagging and reporting
Apply the same labelling to custom objects. Custom objects are where PHI quietly leaks during exports

Step 4: Secure the integrations

This is where most of the real risk sits. Every external connection needs its own controls.

OAuth 2.0, mutual TLS and least privilege permissions on every connected system
FHIR requests scoped to the minimum necessary fields, not the whole resource because it was easier
Encrypt every EHR to Health Cloud transfer, validate the field mapping, log the transfer
Signed BAAs for every third party app, and permissions trimmed to what the app actually uses

EPIC integration

TLS 1.2 or above on all API calls
Least privilege access to EPIC data inside Health Cloud
Audit log every read and write on clinical notes, lab results and care plans
Confirm the BAA covers EPIC and any middleware in the path

FHIR sync

OAuth 2.0 plus mutual TLS on the endpoints
Minimum necessary fields in every resource request
Alerts on abnormal API usage patterns
Validate field mapping on the way in, so PHI does not land in an unclassified field

Legacy EHR migration

SFTP or a secure API pipeline, never a plain file drop
Anonymise non essential PHI before the migration where you can
Post migration audit to confirm what landed and who can see it

Step 5: Logging and monitoring

Comprehensive logs for views, edits and exports of PHI
Real time alerts on bulk exports and logins from unrecognised locations
Forward Health Cloud event logs into your SIEM rather than checking them inside Salesforce

Step 6: Retention and backup

Define retention timelines and align them with your own policy, not just the platform default
Automate deletion of expired PHI
Encrypt backups, restrict access, keep them in a HIPAA ready environment
Actually test the restore. An untested backup is not a backup

AI workflows: the part most checklists miss

Health Cloud is turning into an AI platform, and the compliance story has not caught up in most orgs.

Map every AI driven process that touches PHI: predictive analytics, chatbots, clinical decision support
Do not send raw PHI to models outside Health Cloud. Use anonymised or tokenised data for training and testing
Apply Shield encryption to AI input and output fields, and role based permissions on AI dashboards
Log AI interactions with PHI the same way you log human ones, including model changes
Sign BAAs with AI vendors where PHI is processed, and check their breach response before you sign
Document the models, data sources and decision logic. Patients retain the right to access and correct AI influenced data

Five mistakes that come up repeatedly

View All and Modify All left on a profile from the original implementation. Nobody revisits it until an audit does
No audit logging on integrations. The Health Cloud side is logged, the middleware is not, and the gap is where the questions land
Encryption enabled on standard fields only. Custom objects holding PHI get missed
AppExchange packages installed without a BAA and with far more permission than they use
AI features processing raw PHI because the pilot was scoped as a demo and never re scoped

FAQ

Is Health Cloud HIPAA compliant out of the box? No. It is HIPAA ready. Shield encryption, audit logging and role based access exist, but compliance depends entirely on how you configure them.

What is the minimum to be HIPAA ready? Shield Platform Encryption enabled, role based access configured to least privilege, Field Audit Trail on, API connections secured, and a documented risk assessment.

How do AI features affect compliance? Anonymise or tokenise inputs, restrict access to outputs through role based permissions, and log every AI interaction with PHI.

Originally published at ashapurasoftech.com. Ashapura Softech Inc. is a certified Salesforce, Zoho, Microsoft and Odoo implementation partner based in Irving, Texas.

Is Your Salesforce Org Ready for AI Agents? A 2026 Readiness Checklist

Ashapura Softech INC — Mon, 07 Sep 2026 10:09:07 +0000

Two developments in 2026 made org readiness a harder problem than it used to be. Salesforce shipped Headless 360 in April, which lets external agents reach the platform through APIs and MCP tools without navigating a browser. In August, Claudeforce put Salesforce capability directly inside Claude with 37 prebuilt sales skills.

Both inherit the permissions of the user they act for. Salesforce's own documentation puts it plainly: when an agent acts on behalf of a user, it can do anything that user is permitted to do. That turns permission accuracy from housekeeping into a security control.

Pillar 1: Data quality

Agents cannot tell current data from stale data. They will read your pipeline as it stands and produce a confident answer built on whatever is there.

Run these five reports before you enable anything:

Check	Acceptable level	Impact if higher
Duplicate account and contact rate	Under 2%	Account planning, customer health, stakeholder mapping
Open opportunities with past close dates	Under 5%	Forecast narratives become unreliable
Open opportunities with no 30-day activity	Under 15%	Deal health scoring, pipeline review
Opportunities with an empty next step field	Under 10%	Close planning, daily briefings
Contacts with no role assigned	Under 20%	Stakeholder mapping, meeting prep

The fix is usually validation rules and process change, not a one-time cleanup. Without that, the same numbers come back within two quarters.

The field that lies

Plenty of orgs treat a field as required in process but leave it optional in the schema. When Competitor or Loss Reason sits 60% blank, an agent reading the populated 40% will report a selection-biased conclusion as an industry trend, and it will sound authoritative.

Audit every field the business treats as mandatory and make the schema enforce it.

Pillar 2: Permissions

This is where most orgs are exposed, and it is the item most often skipped under deadline pressure.

Audit these:

Every View All or Modify All grant on standard objects, across profiles and permission sets
Report export permissions granted to users
Sharing rules that give broader access than the role hierarchy suggests
Integration users with elevated permissions and no named owner
Users still holding permissions from a role they no longer occupy

Most audits turn up at least one profile that got View All during the original implementation as a deadline fix and was never revisited. When an agent can run natural-language queries across every accessible record without the user opening Salesforce, that old shortcut becomes a live exposure.

Remediation order:

Inventory the over-provisioned profiles
Check login and report-export history to see what access is actually used
Move the legitimate needs into narrowly scoped permission sets
Remove the blanket grants
Retest the affected workflows before enabling agents

Budget three to four weeks for this at a mid-sized org. It is the single item that turns an eight-week pilot into a full quarter.

Pillar 3: Business logic

When work starts in Claude or Slack and lands in Salesforce, the page layout stops being your control surface.

Anything you enforced through the interface, conditional field visibility, user-restricted buttons, required fields per record type, has to be re-implemented in validation rules, flows and sharing models that an agent will actually hit.

Document every rule enforced only by a page layout or Lightning component
Confirm each one has a validation rule or flow equivalent
Flag flows that need a human: screens, confirmations, waits for input
Test automations that fire on field update for loop behaviour under rapid writes

Automation chains built for human-paced data entry behave differently when something writes 40 records a minute. Governor limits will catch some of it, but hitting them mid-workflow leaves partial states.

Pillar 4: Process

Two questions decide whether a pilot produces a repeatable result or a one-off anecdote.

Which single workflow are you piloting? Pick one skill with a measurable time cost, not broad platform enablement. Meeting prep and pipeline review are the strongest candidates because the hours are easy to count.

How will you measure it? Set the baseline before you switch anything on:

Weekly minutes on the task for five reps across one baseline week
The same measurement after four weeks of agent use
An accuracy check by a sales manager across twenty sample outputs
Confirmation that reps are not quietly redoing the work by hand alongside the agent, which is the failure nobody reports

Pillar 5: Measurement and governance

Adoption metrics change meaning. Once sellers start their work in Claude or Slack, Salesforce login counts stop describing usage. Agree the replacement metric before Q1.

Training shifts. The skill is prompting and output verification, not navigation.

Consumption needs an owner. Agentforce billing runs on Flex Credits that expire at order end with no rollover. Someone has to watch the monthly burn.

If you are in a regulated industry

Get the data flow diagram for each deployment path. A single request can cross the model provider, Amazon Bedrock and Salesforce infrastructure. Establish where data rests and where it is processed at each hop. Salesforce's Trust Boundary covers this for Agentforce by running inference inside its own VPC, but external plugin paths can differ.

Confirm logging and retention, then compare the answers against your own retention policy rather than assuming they line up.

How long it actually takes

Phase	Duration	Owner
Data quality assessment	3 to 5 days	Admin or analyst, reporting only
Permission audit	1 week to assess, 3 to 4 weeks to remediate	Admin plus security review
Business logic review	1 to 2 weeks	Developer or architect
Pilot design and baseline	1 week	RevOps
Pilot run	4 weeks	One team

Eight to ten weeks for a typical mid-sized org. Orgs with a disciplined permission model can be ready in about five. Permission remediation is the longest phase and the one most often cut, and its failure mode is data exposure rather than a disappointing demo.

Originally published at ashapurasoftech.com.

Claudeforce vs Agentforce vs Einstein: What Is Actually Different

Ashapura Softech INC — Fri, 04 Sep 2026 12:41:38 +0000

Three Salesforce AI names get used interchangeably in almost every conversation I have. They do three different jobs, and the difference is architectural rather than marketing.

The one-line version

Einstein is prediction and generation inside existing Salesforce features. Lead scoring, forecasting, a suggested reply. It assists the person doing the work. You configure it.

Agentforce runs autonomous agents on the Salesforce platform. An agent takes topics and actions, decides which to use, and completes work end to end, including work that touches customers. You build and deploy it.

Claudeforce goes the other direction. Announced 26 August 2026, it puts Salesforce data inside Claude through a first-party plugin carrying 37 prebuilt sales skills, and makes Claude the default reasoning model behind Agentforce. The work happens in Claude rather than in the CRM screen.

Side by side

	Einstein	Agentforce	Claudeforce
What it is	Prediction and generation in-product	Autonomous agents	Salesforce data inside Claude
Where the work happens	Salesforce UI	Salesforce platform	Claude
Who it serves	The user doing the task	External customers and internal processes	Internal knowledge workers, sellers first
Autonomous	No	Yes	No, it is assistive
How you build it	Configuration	Topics, actions, Flow, Apex	Install the plugin

The architecture point

Claudeforce is only possible because of Headless 360, the API and MCP layer Salesforce has been shipping through 2026. Without a layer that carries the org's permission model along with the data, putting Salesforce records inside a third-party chat window is a security review that never ends.

That is the actual engineering story. The plugin is the visible product. The permission-carrying API layer is the reason it could exist at all.

Pricing, because only one of them has any

Agentforce is priced on consumption rather than seats: Flex Credits at $500 per 100,000, with $2 per conversation and $2 pay-per-resolution options. Your bill scales with agent activity rather than headcount, which is the opposite of how most Salesforce budgets are built.

Claudeforce has no published standalone price. It is with pilot customers, with open beta announced for September 2026. Anyone quoting you a list price is guessing.

How to pick

Ask where your people already work.

If the answer is "in Salesforce, and they need help with the task in front of them", that is Einstein.

If the answer is "we want the task done without a person in the loop", that is Agentforce. The hard part there will be data quality and choosing which workflow to hand over first, not the technology.

If the answer is "our team lives in a chat window and Salesforce is where the data happens to be", that is Claudeforce.

They are not competing. Most orgs that adopt one will end up with two.

The governance question nobody asks until late

Agents inherit the org's sharing model, so an agent cannot read what the user it acts for cannot read. That is the easy half.

The harder half: when an agent completes work that touches a customer and gets it wrong, who owns that? Testing an agent is not testing a feature. You are testing a system that makes decisions. Budget for it the way you would budget for any release that touches customers, because that is what it is.

This is an edited version. The full guide, with the worked pricing example and the complete comparison, is on our site: Claudeforce vs Agentforce vs Einstein

I work at Ashapura Softech, a Salesforce implementation partner, so weigh that accordingly.