Salesforce can model almost any sales process. That’s its strength, and in smaller orgs it’s often the problem. Each admin, consultant and AppExchange package adds a little more: another record type, a few fields, a flow that “just handles one edge case.” Three years later the org has 400 fields on the Lead object, automation spread across tools Salesforce no longer supports, and a sales team that exports reports to spreadsheets because they don’t trust the dashboards.
We work on the layer between the configuration and the business: how leads become customers, what rules move them, who owns them, and whether the data underneath is good enough to report on.
What we do and what we don’t
Being clear about this saves everyone time.
The orgs we help most are small to mid-sized: one or a few business units, a part-time or overloaded admin, and a sales and marketing process that has outgrown its original setup.
Why doesn’t our lead lifecycle match reality?
Usually because Lead Status is doing three jobs at once. In many orgs it tracks sales activity (“Attempted contact”), qualification (“MQL”, “SQL”) and outcome (“Unqualified”) in a single picklist, with values added by different teams over the years. Reps pick whatever is closest, and no report can say how many marketing-qualified leads came in last quarter.
We separate the concepts. Lead Status describes where sales is with the lead. A lifecycle or qualification field records the business state, set by defined rules rather than by whoever edits the record last. Lead conversion then becomes a real decision point, with the lead fields mapped properly to the contact, account and opportunity so qualification answers aren’t lost the moment a lead is converted.
If you also run Marketing Cloud Account Engagement (formerly Pardot), the scoring, grading and sync rules need to agree with that model too, or marketing and sales will report two different funnels from the same data.
What happened to Workflow Rules and Process Builder?
Salesforce ended support for Workflow Rules and Process Builder at the end of 2025, and Flow is now the place to build declarative automation. Existing rules and processes may keep running, but they no longer get fixes, and any new automation belongs in Flow.
Migration is a good moment to clean up rather than translate one-for-one. We often find a workflow rule, a process and a flow all updating the same field on the same object. The Migrate to Flow tool can convert simple items, but it can’t tell you which of the three should exist. We inventory automation per object, decide what each piece is for, and consolidate it into a small number of record-triggered flows with clear entry conditions. Fast field updates go in before-save flows, actions that touch other records go in after-save flows, and every flow gets a description that says what business rule it implements.
Why are leads going to the wrong owner?
Most often because the rule entries in your lead assignment rule are in the wrong order, or because some leads never run through the rule at all.
Salesforce allows one active lead assignment rule, with entries evaluated in order until one matches. An entry for “Country equals United States” placed above “Employees greater than 1,000” means a large US company goes to the regional team, not the enterprise rep, even though the second entry describes it better.
Then there are the leads that skip routing. Web-to-lead and manual entry can apply the active rule, but records created by imports, form tools or integrations only run it if they’re set up to request it. A lead from a webinar platform arrives owned by the integration user and sits there. Round-robin distribution and matching new leads to existing accounts also aren’t something assignment rules do natively, so teams patch them with flows, queues or AppExchange tools.
We trace every source that creates leads, confirm how each one triggers assignment, add queues and fallback ownership for anything unrouted, and alert someone when a lead goes unworked past your response target.
Find out where your Salesforce org is leaking leads
We trace every lead source, assignment rule entry and flow, then show where records skip routing or lose data.
When do record types help, and when do they hurt?
Record types are useful when two processes are genuinely different: new business and renewal opportunities with different stages, or partner leads that follow a separate path. Each record type can have its own page layout, picklist values and sales process.
They hurt when they multiply for small differences. Each record type adds layouts, picklist assignments and branches in every flow and report. We usually reduce them to the few that represent real process differences, and use fields and Dynamic Forms for the rest.
Data quality you can maintain
Duplicates in Salesforce are controlled by matching rules (how records are compared) and duplicate rules (what happens when a match is found: block, alert or allow and report). Many orgs have the standard rules switched on and never reviewed, so integrations create duplicates freely while users get blocked on legitimate entries.
We tune those rules, add validation rules for the fields reports depend on, standardize picklists, and run a one-time cleanup for existing duplicates. The bigger win is usually upstream: fixing the integration or import that keeps creating bad records. See CRM data cleanup for how we approach it.
Integrations
Salesforce rarely stands alone. Marketing automation, billing, support, product usage and enrichment tools all write to it. We define which system owns each field, how records are matched, and what happens on conflict, then implement through native connectors, AppExchange packages, workflow tools or Salesforce’s APIs. For API-level builds that need custom code inside Salesforce, we write the specification and work alongside your developer. More on our approach in CRM integration.
How a Salesforce engagement runs
Audit the org
We review objects, fields, record types, automation, assignment, duplicate rules and reports, and trace two or three real leads from creation to closed opportunity. This is our CRM audit, adapted for Salesforce.
Agree the lifecycle and rules
We document the states, transitions, ownership rules and exclusions in plain language before changing configuration. Larger changes start with requirements documentation.
Build and consolidate in a sandbox
Changes are built and tested in a sandbox, including flow consolidation and assignment rule changes, then deployed in planned releases.
Validate with real records
We test edge cases (existing customers, missing fields, integration-created leads) and check that reports reflect what happened.
Do you write Apex or build custom Lightning components?
No. We work with declarative tools: Flow, assignment rules, validation and duplicate rules, record types, layouts and reports. When something genuinely requires code, we write the requirements and work with your developer or partner.
Should we migrate Workflow Rules and Process Builder to Flow?
Yes. Salesforce ended support for both at the end of 2025. Treat migration as a consolidation exercise: decide what each automation is for, remove duplicates, and rebuild as fewer, well-documented flows.
Can Salesforce do round-robin lead assignment?
Not with lead assignment rules alone. Round-robin is typically built with Flow, queues and a counter, or with an AppExchange routing tool. The right option depends on volume and how complex your rules are.
Do you work with Marketing Cloud Account Engagement?
We work on how Account Engagement connects to the Salesforce lifecycle: scoring and grading thresholds, the handoff to sales, field sync and campaign attribution. We’re not a specialist Marketing Cloud Engagement implementer.
Is our org too large for you?
Possibly. We’re a good fit for small and mid-sized orgs. If you have many business units, complex territory management or heavy custom development, a larger Salesforce consultancy may suit you better, and we’ll tell you if so.