01
Development
Apex, Lightning Web Components, triggers, flows and platform events, written to survive the next seasonal release rather than the next sprint.
Capability / Salesforce
Salesforce development, administration and support.
We build on Salesforce and we run it. Configuration and custom code, CPQ, integrations to ERP and logistics systems, customer portals, and the daily queue a production org generates.
Coverage
One team across the whole estate, not one module of it.
A CPQ estate is a connected system. A pricing rule changes what the ERP receives, an integration failure presents as a quoting fault, and a sharing change closes a portal user out. We staff for all of it.
02
CPQ
Product and price rules, bundles, discount schedules, approval logic and quote output, including the custom behaviour layered on top of the standard product.
03
Administration
Users, profiles and permission sets, sharing and visibility, data quality, and the configuration change a live org generates every week.
04
Integrations
The flows between Salesforce and an ERP, shipping and logistics providers, including the diagnosis that says which side a failure belongs to.
05
Communities and portals
Experience Cloud sites where customers and partners transact, with a sharing model that keeps each audience to its own slice of the data.
06
Quality and release
Test classes, regression before a release lands, sandbox strategy, and the seasonal platform releases Salesforce sets the date for.
Depth
The kinds of Salesforce work we take on.
From a single change on a live org through to ownership of an inherited estate.
| Type of work | What it involves | How it is engaged |
|---|---|---|
| A change to a live org | Diagnosis in configuration, code, data or an integration before anything is touched, then a change proven outside production. | Dedicated people, business as usual |
| A feature on an existing estate | Designed against what is already there, built in a sandbox, tested and released on your cadence. | Dedicated people |
| A CPQ build or rework | Product and pricing model, rules, approvals and quote output, with the consequences for the ERP worked through rather than discovered later. | Managed pod |
| A portal for customers or partners | Experience Cloud build, sharing and visibility design, and the pages external users transact on. | Project delivery |
| Taking over an inherited org | An audit of configuration, custom code and integrations, then ownership of the queue and the release path. | Managed pod, business as usual |
Technology and people
What we work with, and who does the work.
Seniority is chosen against the risk in the work. A production quoting path is not junior territory.
Platform
- Sales and Service Cloud
- Experience Cloud
- Salesforce CPQ
- Flow and process automation
Development
- Apex
- Lightning Web Components
- SOQL and SOSL
- Platform events and asynchronous jobs
Integration
- REST and SOAP APIs
- ERP integrations
- Shipping and logistics providers
- Middleware and queued messaging
Delivery
- Sandbox strategy
- Metadata deployment
- Apex test classes
- Release and change control
Roles and seniority available
Salesforce developer
- Apex, LWC and platform automation
- Lead, senior and mid-level
- Works to your branching and review model
CPQ specialist
- Product, price and discount rules
- Senior and mid-level
- Quote output and approval design
Salesforce administrator
- Users, permissions, sharing and data
- Senior and mid-level
- First-line triage on a production org
Salesforce QA engineer
- Regression and release verification
- Senior, mid-level and associate
- Manual passes and automated coverage
Inside your team
How the work runs when the org is yours.
Most of our Salesforce work sits inside someone else's estate, process and release calendar. We adopt them rather than replacing them.
Your org, your change control
We work in your sandboxes, your deployment path and your approval process. Nothing reaches production outside the process you already run.
- Sandbox strategy you define
- Your deployment tooling
- Change approval where you require it
Diagnosis before change
A quoting fault can start in configuration, custom code, data or an integration. We find the origin before touching anything.
- Fault traced to its source
- Reproduced outside production
- Fix proven before it is released
Continuity on the estate
The same engineers see the same org week after week, so recurring faults are recognised rather than rediscovered.
- Named people, not a rota
- Context retained in the team
- Documented as the work is done
Proof
A production CPQ estate, held by one team.
We describe the work, not the client.
What it evidences
Ownership of a connected estate
- CPQ, custom development, ERP and shipping integrations, a customer community and org administration held together
- Faults diagnosed across configuration, code, data and integration before any change is made
- A production quoting and order path kept available through seasonal platform releases
- Internal users and external community users served from the same queue by the same people
Business-as-usual ownership of a CPQ-centred Salesforce estate at a specialty manufacturer
Ongoing ownership of a production Salesforce environment built around CPQ, covering configuration and custom features, ERP and shipping integrations, a customer community and day-to-day org support, held by one team.
Read the case studyNext step
Send us the org and the backlog.
Tell us what the estate looks like and where it hurts. We will come back with the roles it needs and when they can start.