Menu Book a free audit
Business systemยทPlatforms

What we build in Salesforce

The most capable CRM API in the category, and the one where the interesting question is governance rather than integration. Almost anything is possible; the discipline is deciding what belongs inside the org and what does not.

Short answer

Salesforce has the most capable CRM API in the category: REST for transactional work, Bulk for volume, and platform events for genuine push rather than polling. Integration capability is essentially never the constraint. Accumulated configuration is: an org live for five years usually carries flows, validation rules, triggers and managed packages that nobody has mapped in full.

We build lead capture and routing, enrichment on creation, two-way sync with accounting, quote generation, stage-triggered orchestration, data hygiene and migrations in, holding cross-system logic outside the org where it can be read in one place. We do not design against it before checking two things: what your edition includes, because some editions gate API access altogether at the lower tiers, and what already fires on the records you are writing to.

What it is, and where it sits

Salesforce is common at the larger end of the small and mid-market range. Businesses that have outgrown a simpler tool, or that inherited it and now run everything through it. Its APIs are excellent: REST for transactional work, Bulk for volume, and platform events for genuine push rather than polling. Integration capability is essentially never the constraint.

What is the constraint is accumulated configuration. A Salesforce org that has been live for five years usually carries flows, validation rules, triggers and managed packages that nobody has mapped in full. The risk in a Salesforce automation is rarely the code we write; it is the interaction with something already there that fires on the same record.

What we build in it

  • Lead capture, deduplication and routing from every inbound source, with the assignment rules made legible
  • Enrichment on creation: firmographics, technology, territory assignment
  • Two-way sync with accounting so opportunity and invoice state agree
  • Quote and proposal generation from opportunity data
  • Stage-triggered orchestration out into delivery, finance and document systems
  • Data hygiene: continuous deduplication, normalization, stale-record flagging
  • Consolidated reporting joining Salesforce to systems it does not know about
  • Migrations in, with field mapping signed off and a dry run against a sandbox

How it is priced

You pay Salesforce directly. Two things matter for an automation budget.

ModelWhat you pay forBest when
Salesforce subscriptionLicenses, paid to Salesforce directly.Already settled by your edition and your headcount.
API call allowanceAn allowance tied to your edition and license count, consumed per 24 hours across the whole org, including by every other integration you already run.Budgeted as a real constraint during scoping. A design that polls every minute can quietly eat a meaningful share of it before it does anything useful.
Edition gatingThe tier that includes API access at all.Confirmed before anyone designs against it. Some editions gate it altogether at the lower tiers.

When to choose it, and when to think twice

Whether to use Salesforce is rarely the live question. Where the logic goes is. Anything touching only Salesforce data belongs inside it, where Flow is capable and your admin can maintain it. Anything crossing a system boundary belongs outside.

Choose it when
Think twice when
The logic touches only Salesforce data: validation, field calculations, stage rules, internal notifications. Flow is capable and your admin can maintain it.
Governor limits are real and deliberateBulk operations must be designed for them rather than discovering them. This is the platform behaving correctly, not an obstacle.
The work crosses a system boundary and can live outside the org, where retry and error handling are worth the name and a non-admin can read it.
Daily API allowance is sharedEvery integration draws on the same pool. Audit what already consumes it before adding another.
Volume needs the Bulk API, or genuine push rather than polling, which platform events provide.
Existing automation collidesLegacy triggers, Flows and managed packages can fire on the records you are writing to, in an order that is not obvious. A recursion or a silent overwrite found in production is expensive; an hour mapping what already fires is not.
Leads need capture, deduplication and routing from every inbound source, with the assignment rules made legible.
Sandboxes are not productionRefresh cycles, data masking and missing configuration mean a clean sandbox test is necessary but not sufficient. Plan a parallel run regardless.
You are migrating in, with field mapping signed off and a dry run against a sandbox.
Deployment is a process, not a copyChange sets or a proper pipeline, with someone accountable. This is a real cost line on a Salesforce project and it is routinely left out of quotes.
The integration runs as a deliberately configured service account rather than as somebody's administrator login.
Field-level security catches out integration usersAn integration that works as an administrator and fails as a service account is almost always this.

The most common failure pattern is cross-system logic implemented as a sprawl of Flows calling outbound messages, with no single place to see what happens when one of them fails. When one fails, nobody can trace where.

No commercial relationship

We hold no reseller agreement with this vendor, take no affiliate commission, and do not resell licenses. You buy your own subscription directly. It is the only arrangement under which our recommendation means anything.

Not sure what your org is already doing?

Scoping maps what fires on which records and where the cross-system logic actually lives before anything new is added. It is free, and you keep the proposal.

You will talk to Fayez or Kareem. Nobody else.