DEV Community: Ashapura Softech INC

Agentforce Specialist Exam in 2026: The New Outline and a 4-Week Hands-On Plan

Ashapura Softech INC — Mon, 19 Oct 2026 12:32:16 +0000

If you are studying for the Salesforce Certified Agentforce Specialist exam from a guide written in 2025, you are probably studying the wrong outline. The Spring '26 version dropped the separate Sales Cloud and Service Cloud sections and added Agent Script, hybrid reasoning, Testing Center, governance and multi-agent topics.

Here is what the exam looks like now, according to the official exam guide we checked on 19 October 2026, and the plan we would follow with four weeks and a free org.

The exam in one paragraph

60 scored multiple-choice questions plus up to five unscored ones, 105 minutes, a 72% passing score, USD 200 to register and USD 100 to retake. No prerequisites, though Platform Administrator and Platform App Builder help. You will see older figures online (90 minutes, 73%, or a free promotion from 2025). The current guide wins.

Where the marks are

Section	Weight	Roughly
AI Agents	35%	21 questions
Prompt Engineering	20%	12
Data 360 Fundamentals	20%	12
Testing, Deployment and Maintenance	10%	6
Governance and Observability	10%	6
Multi-Agent Orchestration	5%	3

The question counts are our arithmetic, not Salesforce's. The point is that AI Agents alone is more than a third of the exam, and Data 360 is not optional.

Four weeks, mostly hands-on

Week 1: prompts and the Trust Layer. Create a free Developer Edition org (it now includes Agentforce and Data Cloud and ships with the Coral Cloud sample app). Do the Agentblazer Champion trail. Build one field generation template and one flex template grounded in record data, and notice what changes when you take the grounding away.

Week 2: Data 360 and the Data Library. Build a file-based Data Library, then connect a policy PDF to an agent. Ask it questions the PDF cannot answer and see how it behaves. Chunking, indexing and retrievers make much more sense after you have broken one.

Week 3: agents, the 35%. Do Agent Script Basics and the Agentforce DX project. Build an agent with two topics and one flow-backed action. Compare the canvas and script views, and use variables and filters to make one decision deterministic instead of leaving it to the model.

Week 4: testing, deployment, governance, review. Work through Testing Center, deployment for service agents, analytics and monitoring, and the MCP quick look. Write tests, make them fail, fix them. Then rate every exam objective green, amber or red and spend your last three days only on the red ones.

Three practice questions we wrote

A company wants an agent to answer warranty questions from a PDF that changes every quarter. Do you put the policy in the prompt or in a Data Library? (Data Library, so updates do not mean rewriting prompts.)
Refunds over 30 days must always be declined. Do you rely on instructions or on a variable and filter? (Variable and filter. Wording leaves the decision to the model.)
Sales reps want an assistant that summarizes their own opportunities. Service agent or Employee agent? (Employee agent, for internal users on their own records.)

The mistakes we see most

Studying the old five-section outline, underweighting AI Agents, skipping hands-on work, treating Data 360 as optional, ignoring which user an agent runs as, and forgetting the yearly maintenance module, which expires the certification if you miss it.

Does it help you get hired?

It helps you get shortlisted. Demand for Agentforce skills has risen sharply even as overall Salesforce job demand fell, but roughly a third of admins already hold this certification. When we interview, we ask what the candidate built, tested and fixed. A Developer Edition project you can walk through beats a badge on its own.

The full study guide, with the Trailhead modules mapped to each section and all sources, is here: Agentforce Specialist Certification: 2026 Study Guide and 4-Week Plan. Hiring managers may also find our free Salesforce admin and developer interview scorecard useful.

Ankur Pandey, Ashapura Softech. We are a Salesforce consulting partner with no affiliation to Salesforce's certification program.

AppExchange Became AgentExchange: 6 Checks Before You Install an Agent or MCP Tool

Ashapura Softech INC — Mon, 19 Oct 2026 12:30:20 +0000

AppExchange did not disappear in April 2026. It became one part of AgentExchange, which Salesforce now runs as a single catalog for classic apps, Slack apps, consulting partners, agents, subagents and MCP servers. The old appexchange.salesforce.com address still opens, with a notice about the new name, and your installed packages are still managed from Installed Packages in Setup.

The name change is the boring part. The interesting part for admins and developers is that the same marketplace now sells things that behave very differently once they are inside your org.

A package and an agent are not the same kind of risk

A managed package adds metadata. You can open it in Setup, see the objects, fields and Apex it brought in, and upgrade on your own schedule. Once you understand what it installed, it mostly does what it did yesterday.

An agent or an MCP tool is closer to a contractor. What matters is what it does at runtime: which records it touches, which external systems it calls, and whose permissions it uses while doing it. Reading the listing page tells you very little about that.

Six checks we run before anything from AgentExchange goes near production

1. Security review status, and whether the listing is private. Public listings that need a security review must pass it before distribution. Private listings get no review at all. A passed review is a floor, not a promise.

2. Which profiles get access at install. Enterprise, Unlimited, Performance and Developer Editions let you pick profiles. Professional and Group Editions install with full access for everyone. We install to admins only in a sandbox first and widen access later.

3. What data it reads and where that data goes. Ask the publisher for the objects and fields it reads and writes, the external endpoints it calls, and anything it stores outside Salesforce. If it connects to Slack, you now have a second system to review.

4. Who the agent runs as. Agents run as a user. A new Agent User starts with very little access, which is good, but service agents serving unauthenticated or merely verified visitors run with the agent's own permissions, not the visitor's. Verification identifies a person. It does not decide what that person may see. For MCP servers, the package can carry the server definition and a permission set, but tool actions and gateway policies are configured per org, and tools stay off until an admin selects them.

5. The pricing model. Many new listings price per action or per process using Flex Credits. Ask whether those charges stack on top of your own Agentforce consumption before you sign a private offer.

6. Reviews, publisher and package type. Read recent reviews from companies on your edition, use the test drive, and confirm whether the package is managed. Components from publicly listed managed packages do not count against your custom object and tab limits. Unmanaged and unlisted packages do.

A short evaluation sequence for agents and MCP tools

Write down the job in one sentence and one success measure.
Install in a sandbox with non-sensitive data.
Review the agent user and permission sets, and add access on purpose.
Test as an anonymous visitor, a verified visitor and a logged-in user, and try to pull someone else's record.
Allowlist only the MCP tools you need.
Turn on logging and read transcripts weekly during the pilot.
Model the cost at month-six volume, not week-one volume.
Agree on the off switch before go-live.

What we see in practice

On one consumer electronics project, Service Cloud, CPQ and Agentforce handle 430,000 orders and 280,000 contacts. At that scale, the agent's permission design was the main decision, not which listing to install. On a B2B distribution project, the agent was only as good as the pricing data it could reach, which first meant getting contract rates out of spreadsheets.

Our rule is simple: nothing from AgentExchange goes straight to production, every agent gets a least-privilege user, and someone owns weekly transcript review for the first month.

The full guide, with the comparison table, the partner-side changes and all sources, is on our blog: Salesforce AgentExchange: what replaced AppExchange and 6 checks before you install. If you are planning Agentforce costs, our Flex Credits explainer covers the consumption model.

Ankur Pandey, Ashapura Softech. We are a Salesforce consulting partner.

How to Vet a Custom ERP Development Company (8 Checks)

Ashapura Softech INC — Wed, 14 Oct 2026 05:46:08 +0000

Disclosure: I work at Ashapura Softech, a US software company that builds custom ERP and implements Odoo and Zoho. Originally published on our blog.

Most companies that go looking for a custom ERP development company are not starting from scratch. They run QuickBooks, a pile of spreadsheets, maybe an Access database one person understands, and they have already trialled a packaged ERP that did not fit. So the real question is not who can build ERP. It is who you can trust with the system that will run your orders, stock and billing for the next ten years.

Here is the short version of how we would vet one.

Start by asking whether you need custom at all

A good vendor raises this before you do. Custom ERP pays off when your core workflow is how you make money and no product handles it without heavy workarounds. If your process is standard (buy, stock, sell, invoice), a configured product such as NetSuite, Dynamics 365, Odoo or Zoho is usually faster and cheaper. Many teams land in the middle: a packaged ERP for 80% of the work and custom modules for the 20% that is unique, like pricing rules or job costing.

Ask every vendor which of those three options they would pick for you. If a firm only sells one, expect it to steer you there.

The 8 checks

ERP track record. Two or three ERP or back-office projects they can walk you through. A portfolio of websites and apps is not the same thing.
Business analysis. A named analyst who will run discovery with finance and operations, not "send us your requirements".
Code and data ownership. The contract should transfer the source code, database and documentation to you.
Architecture in plain language. They can explain stack, hosting and scaling without hiding behind a proprietary framework.
Integrations. Real experience connecting ERP to CRM, ecommerce, banks and accounting, priced as line items rather than "small add-ons".
Security and compliance. Roles, audit trails, backups, and awareness of what applies to you (SOX, HIPAA, state tax).
Delivery model. Fixed overlap hours and one accountable US-facing contact.
Post-launch support. A written SLA with response times and a yearly support cost.

One first-call question that tells you the most

"What did your last ERP project get wrong, and what did you change afterwards?" Every team that has shipped ERP has a story about a migration that ran long or a module nobody used. A vendor with no answer has either done little ERP work or is not being straight with you.

Pricing: insist on paid discovery first

Projects are usually priced as fixed price per phase, time and materials, or a dedicated monthly team. Whatever the model, ask for a short paid discovery before any fixed build quote. A full ERP quoted from a one-hour call is a guess, and you pay for the guess later in change requests.

Budget risk is mostly a planning problem. Panorama Consulting's 2024 ERP report found about a third of projects went over budget, with extra technology requirements found mid-project as the most common cause. The fix is an integration inventory during discovery, a clear estimate of your own staff time, and data migration and training priced separately.

Red flags

A fixed price for the whole ERP before discovery
No line for data migration, training or support
Reluctance to put code ownership in the contract
Senior people who vanish after the contract is signed
One platform pushed for every client

A simple weighted scorecard

Score each shortlisted vendor 1 to 5 on: ERP experience (20%), discovery quality (15%), integration experience (15%), code ownership (10%), security (10%), support SLA (10%), team stability (10%) and three-year total cost (10%). Price is only 10% on purpose. The cheapest build is often the most expensive system to own.

The full version with comparison tables and the FAQ is on our blog. Our custom ERP software development page covers cost tiers and timelines, and if Odoo might cover most of your process, see how we work as an Odoo implementation partner.

Budgeting a Zoho CRM rollout in 2026: licences, services and timeline

Ashapura Softech INC — Thu, 08 Oct 2026 08:55:01 +0000

Most teams that ask "what will Zoho CRM cost us?" are really asking two questions. The first is the licence, which Zoho publishes. The second is everything around it: setup, data migration, integrations and the time your own people spend. That second number is the one that surprises budgets, so this post walks through how to estimate both before you ask anyone for a quote.

Originally published on the Ashapura Softech blog, where the full guide covers every phase, the sources behind each figure and an FAQ.

Start with the licence line

Zoho CRM is priced per user per month. On the published US price list, annual billing works out to $14 for Standard, $23 for Professional, $40 for Enterprise and $52 for Ultimate, with a free edition for up to three users. Monthly billing costs more per seat.

The edition matters more than the headline price suggests. Limits on custom modules, workflow rules and blueprint transitions change between editions, and choosing one that is too low usually means paying a consultant to build workarounds that cost more than the upgrade would have. Prices also change, so confirm the current list on Zoho's pricing page before you budget.

Then decide how the work gets done

There are three realistic ways to implement Zoho CRM, and each has a very different cost profile.

Approach	Typical services cost	Time to a working CRM
Do it yourself	60 to 100 hours of internal time	8 to 16 weeks
Hybrid: you configure, a partner migrates and integrates	$3,000 to $10,000	4 to 8 weeks
Full partner implementation, mid-market	$5,000 to $25,000	2 to 4 months

Doing it yourself works for small teams with clean data and no integrations. Once you have history to migrate or two systems to connect, the hybrid model is usually the cheapest route to a CRM people actually use.

Know where the time goes

A mid-size rollout tends to follow the same phases: discovery (one to two weeks), design and configuration (two to four weeks), custom development if you need it, data migration (one to three weeks), integrations (one to three weeks), testing and training, and then go-live with a short hypercare window. Custom development is the phase that varies most, because it is driven entirely by scope.

The five things that move the number

Your data. Duplicate contacts and free-text fields that should be picklists have to be fixed before import. Migration is where most estimates break.
Integrations. Native connectors such as Zoho Books are quick. A two-way sync with an ERP or an online store is a project of its own.
Configuration versus code. Fields, layouts and workflows are cheap to change later. Custom Deluge functions and widgets have to be maintained.
Edition choice. Too low an edition forces expensive workarounds.
Adoption. A CRM nobody updates is the most expensive outcome. Budget for training and for one internal owner.

A quick worked example

Take a 15-person sales team on the Professional edition with annual billing. Licences come to $23 x 15 x 12, or $4,140 for the year. A partner-led small business rollout with one migration and two integrations typically adds $5,000 to $10,000 in services. Add 40 to 60 hours of internal time from the process owner and sales manager. The year-one cash cost lands at roughly $9,140 to $14,140.

Keep it on budget

Write the sales process down before anyone opens Zoho. Changes on paper cost nothing.
Clean and deduplicate data in the source system first.
Launch in phases: pipeline first, then quotes, service or marketing.
Ask partners for a fixed-scope quote with a change process, so you compare scope rather than hourly rates.
Name one internal owner for fields, reports and user requests.

The full guide breaks each phase down further and lists the sources for every figure used here.

Salesforce Winter '27: the auth and integration changes to test before your org upgrades

Ashapura Softech INC — Mon, 28 Sep 2026 09:59:30 +0000

Most Winter '27 coverage leads with Agentforce. If you own Salesforce integrations, the more urgent part of this release is quieter: it starts removing password-based authentication, and some of it lands before your next budget cycle.

Winter '27 goes GA on October 12, 2026. Here are the changes that can break a working integration, and a practical test for each. The full list of 15 changes, including Flow and Agentforce updates, is in our Salesforce Winter '27 release guide.

1. SOAP login() now needs an explicit permission

Winter '27 enforces the release update "Assign Use Any API Auth Permission for SOAP login()". Any user that authenticates through the SOAP login() call needs that permission, or the login fails.

Test: list every integration user, find the ones still calling login(), and grant the permission through a permission set rather than a profile. Then run each integration end to end in a preview sandbox.

Why not stop there: the SOAP login() call itself is scheduled to retire on June 1, 2027. Granting the permission buys time. It does not fix the design.

2. The OAuth username-password flow retires on February 20, 2027

This is the one most likely to cause a silent outage. Integrations that request a token with grant_type=password (username, password and security token) will stop getting tokens. There is no error screen for a user to notice, just a nightly job that quietly stops.

New orgs already block this flow by default. Older orgs with middleware built years ago are the ones at risk.

Test: search your integration code and middleware config for grant_type=password. For each hit, pick a replacement:

Client credentials flow running as a dedicated integration user. The simplest swap for scheduled jobs and middleware.
JWT bearer flow with a certificate. Better for sensitive integrations because no password is stored anywhere.

Keep secrets in Named Credentials rather than in code or environment files.

3. Standard-volume platform events are on the way out

You can no longer create new standard-volume platform events, and new events are high-volume by default. According to the Platform Events Developer Guide, existing standard-volume events retire in Summer '27.

Test: list your custom platform events and check which are still standard-volume. Migrating is not complicated, but it touches every subscriber: Apex triggers, flows and any external CometD client. Retest all of them after the change.

4. Profile Filtering is on by default

Users without the View All Profiles permission can no longer see the names of profiles they are not assigned to. Any code, flow or report that reads Profile.Name as a standard user may now get nothing back.

Test: search your metadata for Profile.Name, run that logic as a standard user in the sandbox, and consider switching profile-based checks to custom permissions, which survive changes like this.

A simple order of work

Confirm your production upgrade window on Salesforce Trust status.
Test in a preview sandbox, not a pre-release org. Pre-release orgs have the features but none of your configuration.
Work through Setup, then Release Updates, before looking at new features.
Put the 2027 migrations (OAuth flow, SOAP login, platform events) on the roadmap now, while there is still room before year-end freezes.

Integration changes rarely fail loudly. They fail at 2am on a scheduled job, and someone notices a week later when the numbers do not match. An hour of inventory work now is cheaper than that week.

This article was originally published on the Ashapura Softech blog, which covers all 15 Winter '27 changes worth testing.

Agentforce Coworker Is Already On. Audit Your Sharing Model First

Ashapura Softech INC — Fri, 25 Sep 2026 10:29:00 +0000

If your org runs Enterprise, Unlimited or Agentforce 1, there is a fair chance Agentforce Coworker is already live in your search bar. Salesforce started switching it on automatically from 10 August 2026, and it became part of AIforce on 15 September. Most admins are treating it as an AI feature to evaluate. It is more useful to treat it as something else: the most honest audit of your sharing model you will ever get.

Why Coworker exposes your sharing model

Coworker does not bypass security. It fully honors the existing Salesforce access model. A user asks a question in plain language and gets one written answer built from every record they are allowed to see.

That last part is the problem. In most orgs, "allowed to see" and "supposed to see" drifted apart years ago. Public Read/Write defaults set during a rushed go-live. Sharing rules nobody remembers creating. A permission set handed to a whole team because one person needed it once.

Classic search hid that drift, because a user had to know what to look for and open records one by one. Coworker removes the friction. It reads across accounts, opportunities, cases, custom objects, knowledge articles, Slack and connected Data 360 sources, then summarises. Anything over-shared is now one question away from being quoted back in a tidy paragraph.

So the first question is not "is the AI accurate?" It is "what can each role actually see?"

Check this before anyone else does

1. Confirm the status. Go to Setup, search "Agentforce Coworker" and see whether it is on. Automatic enablement skipped some orgs: those that opted out of generative AI, multi-dataspace or multi-org setups, HIPAA, health, life sciences and government orgs, and Flex Foundation seats without Unmetered entitlements. Do not assume either way.

2. Audit org-wide defaults on high-traffic objects. Opportunity, Case and any custom object holding pricing, margin or HR data. If the default is Public Read Only and it should be Private, fix it now.

3. List every sharing rule and who it opens records to. Pay attention to rules granting access to "All Internal Users" or a top-level role.

4. Check who holds the Access_Ai_Search permission set group. That assignment is what lets a user in. Start with a pilot group across a few roles, not the whole org.

5. Look at your Data 360 sources separately. Sources that are permission-aware enforce their own rules. Others need governance policies you create by hand in Data 360. An unconfigured connector is the easiest place to leak.

6. Clean duplicates on the objects people ask about most. A summarised answer built from three copies of the same account is confidently wrong.

Then test it by role, not by feature

Pick one user from sales, one from service and one manager. Ask each the same questions: "What are our largest open deals this quarter?" "What did we quote Acme last year?" "Which cases mention a refund?" Compare the answers. If a rep gets a figure only managers should see, you have found a sharing problem, not an AI problem, and it existed long before Coworker arrived.

What it costs, briefly

CRM and Slack search is included at no extra fee on eligible Unmetered seats. Answers that draw on Data 360 objects consume credits, and users without eligible seats are billed on credits too. Measure credit use during the pilot before you widen access.

Limits worth knowing

Updates work on Salesforce CRM records only, and ask the user to confirm first. There is a cap of 30 language model calls per minute per user, files over 75 MB are not indexed, the beta is English only, and it is not available in GovCloud except for Experience Cloud.

The takeaway

Coworker is only as trustworthy as the permissions underneath it. Spend the first week on who can see what, and the rollout after that becomes the easy part.

The full guide, including setup steps and fixes for the common Not Enabled, 401, 400, 500 and Invalid Token errors, is on our blog: Agentforce Coworker: What It Does, What It Costs and How to Turn It On.

Ashapura Softech is a certified Salesforce partner.

The Seven Agentforce Named Agents Are a Data Readiness Test

Ashapura Softech INC — Tue, 22 Sep 2026 11:41:54 +0000

Salesforce shipped seven named Agentforce agents this month. Casey, Paige, Carter, Piper, Fin and Marshall are generally available, and Hunter is in pilot with general availability expected in November 2026.

Most of the coverage reads like a feature list. That is the wrong way to look at it. Every one of these agents is a test of something you already own, and the test is not about AI at all. It is about whether the underlying record, catalogue or process is in a state that an agent can act on.

Here is what each one actually checks.

Casey checks your knowledge base

Casey handles service across voice, SMS, WhatsApp and web chat. It answers from knowledge articles. That means Casey is only as good as the last time someone reviewed those articles.

If your knowledge base has three articles on the same refund policy written in 2023, 2024 and 2026, Casey will answer confidently from whichever one it grounds on. The fix is not prompt tuning. It is a content audit and an owner for every article.

Paige checks whether IT and HR agree on anything

Paige resolves internal IT and HR requests through Slack and employee portals. This is the easiest place to start, because the audience is your own staff and a wrong answer costs a ticket rather than a customer.

What it exposes is ownership. Password resets, laptop requests and leave policy usually live in three systems with no agreed source of truth. Paige forces that conversation before it forces anything else.

Carter checks your product data

Carter assists with discovery, comparison and checkout. It does not replace a storefront. It reads your catalogue.

If two SKUs have inconsistent attributes, missing dimensions or a description written by a supplier five years ago, Carter will compare them badly. Commerce teams tend to discover their catalogue debt the week they turn this on.

Piper checks whether you have a qualification definition

Piper engages and qualifies inbound leads on the website and over email. To qualify a lead, something has to define what qualified means.

In most mid-market orgs that definition lives in a sales leader's head, and the CRM fields that are supposed to carry it are half empty. Piper applies whatever rule you give it, thousands of times, consistently. That consistency is exactly what makes a vague rule visible.

Fin checks whether your handoffs are documented

Fin orchestrates cross-channel workflows. It is the right answer when the problem is that a process breaks between teams rather than inside one.

But an agent cannot orchestrate a handoff nobody has written down. If the step between support and billing is "Sarah usually emails them", there is nothing for Fin to run.

Marshall checks whether the process is actually defined

Marshall executes back office work: invoice handling, order processing, fulfilment exceptions. Deterministic execution is the selling point, and it is also the constraint.

Marshall runs processes. It does not design them. If your exception handling is currently a spreadsheet plus judgment, that has to become a defined path first.

Hunter checks your patience

Hunter runs outbound pipeline from research through outreach, and it is the first agent built on long horizon runtime, meaning it pursues a goal across days or weeks rather than a single session.

It is in pilot. General availability is expected in November 2026. Anything you plan around it before then is a plan around a date Salesforce has not committed to.

The licensing question people skip

Each agent sits inside its product cloud, and consumption draws on the Flex Credit allowance that comes with your edition tier. Two companies on identical editions can burn very different amounts depending on conversation volume and complexity.

That is not a number you can model from a pricing page. Get it confirmed with your account executive before it lands in a budget.

Where to actually start

Start with Paige. Internal audience, contained blast radius, and the ownership problems it surfaces are the same ones that would have broken a customer-facing rollout six months later.

Then pick the agent whose input data you trust most, not the one with the biggest theoretical return. An agent pointed at bad data produces bad answers faster than a human would.

Two platform pieces shipped alongside these agents and are worth watching: multi-agent orchestration, which is generally available now, and Agent Optimizer, expected in October 2026 for building, testing and analysing agent behaviour.

Disclosure: I work at Ashapura Softech, a certified Salesforce implementation partner. The original, longer version of this piece with the full agent-by-agent breakdown and FAQ is on our blog: Agentforce Named Agents.__

AIforce moves the UI outside Salesforce. Your sharing model was not built for that.

Ashapura Softech INC — Fri, 18 Sep 2026 06:14:09 +0000

Salesforce announced AIforce at Dreamforce on 15 September 2026, and most of the commentary has been about the interface. Agents read and act on CRM data from Claude, from Slack, from whatever tool someone already has open, instead of making that person log into Salesforce.

That framing is correct and it buries the part that will actually cost implementation teams their weekends.

The UI was doing security work you never wrote down

For fifteen years the Salesforce page layout has been an informal access control layer. A field exists on the object, it is technically readable by the profile, and it simply is not on the layout anyone uses. Nobody sees it, so nobody worries about it.

Field-level security was the formal control. The layout was the practical one. Those two drifted apart quietly in every org I have looked at.

Take the layout away and only the formal control is left. An agent querying on a user's behalf does not read the layout. It reads what the sharing model and FLS permit, which in a ten-year-old org is a noticeably larger set than what the page shows.

Three places this bites first:

Compensation and cost fields parked on the Opportunity or a custom object, never laid out, never FLS-restricted
Free-text notes fields holding things people would not put in a structured field, including customer health commentary and occasionally personal data
Legacy fields from a migration that nobody removed because removing fields is scary

None of that is a Salesforce defect. It is fifteen years of pragmatism meeting a new read path.

Sharing rules were tuned for humans who ask one question

A rep opens an account, reads it, moves on. An agent answering "which of my accounts are at risk" will traverse far more records in one turn than that rep would touch in a day, and it will do so with that rep's permissions.

The permissions are not wrong. The aggregate is new. A rep with access to 400 accounts one at a time has a different practical exposure from the same rep receiving a synthesised summary across all 400 in four seconds. Role hierarchy and criteria-based sharing were written assuming the slow path.

Worth checking before anyone enables an agent for a sales team: what does the most junior person's permission set actually reach when it is read in bulk rather than one record at a time.

Audit stops answering the question you care about

Salesforce logs the query. It logs the API call and the running user. What it does not carry is the reason, because the reason lived in a conversation somewhere else.

Field Audit Trail tells you a record was read. It does not tell you that it was read because someone in a Slack channel asked about a competitor. When a customer eventually asks who looked at their data and why, the answer now spans two systems and only one of them is yours.

Decide where the prompt and response are retained before the first agent goes live, not after the first awkward question.

A sensible order of work

Run an FLS report against the fields your layouts do not show. Every field readable by a profile and absent from every layout is now effectively exposed.
Pick the narrowest possible first use case, one object, read only, one team. Resist the platform-wide pilot.
Set retention for prompts and responses in whichever tool the agent runs in.
Only then look at write operations, and gate them behind an approval step for anything touching money or contractual terms.

None of that is exciting and all of it is cheaper before launch than after.

The edition change matters here too

The same week brought Salesforce Core, Advanced and Max editions, which replaced Enterprise and Unlimited and bundled Agentforce into every tier with a Flex Credit allocation. Bundled is not the same as configured. The capability arriving in your contract does not mean your org is ready to expose it, and the credits will be consumed by whatever you switch on, including the pilot you did not scope.

If you are deciding between the two agent models before any of this, the practical split between Claudeforce and Agentforce is about where the reasoning happens, not which one is newer. And if you want examples that have published numbers rather than promises, the Agentforce use cases that hold up are the high-volume, documented-answer ones.

For the full announcement breakdown, including the Headless Toolkit and AgentExchange, see what AIforce actually is.

The interface change is the headline. The permission model is the project.

Agentforce Pricing: The 20-Action Break-Even Between Flex Credits and Conversations

Ashapura Softech INC — Thu, 17 Sep 2026 05:11:37 +0000

If you are about to put an Agentforce agent in front of customers, there is one number worth working out before anyone writes a line of Apex: how many actions does a typical conversation take?

That number decides which of Salesforce's billing models is cheaper for you. Everything below uses Salesforce's published list prices. The full breakdown, with sources, is in our Agentforce pricing guide.

The two prices you are choosing between

Flex Credits: $500 per 100,000 credits, so $0.005 a credit. A standard or custom agent action is metered at 20 credits.
Conversations: $2 per customer-facing conversation session, however many actions happen inside it.

So one action costs 20 x $0.005 = $0.10.

The break-even

cost_per_conversation_on_flex = actions_per_conversation * 0.10
break_even = 2.00 / 0.10 = 20 actions

Under 20 actions per conversation, Flex Credits are cheaper.
Over 20, the flat $2 conversation price wins.

That is the whole calculation. The hard part is getting an honest value for actions_per_conversation.

Where the estimate usually goes wrong

1. Counting only the happy path. A test conversation that looks up an order and answers a question might be 4 actions. Real traffic includes retries, clarifying turns and off-topic requests the guardrails have to handle. Those still call actions.

2. Forgetting prompts. Prompts are billed separately from actions: 2, 4 or 16 credits depending on the tier, and chunked in 2,000-token increments. An agent that retrieves too much knowledge pays for it on every turn.

3. Voice. A voice action is 30 credits and every voice minute is another 60, rounded up. A three-minute call with 8 actions is 8 x 30 + 3 x 60 = 420 credits, or $2.10. Voice agents cross the break-even far sooner than chat agents.

4. Sandbox testing. Sandbox runs at a 20% discount, not free. Ten test passes over a big regression suite adds up.

A quick way to get a real number

Before choosing a model, run a pilot on Flex Credits and pull the consumption data per session. Then:

sessions = [...]  # actions per session from the pilot
avg = sum(sessions) / len(sessions)
p90 = sorted(sessions)[int(len(sessions) * 0.9)]

print("avg cost on flex:", avg * 0.10)
print("p90 cost on flex:", p90 * 0.10)
print("conversation price:", 2.00)

Look at the p90, not only the average. If a meaningful share of sessions sits above 20 actions, the conversation model caps your exposure.

Also worth knowing

Pay-per-resolution is also $2, but only charged when the agent resolves the issue on its own. If the customer escalates to a human or leaves negative feedback, there is no charge. For a service team with a good knowledge base this moves the risk to Salesforce.
Flex Credits expire at the end of the order term with no rollover, so buying a large block "just in case" can waste money.
The 10,000-token rule you may have read about does not apply to actions. Salesforce's documentation says each standard action is metered as one action regardless of tokens processed.

Summary

Work out actions per conversation from real pilot data, compare the p90 against 20, and pick the model from that. The rest of the pricing detail, including editions, add-ons and negotiation points, is in the full guide on our blog.

If you are also comparing the new Core, Advanced and Max editions, we covered that in Salesforce Core, Advanced and Max explained.

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/