For teams on Salesforce
Salesforce gives you every control. Most orgs have them configured against each other.
The problems are rarely missing features. They are a lead-to-contact model that was never decided, duplicate rules that only alert, validation rules that break integrations, and opportunity history nobody can read.
Part of one fixed build: $7,500, 21 days, $2,500 back if it isn't running as scoped. Pricing details
Ask yourself
Three questions that usually expose it.
- When a rep converts a lead from a company you already sell to, what does Salesforce suggest?
- Which of your validation rules apply to integration users?
- Which source does your stage-velocity report read: opportunity history or a custom date field?
Failure modes
What breaks, and why.
| Failure | What you see | Root cause |
|---|---|---|
| Duplicates through lead conversion | Reps convert leads into new accounts instead of existing ones, and the account hierarchy fragments. | Conversion defaults to creating records. Without matching rules surfacing existing accounts, and training on attaching to them, each conversion can add a copy. |
| Duplicate rules that only warn | Rules exist, yet duplicates keep arriving through imports and the API. | Rules set to 'Allow' with an alert let integrations save duplicates anyway (an API client can acknowledge the alert and save). Only 'Block' stops them. Matching rules also need tuning to your data, not the defaults. |
| Validation rules that break the stack | An integration starts failing silently after an admin adds a 'required field' rule. | Validation rules fire on API updates too. Rules written for reps without bypass logic for integration users block syncs. |
| Leads landing with the wrong owner | Inbound leads sit with a queue or the wrong territory. | Only one lead assignment rule can be active and its entries evaluate in order. Whether records created by integrations or code run it depends on how they are created: the REST API applies the active rule by default, but Apex inserts need it requested explicitly. |
| Stage history no one trusts | Velocity and conversion reports disagree with what reps say happened. | Opportunity history tracks stage, amount and close date changes, but other fields need field history tracking, which has a per-object field limit. Reports built on the wrong source tell different stories. |
First 48 hours
What I check before changing anything.
- Lead and contact model: when leads are used, conversion settings (including whether validation applies to converted leads) and the unconverted-lead backlog
- Duplicate rules and matching rules per object: Allow vs. Block on create and edit, and which integrations save through alerts
- Validation rules and whether integration users can bypass them
- Lead assignment rule order, queues, and territory logic
- Opportunity stages, history and field history tracking on the fields reporting needs
- API consumption against your org's daily limit, by integration
Decisions we make with you
Tradeoffs, written down.
Leads or contacts-only
Leads give you a clean inbound funnel; a contacts-only model avoids conversion duplicates but changes how you report on unqualified demand. We choose based on your inbound volume and motion.
Block or alert
Blocking duplicates stops bad data but can stop a sync. We block on manual entry and route API duplicates to a review queue.
Sandbox first
Rules, flows and fields are built and tested in a sandbox and moved with a documented deployment, not edited live in production.
An org's opportunity counts per account looked low. Root cause: leads from one web form converted into new accounts because the matching rule compared exact account names. Changing the rule to normalized name plus website, and showing matches during conversion, stopped the fragmentation.
Want this checked on your own CRM first? Get a free one-page teardown, no call needed.
FAQ
Common questions.
Do you build in a sandbox or in production?
Rules, flows and fields are built and tested in a sandbox first, then deployed with a documented change list. Data cleanup runs in production in reviewed batches, after a full export.
Will new validation or duplicate rules break our integrations?
Each rule is checked against the integration users and API paths that touch the object. Integrations get bypass logic or a review queue where blocking them would stop a sync.
Our admin team owns the org. How do you work with them?
Changes go through them. I share the change list before each deployment, and they keep the final say on anything touching security, sharing or automation they maintain.
Can a Salesforce merge be reversed?
Not cleanly. Merged-away records can't simply be restored into their original state, so merges follow signed-off rules, run in batches of reviewed matches, and every affected object is exported first.
Will this eat into our API limits?
Bulk work is scheduled and batched to stay well inside your daily allocation, and I check current consumption by integration before running anything heavy.
Connected problems
The build fixes these as one system.
CRM data foundation
Duplicates are a symptom. The disease is uncontrolled record creation.
HubSpot
Most HubSpot problems come from a handful of platform behaviours nobody designed for.
Pipeline reporting
If two people can define 'pipeline' differently, your dashboard is an opinion.
Signal-based pipeline
Lead quality is a model, not a list.
Bring your org. We'll find the controls working against each other.
Book 20 minutes and bring the CRM up on screen. I reply within 1 business day.
Book a 20-min call