Salesforce implementation
Salesforce, architected — not just configured.
aibrevo implements Salesforce for companies that have outgrown a standard setup: custom objects, Apex triggers, Flow and Bulk/REST API integrations, designed around your data model rather than bolted onto it. Typical projects run 8 weeks to 6+ months depending on migration and integration scope.
Who this is for
RevOps and IT leaders at 200+ employee companies who need Sales Cloud, Service Cloud or CPQ built to a real specification — and documented so an internal admin can own it.
What we implement in Salesforce
Data model & schema
Objects, relationships, record types, page layouts and sharing rules designed for how you actually sell — not the default Opportunity/Contact/Account shape with fields bolted on until it fits.
Automation
Flow, Apex triggers and scheduled jobs, built bulk-safe from the start: batched DML instead of per-record loops, governor limits respected, and clear ownership of which automation fires on which object so two flows don't silently fight each other.
Integrations
REST/Bulk API and middleware connections to billing, product, marketing and support systems — with retry logic, error logging and a defined system of record for every field that lives in more than one place.
Migration
Data mapping, de-duplication and history preservation from spreadsheets or a legacy CRM, staged through a sandbox before a single record touches production.
Reporting
Report types, dashboards and forecasting that leadership will trust — built on report types that expose the right cross-object relationships instead of forcing analysts into custom SOQL for basic questions.
Handover
Admin documentation, a deployment pipeline and training for your internal team, so changes after go-live go through the same sandbox-to-production process as the original build.
Security & sharing model
Role hierarchy, profiles, permission sets and field-level security mapped to your actual org chart and data-sensitivity requirements — designed before go-live, not patched in after someone reports seeing data they shouldn't.
Sandbox strategy & release management
A defined chain of sandboxes (Developer, Partial Copy or Full depending on edition) with changes tracked in version control and deployed via change sets or a CI pipeline, so production is never edited directly.
AppExchange package evaluation
Vetting third-party managed packages against your actual data model before installation — checking for unmanaged dependencies, license-cost-per-user implications, and whether a package's own objects will need the same sandbox and security-model discipline as anything we build natively.
Change management & adoption
A rollout plan that accounts for the humans, not just the org — role-specific training, a feedback channel during the first weeks of live usage, and a defined process for triaging 'this field is confusing' reports before they calcify into workarounds that corrupt the data model.
A typical Salesforce project timeline
Phase proportions are typical, not a guarantee — actual timing depends on data volume, integration count and how much of the data model is custom.
- Weeks 1–2
- Discovery: current-state audit of any existing org, data-model design sessions with RevOps and sales leadership, and a written specification for objects, record types and sharing model before any configuration starts.
- Weeks 3–6
- Configuration and automation build in a sandbox — Flow and Apex development, page layouts, validation rules — running in parallel with data-mapping work for the migration, so the team building automation and the team cleaning source data aren't blocking each other.
- Weeks 7–9
- Integration build against billing, marketing and support systems, plus the actual data migration into a full or partial-copy sandbox for realistic-volume testing — this is typically where governor-limit and bulkification issues surface, while they're still cheap to fix.
- Weeks 10–12
- User acceptance testing with real end users (not just admins), report and dashboard validation against live-like data, a staged production deployment, and go-live followed by a monitored support window. Enterprise multi-cloud projects extend this same shape over several additional months rather than compressing it.
Common Salesforce projects
- Sales Cloud implementation for a growing enterprise
- Salesforce CPQ configuration and quote-approval flows
- Salesforce-to-Salesforce or legacy-CRM migration
- Rescuing an underperforming rollout — data model rebuild
- Marketing automation and Salesforce integration
Where Salesforce projects go wrong
Customizing before understanding the limits
Teams build dozens of triggers and workflows before hitting governor limits or record-lock contention — then have to unwind automation that was never bulk-safe to begin with. A single unbulkified trigger that works fine on 10 test records can throw a hard limit error the first time someone imports 500.
One giant object for everything
Cramming unrelated processes onto the Opportunity object with 80+ custom fields instead of modelling separate objects makes page layouts unusable and reporting unreliable — every new requirement becomes three more fields on a record type nobody can read anymore.
Treating profiles and permission sets as an afterthought
Sharing rules and field-level security get patched in late, so users either see data they shouldn't or hit silent permission errors that look like bugs. Untangling a security model after 200 users are already live is a much bigger project than designing it up front.
Ignoring the role hierarchy when it would solve the problem
Teams build complex, hand-maintained sharing rules for visibility that the standard role hierarchy would have handled automatically based on org structure — adding ongoing maintenance overhead for a problem Salesforce already solves natively.
Apex test coverage without real assertions
Code gets written to satisfy the 75% test-coverage requirement for deployment without asserting the logic actually does what it should, so the tests pass but provide no real safety net — the first time someone changes the trigger, nothing catches the regression.
No user-adoption plan behind the technical rollout
The org ships correctly configured and the reps still go back to spreadsheets a month later, because nobody owned the change-management side — training happened once, in a single session, with no feedback loop for the questions that only surface once people are using it daily.
Formula and rollup fields with circular or unbounded dependencies
A formula field references another formula field that references a roll-up summary back on the same record chain, and the org either throws a deployment error or silently returns blank values under specific record states — usually discovered by a user, not by testing.
What does Salesforce implementation cost?
Salesforce implementation costs in 2026 typically run $15k–$150k for most organizations: small orgs under 50 users land around $15k–$40k, mid-size multi-cloud deployments run $40k–$75k, and enterprise builds with custom development and multi-department rollouts can exceed $100k (folio3.com, 2026 cost breakdown). Licenses typically run 20–30% of first-year cost and implementation services 40–50%, with Sales Cloud Enterprise licensing around $165/user/month and independent consulting rates commonly $100–$300/hour for US and Western-market partners. We quote per project after a 30-minute call rather than a per-seat formula, since integration count and data-model complexity move the number more than headcount does.
Certified across the platforms we implement
- salesforceCertified engineers
- HubSpotCertified engineers
- Dynamics 365Certified engineers
- ZohoCertified engineers
- PipedriveCertified engineers
- monday.comCertified engineers
- AirtableCertified engineers
- GoHighLevelCertified engineers
Our engineers hold certifications on all eight platforms we deliver. We work as an independent implementation firm — no reselling, no white-label, no offshore hand-off.More about the team →
Certifications, and what they actually mean
A Salesforce Administrator or Platform Developer certification confirms someone has passed a proctored exam on the platform's declarative tools, data model and security framework — it's a real, useful baseline, but it's not the same thing as architecture judgment earned by building and living with orgs at scale. Plenty of certified admins have never designed a sharing model for 500 users or debugged a governor-limit failure under real production load. What actually matters on a project is the combination: certification as evidence of foundational knowledge, plus a track record of specific project types (multi-cloud, CPQ, complex integrations) similar to yours. When evaluating any Salesforce partner, ask what they've built, not just what exams they've passed — and ask to see how they structure a sandbox pipeline and a security model, since those two things separate a person who can configure Salesforce from one who can architect it. It's also worth distinguishing free Trailhead badges from Salesforce's proctored, paid certifications — Trailhead is genuinely useful for learning the platform's concepts, but badges don't require passing a timed exam under exam conditions the way an Administrator, Platform Developer or Certified Technical Architect credential does, and the two get conflated in marketing copy more often than they should. The CTA credential in particular sits well above the others — it requires defending an architecture in front of a review board, not just passing a multiple-choice test, and very few consultants hold it.
How to tell if your Salesforce org needs a rebuild vs. a fix
Not every Salesforce problem calls for tearing the org down and starting over — most don't. The signals below distinguish a targeted fix from a structural rebuild.
Signal it's a fix: one broken automation
A single Flow or trigger misbehaving under a specific edge case — a discount rule that doesn't apply correctly, a notification firing twice — is almost always isolated and fixable without touching the surrounding data model.
Signal it's a rebuild: the object model doesn't match the business
If core processes are jammed onto the standard Opportunity object with 80+ custom fields standing in for what should be separate objects, no amount of automation tuning fixes the underlying reporting and usability problems — the data model itself needs to change.
Signal it's a fix: reports are slow or a few numbers look wrong
Report performance issues or an isolated bad number usually trace to a specific report type or a stale field mapping — diagnosable and fixable in days, not a sign the whole org is broken.
Signal it's a rebuild: nobody trusts the reports at all
When leadership has quietly stopped using Salesforce dashboards because the numbers never seem to reconcile with reality, that's usually years of accumulated data-model and automation debt — a rebuild of the underlying structure, not a report tweak, is what restores trust.
Signal it's a fix: security errors for a handful of users
A few users hitting unexpected permission errors after a role change is a sharing-rule or profile adjustment, not evidence the whole security model is broken.
Signal it's a rebuild: the org was built without a sandbox strategy
If changes have always been made directly in production with no version control or deployment pipeline, every fix carries real risk — establishing a proper sandbox-to-production process is itself a structural project, not a quick patch.
Signal it's a fix: a single managed package is causing conflicts
An AppExchange package that clashes with a custom trigger or duplicates a field is usually resolved by reconfiguring or replacing that one package, without touching the rest of the org's architecture.
Signal it's a rebuild: dozens of overlapping Flows and Process Builders on the same object
When the same object has years of accumulated Process Builders, Workflow Rules and Flows firing in an order nobody can confidently explain, consolidating them into a deliberate, documented automation layer is a structural project rather than a series of individual fixes.
How Salesforce compares
Salesforce implementation — FAQs
Do you write Apex, or only use Flow?
Both. Flow first where it fits; Apex when the logic, performance or bulk requirements need it — always with test coverage and governor limits respected.
Can you take over a half-finished Salesforce org?
Yes. A large share of our Salesforce work is remediation: auditing the org, fixing the data model, rebuilding automation and cleaning reporting.
Are you a certified Salesforce partner?
Our engineers hold Salesforce Administrator and Platform Developer certifications. We work as an independent implementation firm, not a reseller.
Do you work in sandboxes with a real deployment pipeline?
Yes — changes are built and tested in a sandbox, tracked in version control, and deployed with change sets or a CI pipeline. We don't configure directly in production.
Can you support multi-cloud orgs (Sales Cloud plus Service Cloud or CPQ)?
Yes. Most enterprise engagements span at least two clouds; we design the shared data model first so the clouds don't fight each other over ownership of the same records.
What does a typical Salesforce project look like week by week?
Weeks 1–2 are discovery and data-model design; the middle stretch (roughly a third to half the timeline) covers configuration, automation and migration in a sandbox; the final quarter is integration testing, UAT with real users, and a staged production deployment before go-live and a monitored support window.
How does aibrevo scope a project differently than a generic quote?
A generic quote prices seats or a flat 'Salesforce setup' fee. We scope from your actual data model, integration count and migration volume after a working session — the same three factors that move a real Salesforce project from $5k to $150k, so the number reflects your project, not a template.
What's included in post-launch support?
30 days of monitoring and fixes after go-live are part of the project — watching automation for edge cases real usage surfaces, tuning reports leadership actually looks at, and admin questions from your team as they take over. Retained support beyond that is priced separately by hours per month.
How does Salesforce integrate with the billing, ERP and marketing tools we already run?
Through REST/Bulk API connections or middleware (MuleSoft, Zapier, or a custom integration layer depending on volume and reliability needs) to systems like NetSuite, QuickBooks, Stripe, Marketo or HubSpot — each integration is scoped with a defined system of record so the same field isn't edited independently in two places.
What happens if we need changes after the 30-day support window closes?
Most orgs need occasional changes — a new field, an adjusted validation rule, a report tweak. We offer retained support priced by hours per month for exactly that, or we document the change process well enough that a certified in-house admin can handle it directly; which one fits depends on whether you plan to hire an admin.
Why should we hire an implementation partner instead of just hiring a certified admin directly?
A full-time admin is the right call once you need ongoing day-to-day configuration changes at volume; a partner makes more sense for the initial architecture and build, where the risk of getting the data model and security design wrong is highest. Many clients do both — a partner for the build, then an in-house admin we train to own it afterward.
We already tried a Salesforce implementation once and it didn't work — can you fix that instead of starting over?
Yes, this is a large share of our Salesforce work. We audit the existing org first — data model, automation, security — and scope a remediation plan that fixes what's broken and keeps what isn't, rather than assuming a failed first attempt means a full rebuild is required.
How is aibrevo different from Salesforce's own professional services or a large SI?
We're a smaller, focused implementation firm — one team works your project end to end rather than handing off between a sales engineer, a solution architect and a delivery team you never spoke with during scoping. That usually means faster decisions and fewer people re-explaining your requirements to each other.
How long does a Salesforce data migration take and what usually slows it down?
Migration timelines depend on record volume, source-data quality and object complexity, and the delay is rarely the load itself. It's usually cleaning, de-duplication, deciding how history maps to Salesforce objects and resolving ownership. We run staged loads in a sandbox first, so surprises appear before production data is touched.
How much does a Salesforce license cost per user in 2026?
Per-user pricing in 2026 ranges from roughly $25/month on Starter up to around $500/month on the top Einstein 1 editions, with Sales Cloud Enterprise commonly around $165/user/month (per 2026 pricing guides). Licensing is usually only 20–30% of first-year cost — implementation services typically outweigh it, which is why the build quality matters more than the sticker price.
Is a Salesforce implementation cost mostly licenses or services?
Services usually cost more. Industry breakdowns for 2026 put implementation services at roughly 40–50% of total first-year cost and licenses at 20–30%, with the remainder going to integrations, data migration and training. A cheap license paired with an under-scoped build tends to cost more later, when the data model has to be redone.
Should we use Salesforce Flow or keep our old Process Builders and Workflow Rules?
Flow. Salesforce has been retiring Workflow Rules and Process Builder in favor of Flow, so anything still running on the older tools is technical debt with a deadline attached. We migrate them to Flow deliberately — consolidating overlapping automation per object rather than converting one-to-one — so the result is easier to reason about, not just newer.
Do you help choose AppExchange packages, or only build custom?
Both. A managed package is often cheaper than custom development for a commodity need, but it brings per-user license cost and its own objects into your security model. We evaluate packages against your actual data model before installation, and build custom only where a package would force you to bend the process around it.
Other platforms we implement
Scope your Salesforce project
A 30-minute call with an engineer. You leave with a written read on your current setup and a clear recommendation — whether or not you hire us.
Book a 30-min call