DEV Community: Ashapura Softech INC

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/

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.