Salesforce practice
Salesforce consulting, implementation and staffing
We implement Salesforce, extend it with Apex and Lightning, connect it to the rest of your systems and place the administrators, developers and architects a program needs.
What organizations bring us
Salesforce implementations succeed when the data model, sharing model and process design match how the business works. They go wrong when those are designed by whoever is asking loudest. Over time orgs gather flows, Apex triggers, fields and permission sets with no clear owner, and every release becomes slower.
We start with process and data, apply the declarative tools first, add code where it is justified, and set up the release and governance model so the org stays maintainable.
How a Salesforce project runs, stage by stage
-
Requirements and design
Process mapping, data model, security model and user stories with business owners.
-
Configuration
Objects, fields, layouts, record types, flows and permission sets.
-
Customization
Apex and Lightning Web Components where declarative tools fall short.
-
Integration
APIs, events and MuleSoft connections to ERP, billing, marketing and data platforms.
-
Data migration
Cleansing, mapping, loading in dependency order and reconciliation.
-
Testing and deployment
Automated tests, user acceptance testing and scripted release.
-
Adoption
Training, role-based guides and a feedback loop after go-live.
-
Support and administration
Release readiness, backlog, health checks and managed support.
Area by area
What each area covers, what consultants do in it, what goes wrong, and the roles we place.
Clouds
The clouds share one platform but each has its own process and data design.
SALES Sales Cloud Leads, accounts, contacts, opportunities, products and price books, quotes, forecasting, territory management, activity…
- What it covers
- Leads, accounts, contacts, opportunities, products and price books, quotes, forecasting, territory management, activity capture and sales engagement.
- What we do on projects
- Design the lead-to-opportunity process and stages with sales leadership, build lead assignment and routing, configure forecasting hierarchies, and connect email and calendar. Align the account model (person accounts, account hierarchies, partner accounts) before loading data.
- Where projects go wrong
- Opportunity stages invented to satisfy a report. Forecast categories nobody trusts. Territory models changed after the data is loaded.
- Roles we staff
- Salesforce Sales Cloud consultant, Salesforce administrator, Salesforce solution architect
SERVICE Service Cloud Cases, entitlements and milestones, queues and Omni-Channel routing, Knowledge, Service Console, email-to-case, web-to…
- What it covers
- Cases, entitlements and milestones, queues and Omni-Channel routing, Knowledge, Service Console, email-to-case, web-to-case, messaging channels and CTI telephony integration.
- What we do on projects
- Define case types and escalation, set up Omni-Channel routing and capacity, build the Knowledge model and review workflow, and connect the telephony platform. Test with real agents on real cases, not scripted ones.
- Where projects go wrong
- Routing rules designed on a whiteboard that fail at peak volume. Knowledge articles with no owner. Case layouts that grew by request.
- Roles we staff
- Salesforce Service Cloud consultant, Omni-Channel and CTI specialist
EXP Experience Cloud Customer, partner and employee portals, Lightning Web Runtime and Aura sites, external user licenses, sharing sets and…
- What it covers
- Customer, partner and employee portals, Lightning Web Runtime and Aura sites, external user licenses, sharing sets and share groups, site authentication and search.
- What we do on projects
- Choose the licensing and sharing model first, since it determines what external users can see. Build pages from Lightning components, configure single sign-on, and load-test the site.
- Where projects go wrong
- Treating a portal as a skin on the internal org. Guest user access misconfigured. Sharing rules for external users added at the end.
- Roles we staff
- Salesforce Experience Cloud developer, Salesforce architect
MKT Marketing (Account Engagement and Marketing Cloud Engagement) Account Engagement (formerly Pardot): forms, scoring, grading, engagement programs and the connector to Sales Cloud. Ma…
- What it covers
- Account Engagement (formerly Pardot): forms, scoring, grading, engagement programs and the connector to Sales Cloud. Marketing Cloud Engagement: Contact Builder, data extensions, journeys, email studio and mobile.
- What we do on projects
- Agree lead lifecycle and scoring with sales, set up sync with the CRM, build journeys from the data model outward, and handle consent and preference management.
- Where projects go wrong
- Scoring models copied from a template. Sync rules that overwrite sales data. Consent stored in more than one place.
- Roles we staff
- Salesforce marketing automation consultant, email developer
REV Salesforce CPQ and Revenue Cloud Products, bundles, pricing rules, quotes, contracts, billing and revenue lifecycle management. Salesforce has announced…
- What it covers
- Products, bundles, pricing rules, quotes, contracts, billing and revenue lifecycle management. Salesforce has announced that CPQ is no longer sold to new customers, with Revenue Cloud as the direction. Confirm current terms with Salesforce.
- What we do on projects
- Document how the business actually prices (discount authority, bundles, renewals), model it in the product catalog, and decide whether an existing CPQ org should stay, be upgraded or move to Revenue Cloud.
- Where projects go wrong
- Rebuilding every legacy pricing exception. Underestimating the data work when moving between CPQ and Revenue Cloud.
- Roles we staff
- Salesforce CPQ or Revenue Cloud consultant, pricing analyst
Platform and development
The platform decides what is easy to change later. Declarative first, code where justified.
DATA Data model and security Objects, fields, record types, relationships, org-wide defaults, role hierarchy, sharing rules, profiles, permission se…
- What it covers
- Objects, fields, record types, relationships, org-wide defaults, role hierarchy, sharing rules, profiles, permission sets and permission set groups, field-level security.
- What we do on projects
- Build the data model from the business processes, set org-wide defaults to the most restrictive that works, use permission sets and groups instead of many profiles, and test sharing as real users.
- Where projects go wrong
- Fields added for every request. Profiles used for everything. Public read/write defaults that block a later tightening.
- Roles we staff
- Salesforce solution architect, Salesforce administrator
FLOW Flow and declarative automation Record-triggered, screen, scheduled and autolaunched flows, orchestrations, approvals, validation rules and formula fie…
- What it covers
- Record-triggered, screen, scheduled and autolaunched flows, orchestrations, approvals, validation rules and formula fields.
- What we do on projects
- Decide per requirement whether Flow, Apex or a validation rule is right, build flows with fault paths and bulk-safe logic, and document the order of execution.
- Where projects go wrong
- Many overlapping flows on one object. No fault handling. Process Builder and workflow rules left in place.
- Roles we staff
- Salesforce administrator, Salesforce Flow developer
APEX Apex development Triggers and handler frameworks, bulkification, governor limits, asynchronous Apex (queueable, batch, scheduled), callo…
- What it covers
- Triggers and handler frameworks, bulkification, governor limits, asynchronous Apex (queueable, batch, scheduled), callouts, unit tests with the 75 percent coverage requirement and meaningful assertions.
- What we do on projects
- Write trigger handlers that process records in bulk, keep SOQL and DML outside loops, design asynchronous work around limits, and write tests that assert behavior rather than just coverage.
- Where projects go wrong
- Logic duplicated between Flow and Apex. Tests written only to hit coverage. Hard-coded record IDs.
- Roles we staff
- Salesforce Apex developer, Salesforce technical lead
LWC Lightning Web Components Components, wire adapters, Lightning Data Service, events, Apex-backed components, Jest unit tests and the Lightning de…
- What it covers
- Components, wire adapters, Lightning Data Service, events, Apex-backed components, Jest unit tests and the Lightning design system.
- What we do on projects
- Build components from base components where possible, use Lightning Data Service for standard records, and write Jest tests for component logic.
- Where projects go wrong
- Custom components for things standard ones already do. Calls to Apex on every render.
- Roles we staff
- Salesforce LWC developer
INT Integration patterns REST and SOAP APIs, Named Credentials and External Credentials, Platform Events, Change Data Capture, External Services…
- What it covers
- REST and SOAP APIs, Named Credentials and External Credentials, Platform Events, Change Data Capture, External Services, Bulk API, callouts and outbound messages.
- What we do on projects
- Choose request/response, event-driven or batch for each integration, set up credentials securely, handle limits and retries, and monitor failures.
- Where projects go wrong
- Point-to-point integrations that cannot be traced. Credentials stored in custom settings.
- Roles we staff
- Salesforce integration developer, integration architect
DEVOPS Environments and release management Sandbox types, Salesforce CLI, scratch orgs, source tracking, unlocked packages, DevOps Center, CI/CD pipelines and met…
- What it covers
- Sandbox types, Salesforce CLI, scratch orgs, source tracking, unlocked packages, DevOps Center, CI/CD pipelines and metadata deployment.
- What we do on projects
- Move from change sets to source-driven development in version control, automate test runs and validation deploys, and agree branching and promotion rules.
- Where projects go wrong
- Production changes made directly. Sandboxes refreshed without a plan for test data.
- Roles we staff
- Salesforce DevOps engineer, release manager
Data, integration and operations
Most of the long-term value, and cost, is in data and integration.
MULE MuleSoft and API-led connectivity Anypoint Platform, system, process and experience APIs, API policies, DataWeave transformations, runtime management and…
- What it covers
- Anypoint Platform, system, process and experience APIs, API policies, DataWeave transformations, runtime management and monitoring.
- What we do on projects
- Design reusable APIs on top of back-end systems, secure and rate-limit them, and monitor flows. Pair MuleSoft with Salesforce when several systems need consistent customer or order data.
- Where projects go wrong
- Treating MuleSoft as a point-to-point tool. No ownership of API versions.
- Roles we staff
- MuleSoft developer, integration architect
DC Data Cloud (branded Data 360 by Salesforce) Data streams and ingestion, identity resolution, unified profiles, calculated insights, segments and activation to othe…
- What it covers
- Data streams and ingestion, identity resolution, unified profiles, calculated insights, segments and activation to other clouds and external channels.
- What we do on projects
- Choose which sources to ingest, define the identity resolution rules, build segments for activation, and manage consumption.
- Where projects go wrong
- Ingesting everything before deciding which questions it should answer. Costs from volume that nobody forecast.
- Roles we staff
- Salesforce Data Cloud consultant, data architect
MIGRATE CRM data migration Data Loader, Bulk API, external IDs, order of load for related objects, record ownership, duplicates, history and attac…
- What it covers
- Data Loader, Bulk API, external IDs, order of load for related objects, record ownership, duplicates, history and attachments.
- What we do on projects
- Profile and cleanse source data, map to the new model, load in dependency order with external IDs, and reconcile counts and sample records.
- Where projects go wrong
- Loading ownership wrongly, so users lose access. Duplicate accounts merged after relationships were built.
- Roles we staff
- Salesforce data migration consultant
ORG Org strategy and consolidation Single-org versus multi-org decisions, merging orgs after acquisitions, deduplication, shared services and governance.
- What it covers
- Single-org versus multi-org decisions, merging orgs after acquisitions, deduplication, shared services and governance.
- What we do on projects
- Assess each org against business unit needs, decide whether to merge, and plan the data and process alignment.
- Where projects go wrong
- Merging for the sake of tidiness without agreeing common process.
- Roles we staff
- Salesforce solution architect
ADMIN Administration and managed support User and permission management, release readiness (three releases a year), flow and field cleanup, reports and dashboar…
- What it covers
- User and permission management, release readiness (three releases a year), flow and field cleanup, reports and dashboards, health checks and enhancement backlog.
- What we do on projects
- Review each seasonal release for impact, manage the backlog with the business, remove unused fields and automations, and provide training.
- Where projects go wrong
- No one owning the org after go-live. Release notes read after the update reaches production.
- Roles we staff
- Salesforce administrator, Salesforce business analyst
Implementation and migration services
-
New implementation
Sales, Service or Experience Cloud implemented from requirements to adoption.
-
Migration from another CRM
Data and process migration from legacy CRM, spreadsheets or another Salesforce org.
-
Org health check and cleanup
Review of automation, security, data quality and technical debt with a prioritized plan.
-
Integration with ERP and billing
Customer, order and invoice data connected to SAP, Oracle, NetSuite or Dynamics.
-
Custom development
Apex, Lightning Web Components and APIs built to Salesforce platform patterns.
-
Managed support
Administration, release readiness and enhancements from an agreed backlog.
Common use cases
-
Lead to cash
Marketing leads route to sales, quotes feed contracts and orders, and invoices from ERP return to the account.
-
Case management with entitlements
Customers receive support levels according to contract, with escalation and knowledge reuse.
-
Partner portal
Partners register deals, access resources and see their own cases using Experience Cloud.
-
Customer 360
Data Cloud brings together profile, orders and service data for segmentation and personalization.
Delivery approach
- 1
Discover
Process, data, users, integrations and constraints.
- 2
Architect
Data model, sharing, automation approach and integration patterns.
- 3
Build in sprints
Configuration and code delivered in short cycles with demos.
- 4
Migrate and test
Data cycles with reconciliation, automated tests and user acceptance.
- 5
Deploy
Scripted release from version control.
- 6
Adopt and improve
Training, support and backlog planning.
What you receive
- Process and data model design
- Security and sharing design
- Configured and tested solution
- Integration designs and code
- Data migration plan and reconciliation reports
- Release pipeline
- Training materials
Consultants we place
Staffing is a separate engagement from project delivery. You can use either, or both.
-
Salesforce solution architect
Owns data, security and integration design.
- Sales/Service/Experience Cloud
- data model
- sharing
- integration patterns
-
Salesforce administrator
Configures and maintains the org.
- Flow
- permission sets
- reports
- release management
-
Salesforce developer (Apex and LWC)
Builds custom logic and components.
- Apex
- LWC
- SOQL
- testing
- governor limits
-
Salesforce business analyst
Translates process into requirements and user stories.
- Process mapping
- UAT
- training
-
MuleSoft developer
Builds and manages APIs.
- Anypoint
- DataWeave
- API policies
-
Salesforce DevOps engineer
Builds the release pipeline.
- Salesforce CLI
- CI/CD
- unlocked packages
- DevOps Center
Managed support options
- Administration and user support
- Seasonal release readiness (Salesforce ships three releases a year)
- Enhancement backlog with monthly planning
- Health checks: unused fields, flows, permission sets
- Integration monitoring
- Data quality and deduplication routines
Related technology
Listed as technologies we work with, not as vendor partnerships or certifications.
Questions people ask
Should we customize or stay with standard?
Standard first. Custom code adds maintenance, and Salesforce ships three releases a year. We use code where the process genuinely needs it.
Can you support an org someone else built?
Yes. We start with a health check to learn what exists and what is at risk.
Do you place Salesforce staff only?
Yes, if that is what you need. Staffing is separate from project delivery.
Is Data Cloud the same as Data 360?
Salesforce now brands Data Cloud as Data 360. We use both names so you can find it.
Related
-
ServiceNow
ITSM, ITOM, CMDB and Discovery, HR and customer service, security operations and platform governance, with integration through Flow Designer and IntegrationHub.
-
Microsoft Dynamics 365
Dynamics 365 Finance, Supply Chain, Sales, Customer Service and Business Central, with Power Platform, Dataverse and Azure integration.
-
Systems integration
Connect enterprise applications using APIs, events, messaging and file exchange, with ownership, monitoring and error handling.
-
Implementations and migrations
How we take responsibility for complex transformation programs: twelve migration types, a seven-stage method and the deliverables you receive at each stage.
Have a technology challenge? Let’s work out the approach.
Discuss a project
Tell us the current system, the target and the timeline. A technical lead replies to talk about scope.
Start the project briefRequest technical talent
Need consultants inside your team rather than a project owner? Send the requirement.
Request talentBecome a partner
Delivery firm, staffing supplier or consulting partner? Register your company.
Register as a partner