Salesforce integration into the org you already run
A Salesforce org that has run for years is not a clean CRM. It is layers of settings left by several people: custom objects, required fields, validation rules, profiles and permission sets. We connect it to invoicing, orders and the warehouse so the integration fits inside that configuration, not beside it. Every change is built on a sandbox and reaches production as a metadata package your admin reviews.
- 2 to 6 weeksfrom the workshop to a connected Salesforce, depending on how many custom objects and permission rules are in scope
- 14 daysfrom the workshop to the first automation running on a sandbox, on a copy of your own data
- 5 to 10 secondshow long BOND takes to answer a question about Salesforce data, with no report to build
The problem
Why does Salesforce do less than you pay for?
A partner rolled Salesforce out for you four years ago. The admin who ran it afterwards changed jobs, and the settings stayed. A rep fills in twelve required fields on an opportunity and nobody reads half of them. Finance keeps a separate spreadsheet, because the Salesforce report shows a different number and no one can say where the difference comes from.
The reason is not surprising. The configuration grew in layers and nobody ever closed one off. A custom object created for a single project, a validation rule added for a single exception, two automations doing the same thing from opposite ends. Then an integration with the invoicing system arrives, falls over on the first required field nobody told it about, and the hunt for someone to blame starts instead of the hunt for the rule.
The third thing is technical and it sets the schedule. Salesforce counts API calls in a rolling 24 hour window for the whole org, and the size of that allowance depends on your edition and licence count, as set out in the Salesforce developer documentation. An integration that queries record by record can burn the allowance before the day ends, and it takes every other integration in the same org down with it. So volume goes through the Bulk API, and we take changes as events rather than polling every 15 minutes.
- A rep fills required fields nobody reads, using whatever value clears the screen fastest
- Finance keeps a spreadsheet next to Salesforce, because the report is not trusted
- The same company sits in Salesforce as three accounts after a merger and a migration
- Nobody knows which automation moved the opportunity to the next stage
- A configuration change goes straight to production, because the sandbox holds last year's data
Why now
What changed, so this can be done without rebuilding Salesforce?
Salesforce gives you separate test environments, and that changes how you work with an existing configuration. A change is designed on a sandbox, and what reaches production is a metadata package your admin or your partner can review before deployment. The documentation sets the refresh windows: Full once every 29 days, Partial Copy once every 5 days. That is why we fix the date of the test on fresh data at the start of the project, not in the week of the switchover.
The second change is about where the logic lives. A Salesforce Flow is the best place for rules that concern Salesforce alone: a task after a stage change, an account owner assignment, a field validation. When a rule has to ask the invoicing system about a payment status or append a row to the warehouse, the logic moves to n8n or Make, and Salesforce stays the place the result is written. The technical layer, meaning authentication, limits and error handling, is covered on our API integration services page.
The third change is the AI agent. A Salesforce report answers the question somebody anticipated on the day it was built. BOND, our company AI agent, reads from Salesforce with a SOQL query and answers in a plain sentence in 5 to 10 seconds, for example on which enterprise accounts have had no activity for 60 days. The question is asked by a person who could not build that report, and that is the whole difference.
What changes
What do you get out of a connected Salesforce?
The integration fits your configuration, not the other way round
Before we write anything, we read your custom objects, required fields, validation rules and live automations through the API. The integration knows those rules from its first write, so it does not fall over on a field nobody told it about.
An inventory of objects, required fields and rules that block writes, done before the first line of code
Change goes through a sandbox, not through production
New fields, amended rules and workflows run first on a sandbox holding a copy of your data. Production receives a metadata package that can be reviewed and rolled back.
Tested on a sandbox refreshed inside the documented window: Full 29 days, Partial Copy 5 days
The API allowance stops being a risk
Volume goes through the Bulk API, and record changes arrive as events instead of a poll every 15 minutes. We measure allowance usage before the switchover and after it, so you can see how much room is left for other integrations.
Usage of the 24 hour window counted before and after the rollout, not estimated
Permissions written out field by field
The integration runs as its own user with a permission set narrowed to the fields in scope. Nobody is handed access to the whole org because that was quicker to set up.
A dedicated integration user, read access and write access granted separately
Your admin or partner knows what we are doing
The scope of metadata changes goes to them in writing before deployment, and we settle who owns which layer. Our work does not collide with the partner who maintains your Salesforce.
A written split: who changes metadata, who maintains the workflows outside Salesforce
A question about Salesforce data with no report to build
The board, the warehouse and finance ask in a plain sentence and get an answer from current data. Nobody learns to build reports in order to check one number once a week.
An answer from a SOQL query in 5 to 10 seconds, with no admin time spent
Proof
Do you connect a CRM to an AI agent yourselves?
Yes, and to be straight with you: the CRM in our founders' agency is HubSpot, not Salesforce. The mechanism is the same, reading and writing through an API under scoped permissions, and below is the scale of that work together with what the number does NOT prove.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency of around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
The agent is wired into the CRM, the website forms, Slack and the data warehouse. Records are created from form submissions, from ads and from referrals, and the agent writes to the CRM as its own user with a narrowed permission scope.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- A person created the contact and the company in the CRM: read the enquiry, retyped the details out of the email and checked by hand whether the company was already there. How complete the data was depended on who happened to have time.
- After
- The agent creates the contact and the company, checks for a duplicate by domain, fills in the company details and notifies the team on Slack. A person steps in at the customer conversation, not before.
3,432 operations on leads and 1,301 on form submissions in 30 days, with no human involved
And in your company
What if our Salesforce is too cluttered for this?
Four sentences come up most often around Salesforce, and this is how we answer them.
If you are after something next to this, there are separate pages: CRM implementation and integration when there is no CRM yet or the choice is still open, HubSpot integration when you are comparing systems, and BOND, our business AI agent when the problem is access to the data rather than the way it flows. Contact data is processed under Regulation 2016/679, so we set the retention period for records that never entered the sales process together with you.
Our Salesforce was configured by someone who no longer works here.
That is the most common starting point, which is why the configuration review is a separate step for us rather than a preamble to a rollout. We read objects, fields, validation rules and automations through the API, then give you numbers: how many fields are actually filled in, how many have sat empty for a year, which rules block writes from outside. You get that report before anything changes, and you can act on it without us.
We are not giving an outside firm access to production.
You do not have to. We work on a sandbox, and on production we start with read access through a dedicated integration user with a narrowed permission set. The metadata package can be deployed by your own admin or partner; we hand it over for review along with a list of what changes. Write access on production is switched on after the pilot, on a narrow list of operations.
We have a Salesforce partner who maintains this.
Good, and they usually stay. We split the scope in writing: the partner owns metadata and configuration inside Salesforce, we own the layer outside it, meaning the workflows in n8n or Make, the warehouse and the AI agent. Every field that needs creating is raised in advance, so two firms do not end up changing the same rule in opposite directions.
We are starting to think Salesforce is too big for us.
Then we will say so plainly instead of selling you an integration. Salesforce earns its place when the sales process has many stages and exceptions, when you need field level access control and a change history for audit, and when there is somebody to administer it. With five reps, one process and no audit requirement, a simpler CRM works out cheaper, and the difference shows up in the first year.
- Salesforce
- Standard and custom objects, required fields, validation rules, Flow, profiles and permission sets, sandbox
- Invoicing and accounting
- Xero, sevDesk, Fakturownia, Comarch Optima, Subiekt
- Sales and orders
- BaseLinker, Shopify, WooCommerce, PrestaShop, Allegro
- Team tools
- Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana
- Data and warehouse
- BigQuery, Google Sheets, Google Analytics, SQL databases
- Automation layer
- Make, n8n, Zapier, custom API integrations
What we find in a Salesforce configuration and what we do about it
Seven things that block an integration most often in an existing Salesforce org. The second column matters more than the third here, because most delays come from nobody checking these conditions before the start.
| What we find in the configuration | Why it blocks the integration | What we do about it |
|---|---|---|
| A required field on a custom object | the write from outside fails, the integration knows nothing about that field | a default value, or the field taken off the required list, verified on a sandbox |
| A validation rule with a condition on profile | passes for the rep, fails for the integration user | the condition extended to cover the integration user, shipped as a metadata package |
| Field level security | the integration reads the record but cannot see half the fields | a permission set narrowed to the fields in scope, written out field by field |
| Duplicate accounts after a migration or merger | one company as three accounts, the report never adds up | matching on tax number, domain and fuzzy name, merged once the rules are approved |
| Querying record by record | the API allowance in the 24 hour window runs out before the day does | Bulk API for volume, change events instead of a poll every 15 minutes |
| Several automations on the same object | no way to tell which one moved the opportunity stage | an inventory of automations and one layer of rules per object |
| A sandbox holding last year's data | the test passes and production fails on a real record | a Partial Copy or Full refresh inside the documented window |
The rows are a starting point. In most companies the review catches three or four of them, and the repair order is settled at the workshop together with the person who administers your Salesforce.
How we work
Five steps from a cluttered org to a connected Salesforce
Each step ends with something you can judge before you decide on the next one.
Workshop
We break the sales process into stages and ask the same question at each one: where does this information come from, who retypes it today and who uses it. We also settle who on your side is allowed to change the Salesforce configuration, because the schedule depends on that answer.
Configuration review
We read custom objects, fields, validation rules, automations, profiles and permission sets through the API. We count the facts: what is filled in, what sits empty, how many duplicate accounts there are, how many calls your current integrations burn in the 24 hour window. You get the report before anything changes.
Permission scope and the logic split
We create the integration user and narrow its permissions to the fields in scope, separately for reading and for writing. We split the rules: what stays in Salesforce Flow, what moves to n8n or Make. The list of metadata changes goes to your admin or partner for review.
Pilot on a sandbox
The integration runs first on a sandbox holding a copy of your data, and we push real cases from the last few weeks through it, including the ugly ones: an account with no tax number, a duplicate left by a merger, an opportunity with an empty required field. We measure API allowance usage before anything touches production.
Production and measurement at 30 and 90 days
We switch over with error monitoring in place and train the person who will maintain it. After 30 days we look at field completeness and the number of events that failed. After 90 days we look at whether finance is still keeping that spreadsheet next to Salesforce.
Before and after
How the day changes for the person working in Salesforce
Before
- Fills in twelve required fields to save an opportunity
- Opens the invoicing system to check whether the customer paid
- Asks the admin for a report, because the existing one does not answer what the board asked
- Makes configuration changes straight on production, because the sandbox holds old data
After
- Fields that served nobody came off the required list after the review
- Payment status and invoice number sit as fields on the opportunity
- Asks the AI agent in a plain sentence and gets an answer from Salesforce in 5 to 10 seconds
- Change ships as a metadata package: sandbox first, then production
The first automation runs on a sandbox 14 days after the workshop. We judge field completeness and failed events at 30 days, and whether anyone still keeps a spreadsheet on the side at 90.
For the person signing this off
What the person paying for Salesforce licences gets out of it
Salesforce licences and admin time are a fixed cost, and how well the platform is used has so far been a matter of trusting what the team says. After the review you know how many fields are actually filled in, how many automations do the same job from two directions and how many API calls your current integrations burn. The renewal conversation stops being a conversation about impressions.
The second thing takes the risk off your decision. Nothing reaches production without a sandbox test and without a change list your admin or partner has already reviewed. We start with a process workshop, so your first decision rests on a document rather than a promise, and if the review shows Salesforce is oversized for you, we will say that too.
- Licence usage visible as a number, not as an opinion from the team
- Nothing on production without a sandbox pilot and a change list to review
- A dedicated integration user with permissions narrowed to the fields in scope
- The split of responsibility with your Salesforce partner agreed in writing
What it costs
The workshop has a fixed price, the integration is quoted after it
The process workshop costs EUR 3,500 net per week and runs from one to seven weeks depending on scope. For a single Salesforce org one week is usually enough, because the scope is narrow: what enters Salesforce, where from, and under which rules it gets written. The integration is quoted after the workshop, once the review shows how many custom objects and permission rules are in play.
You pay Salesforce for the licences directly, and the same goes for running workflows in Make or n8n, or you pay nothing at all when the workflow sits on your own infrastructure. Where an AI agent is in scope, the model provider charges EUR 0.005 to 0.07 per query. No commission on top from us. If your Salesforce partner is doing part of the metadata work, you settle their time with them and we hand over the scope in writing.
Process workshop
EUR 3,500 net
per week, usually one week for a single Salesforce org
A self-contained piece of work. It ends with a configuration review and a list of connections in order, which you can execute without us.
- Salesforce org review: custom objects, required fields, validation rules, automations
- Profile and permission set review for a dedicated integration user
- Measurement of how much of the 24 hour API allowance current integrations burn
- Duplicate account report and proposed merge rules
- The logic split: what stays in Flow, what moves outside Salesforce
- Most popular
Workshop and Salesforce integration
Quoted after the workshop
scope follows from the number of systems and the state of the configuration
The option most companies choose. A connected Salesforce 2 to 6 weeks after the workshop, verified on a sandbox before production.
- Everything in the workshop
- Integrations through the API: invoices, orders, warehouse, team tools
- Bulk API for volume and change events instead of polling
- Pilot on a sandbox with a copy of your data, switchover with error monitoring
- Metadata package handed to your admin for review
- Training for the person who will maintain it without us
Salesforce and an AI agent
Quoted after the workshop
for companies where the whole team asks about CRM data, not only sales
Everything in the integration plus BOND, which answers questions about accounts and opportunities in a plain sentence.
- Everything in the Salesforce integration
- AI agent reading from Salesforce with SOQL: accounts, opportunities, activities
- Permissions scoped separately for reading and for writing
- Access for people outside sales, an answer in 5 to 10 seconds
The workshop ends with a document that stands on its own without us: a configuration review, a map of where each piece of information is written and a list of connections in order. If the review shows the Flows you already have are enough, we say so and the engagement ends at the workshop. If it turns out Salesforce is oversized for your scale, we will say that too, even though it leaves us with nothing to sell you.
Frequently asked questions
How is a Salesforce integration different from integrating a simpler CRM?
The starting point. In a simpler CRM you usually design the flow from scratch. In Salesforce you walk into a configuration somebody built years ago: custom objects, required fields, validation rules, profiles and permission sets. That is why the review of that configuration is a separate step for us rather than a preamble, and why the first version of the integration runs on a sandbox.
Do we have to give you access to our production Salesforce org?
Not at the start. We work on a sandbox, and on production we begin with read access through a dedicated integration user whose permissions are narrowed to the fields in scope. Writing is switched on after the pilot, on a narrow list of operations. The metadata package can be deployed by your own admin or partner, and we hand it over with a list of everything it changes.
What happens when a required field blocks a write from outside?
First we check what the field is for and who uses it, because some required fields are leftovers from projects that no longer exist. If the field is needed, the integration gets a value for it agreed at the workshop. If it is not, we propose taking it off the required list and we verify that change on a sandbox before it goes anywhere near production.
How do you stay inside the Salesforce API limits?
Salesforce counts calls in a rolling 24 hour window for the whole org, so an integration that queries record by record can block every other one. We push volume through the Bulk API, take changes as events, and measure allowance usage during the review and again after the switchover. That shows you exactly how much room is left for the other integrations in that org.
When does a rule stay in Flow and when does it move to n8n or Make?
Rule of thumb: if it concerns Salesforce alone it stays in Flow, because that is where your admin can change it without us. A task after a stage change, an account owner assignment, a field validation, all Flow. If the rule has to query the invoicing system or append a row to the warehouse, it moves to the orchestrator, where you can see which step it failed on and rerun it.
How long does it take to connect Salesforce to other systems?
One week of workshop and 2 to 6 weeks of work, depending on the number of systems and the state of the configuration. The first automation usually runs on a sandbox 14 days after the workshop, so the team sees an effect before the project ends. The longest item is often not the integration but agreeing the metadata changes with whoever owns the configuration.
When does a company not need Salesforce?
When the sales process has a handful of stages and no exceptions, when there is no requirement for field level access control or an audit trail of changes, and when there is nobody to administer it. With five reps and one process a simpler CRM costs less in licences and in upkeep, and the difference shows in the first year. We say this at the consultation, before we quote anything.
Can the AI agent write data into Salesforce?
It can, but permissions are scoped separately for reading and for writing and we usually start with reading only. Writing is switched on after the pilot, on a narrow list of operations: a note, a task, a change to one field. Every agent operation is logged, so you can check who changed what and roll the change back.
Let us look at what is holding your Salesforce back today
The free consultation takes 30 minutes. You tell us how long you have had Salesforce, who administers it now and what you retype into it from other systems: invoices, orders, spreadsheets. We show you which connection removes the most manual work and what has to be tidied up in the configuration before it. You do not have to share access to the org at this stage.
We run at most two rollouts at a time, so that someone is actually sitting on each of them.
Book a free consultationPS. If somebody at your company filled a required field with anything at all this week just to save an opportunity, that is exactly this problem. A connected Salesforce pulls that data from the system where it already exists, and fields that serve nobody come off the required list after the review. We start with the workshop, because an integration bolted onto an untidy configuration only spreads the mess faster.