Salesforce and CodeWords: working with the platform, not against it

Salesforce is the one platform in this series where the automation question is genuinely complicated, because Salesforce already has four generations of automation inside it. Workflow rules, Process Builder, Flow, and Apex all exist, several are deprecated, and most orgs of any age contain a sediment of all of them, some of which nobody can explain.

So the first question is not what to automate. It is what is already running, because adding external automation to an org where three things already fire on contact creation is how you get a record that updates four times and a support ticket nobody can diagnose.

What we'll cover

• Find out what already runs
• Governor limits, which shape everything
• What the Salesforce API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Bulk operations that do not fail halfway
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Find out what already runs

Before building anything, inventory what fires on the objects you intend to touch.

Flows are the current mechanism and where new automation should go if it belongs inside Salesforce at all.

Process Builder and Workflow Rules are the previous generations. Salesforce has been retiring them, and many orgs still run them, frequently doing something nobody has read in years.

Apex triggers are code, and they may be doing things no declarative inspection will reveal.

Validation rules reject writes, which is how an external automation discovers a required field it did not know about.

Managed packages bring their own automation, and it is not always visible or modifiable.

The order of execution across all of these is defined and intricate, and it is the reason a change that looks simple produces an unexpected result. An afternoon inventorying this is the cheapest hour in the whole project.

Governor limits, which shape everything

Salesforce runs your logic on shared infrastructure, and it enforces that by capping what any operation can do. This has consequences for external automation too, mostly through API limits.

API request limits are per org per rolling day, and they are shared with every other integration you have. An automation making one call per record across fifty thousand records can consume a meaningful share of the daily allowance on its own.

Bulk operations exist precisely for this. The bulk interfaces process records in batches rather than individually, which is both faster and dramatically cheaper in API calls.

Your automation can trigger theirs. A record updated by your automation fires whatever Flows and triggers are configured, which consume their own limits and may cascade. This is the most common surprise: an external update that works fine for ten records fails at scale because it set off something inside the platform.

Watch the consumption. The API usage figure is visible, and an automation that quietly consumes most of the daily allowance will be discovered by whichever integration fails first, which is rarely the one responsible.

What the Salesforce API reaches

REST and SOAP APIs cover records across standard and custom objects, with create, read, update, delete, and upsert.

Bulk API handles large volumes asynchronously in batches, which is what anything touching thousands of records should use.

SOQL queries records, and SOSL searches across objects.

Composite requests bundle several operations into one API call, which is a straightforward way to reduce consumption.

Platform Events and Change Data Capture push changes outward, which is far better than polling for anything reactive.

Metadata API reads and writes configuration, which is how you inventory what automation exists.

Upsert on an external ID is the single most useful capability for integration work, because it makes writes idempotent without a lookup first.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, naming the objects and fields involved.
3. Authorize the connection through OAuth, using an integration user with a permission set scoped to what the automation needs rather than an administrator's own login.
4. Describe the exceptions: a validation rule rejection, a duplicate match, a required field the source data does not have.
5. Test in a sandbox with realistic data volumes, because behaviour at ten records tells you nothing about behaviour at ten thousand.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Enrichment from systems Salesforce cannot see. Product usage, support history, billing status, written onto accounts and contacts. The highest-return integration, because everything in the platform becomes more capable once these fields are reliable.

Reconciliation against billing. Accounts in Salesforce with no billing record, customers billing with no Salesforce account, and where the two disagree on status. Report rather than resolve.

Stale pipeline reporting. Opportunities with no activity beyond a threshold, reported to owners and managers as a list. Most forecast inaccuracy is stale opportunities nobody closed out.

Duplicate detection. Probable duplicates by domain and fuzzy name, reported for a person to merge. Never merged automatically, because a wrong merge in Salesforce loses history irreversibly.

External document and contract linking. Signed agreements, proposals, and delivery documents attached to the right record from wherever they actually live.

Activity reporting from reality. Meetings and emails that genuinely happened, pulled from calendar and mail rather than from what somebody logged.

Automation inventory reporting. What Flows, triggers, and legacy processes exist per object, which is the report every inherited org needs and almost none have.

Bulk operations that do not fail halfway

The characteristic failure of Salesforce integration is a job that processes fine for a while and then stops.

Use the Bulk API for anything above a few hundred records. Record-at-a-time processing consumes API calls linearly and is the main cause of exhausted allowances.

Expect partial success. A bulk job returns per-record results, some of which will have failed validation. An automation reading only the job status and not the per-record results silently drops those records.

Handle validation rejections as data problems. A record rejected for a missing required field is telling you something about your source data, and it belongs on an exception report rather than in a retry loop, since it will fail identically every time.

Batch size matters. Very large batches are more likely to hit limits inside the platform, particularly where triggers fire per record. Moderate batches are more reliable than maximal ones.

Upsert on an external ID rather than query-then-write. It halves the API calls and makes the operation naturally repeatable, which matters when a job has to be restarted.

Schedule heavy jobs outside business hours, since they compete with users for the same limits.

Building it so it survives

Make it safe to run twice. Upsert on an external identifier is the mechanism, and it is worth designing your external ID field before writing anything.

Never let an automation merge or delete records. Both are irreversible in ways that lose history, and both should be a person's decision with the evidence in front of them.

Use an integration user. A named integration user with a scoped permission set survives people leaving and makes the audit trail legible. An automation acting as a departed administrator is a problem waiting for an offboarding.

Log what was written and why. Salesforce records change frequently and from several directions, and the question of what changed a field is otherwise genuinely hard to answer.

Report the outcome. Records processed, failed, and skipped, daily. Bulk failures are invisible without this.

Limits worth knowing about

Daily API request allowance is per org and shared across every integration, which makes one badly written automation everybody's problem.

Governor limits apply inside the platform, so your external write can fail because a trigger it fired exceeded a limit, which produces an error that appears to be about something else entirely.

Validation rules and required fields reject writes, correctly, and an integration built against a sandbox with different rules will meet them in production.

Field-level security applies to the integration user, so a field the automation cannot see appears simply absent rather than forbidden, which is confusing to debug.

Sandbox refreshes change data and sometimes configuration, so a test that passed last month proves less than it appears to.

What to build first

The automation inventory, read-only: what Flows, triggers, validation rules, and legacy processes exist on the objects you care about. It needs read access only, it takes an afternoon, and in most inherited orgs it finds automation nobody knew was running — which is both immediately useful and the prerequisite for building anything safely.

Two habits make the difference. Test at realistic volume in a sandbox, because Salesforce behaves differently at ten thousand records than at ten. And report what your automation wrote, since a record with five things updating it needs an audit trail to be comprehensible at all.

Frequently asked questions

Should I use Flow or an external automation?

Flow for anything that belongs inside Salesforce and only touches Salesforce data — it is native, declarative, and visible to your administrators. Reach outside when the logic needs systems Salesforce cannot see, when the volume would consume governor limits, or when the process spans several systems where Salesforce is one participant rather than the centre.

Why does my integration fail at scale but work in testing?

Almost always governor limits fired by the platform's own automation. Your write triggers Flows and Apex, those consume limits per transaction, and a batch that works at ten records exceeds them at two hundred. Reduce batch size and check what fires on the object.

How do I avoid consuming the whole API allowance?

Use the Bulk API, upsert on an external ID rather than query-then-write, bundle with composite requests, and prefer Platform Events over polling. Most allowance problems are one automation making a call per record when a bulk job would have made a handful.

Can automation merge duplicate records?

It should not. Merging is irreversible and loses history, and fuzzy matching is confidently wrong often enough that this is not theoretical. Report probable duplicates with the evidence and let a person decide.

What permissions should the integration have?

A dedicated integration user with a permission set granting exactly the object and field access required. Not an administrator, and not a real person's account, which carries their whole access footprint and breaks when they leave.

How do I stop my automation fighting existing Flows?

Inventory what runs on the object first, then decide explicitly which system owns which field. Two automations both writing a status field will produce a record that flips, and the eventual diagnosis is expensive because the order of execution is not obvious.

Should it write to standard or custom fields?

Custom fields for anything the automation owns, clearly named so it is obvious the value is derived rather than entered. Writing into standard fields people also edit is how you overwrite somebody's work and lose their trust in the data.

Should we test against a sandbox?

Yes, and know which kind you have. A full sandbox carries data and is refreshed rarely; a developer sandbox carries configuration and almost no data. An automation tested only against an empty sandbox has not met the volume, the duplicates, or the half-populated records that production holds.

Why did records fail to save with no obvious error in our code?

Usually validation rules, required fields, or a trigger further down the chain rejecting the change. Salesforce enforces configuration that your automation cannot see, which is the argument for inventorying what already runs on an object before writing to it.

What permissions should the integration user have?

Its own user, with a profile granting access to the specific objects and fields it needs, and nothing else. A shared administrator login makes it impossible to tell what an automation did, and impossible to revoke one thing without disrupting others.

Related reading

• Freshsales and CodeWords
• CodeWords integrations and templates