Salesforce Integration
The platform is not the hard part. What was already built in it is.
What is salesforce?
Salesforce integration means connecting other systems to a Salesforce org, where the difficulty comes from the customisation already present, the platform governor limits, and a permission model that behaves differently from most systems.
Salesforce integrations rarely fail on the connection. They fail on what somebody built in the org three years ago: validation rules that reject your data, triggers that fire on your writes, and required fields nobody documented.
The second constraint is deliberate. Salesforce enforces hard limits on how much any process can do, and an integration that ignores them works in testing and fails at volume.
The third is permissions, which combine profiles, roles and sharing rules in ways that mean an integration user can behave very differently from the person who configured it.
Why we look before we quote
Duara integrates Salesforce from Nairobi, and starts by examining the org rather than the requirement.
We look at what is already built before quoting. An org with heavy customisation is a different piece of work from a near standard one, and quoting without looking is how integration projects double in length halfway through.
Who this is for
- Data is entered into Salesforce by hand
- Your org has years of customisation
- A previous integration hit platform limits
- Salesforce and another system disagree
Industries we serve
- Financial services
- Technology companies
- Professional services
- Manufacturing sales operations
- Telecommunications
- Large distributors
Problems this solves
These are the conditions that make a Salesforce integration harder than it appears from outside.
- Customisation nobody documented. Validation rules, triggers and required fields built years ago reject or transform data in ways nothing explains.
- Platform limits hit at volume. An integration that works in testing fails once real volume arrives, because governor limits are hard rather than advisory.
- Permission behaviour that surprises. Profiles, roles and sharing rules combine so an integration user sees something different from whoever configured it.
- Duplicate records multiplying. Integrations creating rather than matching produce a second version of a customer that then diverges.
What we deliver
Examining the existing org before quoting, designing within platform limits from the start, testing permissions as the integration user, and matching records rather than creating them.
An assessment of your existing org customisation
Integration designed within platform limits
Permissions tested as the integration user
Record matching rather than duplicate creation
Testing in a sandbox that reflects production
Documentation your own admin can maintain
Features
- The org examined before quoting. Heavy customisation is a different piece of work, and quoting without looking is how projects double halfway through.
- Built within governor limits. They are hard rather than advisory, and an integration ignoring them works in testing and fails at volume.
- Permissions tested as the integration user. Profiles, roles and sharing rules combine unpredictably, so what your admin sees proves nothing about what the integration sees.
- Matching, not creating. Records are matched against existing ones, since duplicate customers diverge and then nobody knows which is current.
- Handover to your admin. Documented so your own Salesforce administrator can maintain it rather than depending on us.
Benefits
- Data stops being entered twice. Information already captured elsewhere reaches Salesforce without somebody retyping it.
- Integrations that survive volume. Designing within platform limits means the thing that worked in testing still works in December.
- Fewer duplicate records. Matching rather than creating keeps a customer as one record rather than three that disagree.
- No dependency on us. A documented integration your admin understands is one you can change without a supplier.
Technologies we use
- Org assessment. Examining existing validation rules, triggers, required fields and customisation before design.
- Limit aware design. Building within governor limits on records, queries and processing.
- Permission testing. Verifying behaviour as the integration user rather than as an administrator.
- Record matching. Matching to existing records on agreed criteria rather than creating new ones.
- Sandbox testing. Testing in an environment that reflects production customisation rather than a clean org.
Governor limits are the constraint that most distinguishes this platform. They are enforced rather than recommended, and an integration designed without them in mind is a system that will fail specifically when you are busiest.
How the process works, step by step
A Salesforce integration usually takes three to seven weeks, and the org assessment happens before the estimate rather than after it.
-
Step 1
Free org review
We examine what is already built, since that determines the work far more than the requirement does.
-
Step 2
Limits considered in design
Governor limits shape the approach from the start rather than being discovered during load testing.
-
Step 3
Matching rules agreed
How records are matched to existing ones, since duplicate creation is the most common lasting damage.
-
Step 4
Tested as the integration user
Permissions verified from the integration perspective rather than from an administrator account.
-
Step 5
Handover documented
Your Salesforce administrator receives what they need to maintain and extend it.
Quality assurance and how we work
The commitments attached to writing into a customised CRM.
- We examine the org before quoting. Heavy customisation is a different piece of work, and quoting without looking is how integration projects double in length.
- We design within platform limits. Governor limits are enforced rather than advisory, and ignoring them produces a system that fails when you are busiest.
- We test permissions as the integration user. What an administrator sees proves nothing about what the integration will see, and that gap causes real failures.
- We match rather than create. Duplicate customer records diverge, and then nobody can say which one is current.
- We hand over to your administrator. An integration only we understand leaves you unable to change your own CRM.
Frequently asked questions about salesforce
What makes Salesforce integrations hard?
Not the connection. What somebody built in the org years ago, in validation rules and triggers nobody documented.
What are governor limits?
Hard platform limits on how much a process can do. They are enforced rather than advisory, and ignoring them fails at volume.
Why does that matter?
Because an integration built without them works in testing and then fails specifically when you are busiest, which is the worst possible timing.
Will you look at our org first?
Yes, before quoting. Heavy customisation is a different piece of work and quoting blind is how projects double in length.
What goes wrong with permissions?
Profiles, roles and sharing rules combine so the integration user sees something different from the administrator who configured it.
Do you test as the integration user?
Yes, specifically. What an admin can see proves nothing about what the integration will be able to do.
Will it create duplicate records?
Not if matching rules are agreed first. Duplicate customers diverge and then nobody knows which is current.
Can it write to custom objects?
Yes, and custom objects are usually where the interesting data is in a mature org.
What about our existing triggers?
They will fire on records the integration writes, which is exactly why the org assessment happens before design.
How long before Salesforce is receiving data?
Three to seven weeks, with the org assessment done before the estimate rather than after.
Which sandbox do you test against?
Yes, one that reflects production customisation. A clean sandbox proves nothing about an org with years of configuration.
Can our admin maintain it afterwards?
Yes, and it is documented for that. An integration only we understand leaves you unable to change your own CRM.
Can it connect Salesforce to our ERP?
Yes, and that is a common request, with field ownership decided explicitly so the two do not overwrite each other.
What if both systems change the same field?
One system owns each field. Without that rule the two overwrite each other and the conflict is unresolvable afterwards.
Does it work with Salesforce Marketing Cloud?
Yes, though it is effectively a separate platform and we would scope it as its own piece of work.
Can it handle high volume?
Yes, with bulk processing designed for it, which is a different approach from record by record and has to be chosen upfront.
What happens when Salesforce releases updates?
Supported interfaces are stable across releases. We build on those rather than on anything that breaks at each update.
Will it slow our org down?
Not if built within limits and scheduled sensibly. Poorly built integrations are a common cause of org performance complaints.
Who has access to our Salesforce data?
The integration user we agree, with permissions you set and can revoke at any point.
What does a Salesforce integration cost?
Org complexity and object count determine it, quoted after the org review.
Glossary of terms
Salesforce terms in plain language.
- Org
- Your Salesforce instance, including everything configured in it over the years.
- Governor limits
- Hard platform limits on processing, enforced rather than recommended.
- Validation rule
- A configured condition that rejects records not meeting it, including from integrations.
- Trigger
- Code that runs automatically when records change, including records your integration writes.
- Sharing rules
- Part of the permission model determining who sees which records.
- Sandbox
- A test environment, useful only when it reflects your production customisation.
Related services in Integrations
Talk to us about salesforce
Ask your Salesforce administrator how many validation rules and triggers the org has. That number predicts the work.
Start your project