Core-X Solutions

Salesforce RevOps consulting

Salesforce will do almost anything you ask, which is the problem. After a few years of everyone asking, the org holds a decade of decisions nobody wrote down — and the reporting is unreliable for reasons that are all, individually, reasonable.

The five kinds of org debt

These are what we find, in roughly this order of frequency. None of them are anyone’s fault; all of them compound.

Automation nobody can trace
Workflow rules, process builders, flows and triggers all firing on the same object, built by different people over several years. A field updates and nobody can say which of the four did it. The order of execution is documented by Salesforce; what your org actually does is not.
Validation rules as archaeology
Rules added to stop one bad import in 2021, still blocking legitimate records today. Every one of them is a decision someone made for a reason that is no longer written down anywhere.
Fields that exist twice
Two custom fields holding the same fact because the second team could not find the first. Reports pick one, dashboards pick the other, and the numbers differ by however many records use the wrong one.
A sharing model grown by exception
Role hierarchy plus sharing rules plus manual shares plus a public group added for one project. Nobody is confident who can see what, so the safe answer becomes giving everyone more access than they need.
Picklists with no owner
Lead source with forty values, eight of which mean the same thing in different capitalisations. Attribution built on this is arithmetic performed on a mess.

Order of execution is not trivia

When a record saves, Salesforce runs things in a defined sequence: validation rules, before-save flows, before triggers, duplicate rules, after triggers, assignment rules, workflow field updates, then processes and after-save flows — and a field update can start the whole thing again.

Almost every “the automation is fighting itself” problem is this sequence: two pieces of logic writing the same field at different points, so the last one wins and which one is last depends on how the record was created. A record made by a rep behaves differently from the same record made by an integration, and both look correct in isolation.

The practical rule: one record-triggered flow per object per timing, with the branching inside it, rather than six flows that each seemed small when someone added it. Before-save for field updates on the same record — it is faster and avoids a second save entirely.

How we work an org

  1. 01

    Inventory the automation

    List every flow, trigger, workflow rule, process builder and validation rule per object, with what fires it and what it writes. Most orgs have never seen this on one page, and it is usually where the reporting problem turns out to live.

  2. 02

    Consolidate onto flows

    Workflow Rules and Process Builder are retired. Migrating is not optional forever, and doing it deliberately — one record-triggered flow per object, ordered — is far cheaper than doing it under a deadline.

  3. 03

    Fix the picklists and the identity

    Agree the values, map the old ones, enforce at the point of entry. Establish the external ID that other systems will key on before any integration is built against the org.

  4. 04

    Rebuild the sharing model

    From an agreed statement of who should see what, rather than by patching the current state. Field-level security matters here too — an integration user that cannot see a field writes nulls over real values.

  5. 05

    Report from outside the org

    Salesforce reporting is good at Salesforce data. The moment a question needs billing or ad spend alongside it, the answer belongs in a warehouse with Salesforce as one conformed source.

What we have done on Salesforce

Six of the engagements on our case studies page involve Salesforce. The ones most worth reading:

A B2B services group after two prior migrations had duplicate companies, contacts on the wrong parent, ownership that no longer matched the team, and campaign names that never agreed with the ad platform. We deduplicated on deterministic keys first and fuzzy matching second, with a documented survivorship rule, rebuilt ownership from an agreed source of record, and enforced campaign naming at entry. Duplicate rate went from 31% to 0.4% and stays there, because the validation runs nightly rather than as a cleanup project. Case study.

An inbound-led services business had enquiries landing in a shared inbox with no owner and no clock. Validation, enrichment and routing on rules the team agreed — territory, value band, current load — with an SLA timer and escalation on expiry. Median first response fell from ~2 hours to 4 minutes, with no leads unassigned overnight. Case study.

Also on Salesforce: £240k of pipeline surfaced from dormant records, every call classified and written back to the record, and four systems resolved to one customer view.

When you do not need us

If the work is entirely inside Salesforce — a new object, a set of flows, a permissions rebuild — a good Salesforce administrator or a certified partner will be faster and cheaper than us, and we will say so.

We are worth calling when the problem crosses the org boundary: Salesforce disagreeing with billing, attribution that needs ad spend joined to closed revenue, reporting that has outgrown what the org can answer, or an integration that keeps producing duplicates.

Start with the automation inventory

One page listing everything that fires on your core objects. It is the cheapest diagnostic there is, and it usually explains the reporting problem on its own.

Discuss a project

Have a messy system?

That is usually where we can help.

Tell us what is not working, what is still manual, or what you cannot currently see clearly. If it is not something we should take on, we will tell you that too.

hello@core-x.solutions