Everything we actually do when we implement, configure, and connect a Salesforce org, written out in full. Platform architecture and objects, Sales Cloud and Service Cloud setup, custom development with Apex and Lightning, Flow automation, data migration, integrations with the rest of your stack, reporting, and driving real adoption. No generic best-practice platitudes. The actual method.
Salesforce is sold as a platform that does everything out of the box. It does not. The default configuration fits almost no real business, and the gap between what ships and what your team actually needs is exactly where implementations fail. This guide covers the gap in full: how the platform is structured, how we model data, how we automate without creating a maintenance nightmare, how we migrate cleanly, and how we connect the rest of your stack without creating a fragile spaghetti of API calls.
Salesforce is a multi-tenant cloud platform built on a metadata-driven architecture. Everything you configure, from objects and fields to Flows and page layouts, lives as metadata in your org. That is what makes deployments and version control possible: you are moving metadata between sandboxes and production, not code in the traditional sense.
The platform divides into clouds, each targeting a different part of the business. The two you will most commonly implement are Sales Cloud, which manages pipeline, accounts, contacts, opportunities, and leads, and Service Cloud, which adds Cases, Omni-Channel routing, a knowledge base, and contact-centre tooling. They share the same underlying platform and can be combined in one org.
Above the clouds sits your customisation: the custom objects and fields that model your specific business, the automation layer (Flow and Apex), the UI layer (Lightning page layouts and Lightning Web Components), and the integration layer that connects Salesforce to your other systems. Getting the sequence right matters because decisions made at the data model layer cascade upward through every other layer.
Every engagement begins with an audit because the state of an existing org (or the requirements for a new one) determines everything downstream. For existing orgs we connect via a read-only Connected App and run a structured health check. For new implementations we run a requirements workshop before touching the platform.
The audit covers five areas:
The output is a prioritised roadmap. Every item has the business impact quantified, the effort to fix it, and whether it can be addressed declaratively or needs development. You receive this before any contract is signed.
The object model is the foundation. If you get it wrong, you end up with workarounds layered on workarounds, reports that require complex SOQL to be useful, and automations that break whenever the data changes shape. This is where most underspecified implementations go wrong.
Salesforce provides standard objects for the most common entities: Account, Contact, Lead, Opportunity, Case. These are fine starting points. The question is when to extend them versus when to build a custom object. The rule of thumb is straightforward:
Relationships between objects in Salesforce are either lookup (soft, the child can exist without the parent) or master-detail (hard, deleting the parent deletes the child, rollup summaries are possible). Choose incorrectly and you cannot run the rollup reports you need, or you lose data when parent records are merged or deleted. We document the relationship type and the cascade-delete behaviour for every relationship we create, because it affects how you can query and what happens at scale.
A well configured Sales Cloud setup eliminates the friction between how your team sells and what the system expects of them. The biggest friction point in almost every default setup is the lead lifecycle: how a new name becomes a qualified contact and when it becomes an opportunity.
We approach Sales Cloud setup in four pieces:
Lead routing assigns new leads to the right rep, territory, or queue. Lead scoring (via custom fields, scoring rules, or a connected marketing automation platform) surfaces the leads worth calling now. Conversion maps lead fields to the Contact, Account, and Opportunity that result from it, so none of the original context is lost. Most default setups lose data at conversion because the field mapping was never configured.
Opportunity stages have to reflect how the team actually closes deals, not a generic sales methodology. We interview the team, map the real stages to the probability figures Salesforce uses for forecasting, and write entry and exit criteria for each stage so the forecast is meaningful. A pipeline with arbitrary stage labels produces forecasts nobody trusts.
Collaborative Forecasting in Sales Cloud can aggregate expected revenue by rep, manager, and product family in real time. Getting this right requires the stage probabilities to be calibrated, the hierarchy to match the real reporting structure, and quota records to be loaded. It is rarely set up correctly out of the box because it requires both configuration and data to be in place simultaneously.
Reps will not log calls and emails manually at scale. Einstein Activity Capture or a third-party tool like Ebsta or Groove can sync email and calendar from Gmail or Outlook automatically. The tradeoff is data volume and storage costs. We configure this with retention policies that keep the data useful without blowing up your storage bill.
Service Cloud is built around Cases: the unit of work for a support request. The configuration questions are how cases arrive, how they are routed, how the team works them, and what the customer sees.
Cases can originate from email-to-case, web-to-case forms, phone calls (via CTI integration), chat, social, and self-service portals. Each channel has different setup requirements and different data enrichment possibilities. We configure the channels your team actually uses first, then add complexity from there.
Omni-Channel routes work items (cases, chats, calls) to agents based on availability, capacity, and skill. The routing model needs to reflect how your team is actually staffed. A routing configuration written for an idealised team structure that does not match reality will queue cases in the wrong buckets from day one.
Entitlements define what support a customer is owed and by when. Milestones define the actions that must happen within those SLAs. This is one of the most underused features in Service Cloud, because setting it up correctly requires your support contracts to be mapped and your escalation logic to be agreed. When it is configured, Salesforce surfaces which cases are at risk of breaching SLA in real time, which is the only way to manage a support team proactively rather than reactively.
Automation is where the real productivity gains come from. It is also where most of the technical debt accumulates, because automation added over time without a governing design pattern becomes impossible to understand or maintain.
The most common mistake we see in Flow is a single Flow that tries to do everything triggered by a record change. It starts with two decision nodes and grows over three years into something nobody understands. We separate concerns: one Flow per process, each Flow doing one job, each documented with a description field that says what it does and when it was last reviewed. Flow versions accumulate quickly; we activate only one version per Flow and clean up inactive versions during the engagement.
Salesforce enforces governor limits to protect the shared infrastructure from runaway processes. The most commonly hit limit is the SOQL query limit (100 queries per transaction) and the DML limit (150 statements per transaction). Apex that queries inside a loop hits the SOQL limit almost immediately at any real data volume. We write all Apex with bulkification in mind from the start: queries outside loops, collections processed as sets. Flow is also subject to limits, though the limits are different and the platform handles more of the bulkification automatically in recent releases.
Data migration is the step most implementations underestimate. The work is not moving records; it is deciding what to move, cleaning it before it arrives, and verifying it after. Bad data migrated into a fresh org corrupts every report, every automation, and every integration downstream.
Salesforce's Duplicate Management uses matching rules to identify near-duplicates before they are created and duplicate rules to block or alert on them at save time. This prevents future duplicates but does nothing about existing ones. We run the Data Quality Analysis Dashboards or a dedicated tool (DemandTools, CRMFusion) to surface the existing duplicate set, then work through a merge strategy: automated merges for high-confidence pairs, manual review queue for ambiguous cases, and a survivor rule that defines which fields from which record win when merging.
Source data fields rarely map cleanly to Salesforce fields. Picklist values differ, phone numbers are in different formats, addresses need splitting, and related records need to be resolved to Salesforce IDs. We document every transformation in a migration spec before writing a single line of code, and we validate the spec against a sample load before running it at full volume.
Salesforce rarely lives in isolation. The question is not whether to integrate but how, and the answer is different depending on the volume, latency, and criticality of the data flowing across the connection.
The options, in order of increasing complexity and maintenance cost:
For real-time integrations where latency matters, Salesforce Platform Events let external systems subscribe to changes in the org without polling. Change Data Capture publishes changes to Salesforce records as events, which downstream systems can consume reliably without querying the API on a schedule. We use these patterns for high-frequency, low-latency scenarios like order status updates or case escalation notifications.
The default Salesforce reports are a starting point, not a finished product. The reports your team actually uses have to be built from the data your team actually tracks, displayed at the access level of the person reading them, and embedded in the workflows they are already in.
We approach reporting in three tiers:
The most complete implementation fails if the team does not use it. Adoption is not a training problem; it is a design problem. If the system is harder to use than the spreadsheet it replaced, people will use the spreadsheet.
The decisions that drive adoption are made in the design phase, not the training phase:
Training covers the mechanics, but what actually lifts adoption is the combination of a well-designed system, a go-live moment with clear messaging about what changed and why, and a named person to call when something looks wrong. We schedule a go-live call, a two-week check-in, and a four-week retrospective as part of every engagement.
Every engagement is fixed scope and fixed price. The scope is written before any work starts, based on the free audit findings, and nothing expands without a signed change order.
We run implementations in three phases with clear handover points:
One point of contact. You get one person who owns the relationship, the delivery schedule, and every escalation. Specifications arrive with acceptance criteria your team can check against. All source documents, data maps, and migration scripts are yours to keep at handover.
A short, honest list of the things we will not do, because they waste money:
That is the full method. When you want it applied to your org, the next step is a free audit: a real health check against your live org, with a prioritised roadmap, in about a week, with no obligation.
A free health check on your real Salesforce data, the findings quantified, and a fixed scope to fix what matters. Findings in a week.
Get a free Salesforce audit