CRM integration guide
Salesforce + UbiGrowth workflows
Salesforce is an enterprise CRM platform where accounts, contacts, opportunities, and activity history are the authoritative record of the commercial relationship. This guide covers the records that matter, how the connection should be scoped, and what the first bounded workflow should be.
Introduction
Make Salesforce part of the workflow, not another silo.
Verified UbiVibe connection
This guide covers how a team designs a CRM workflow around Salesforce with UbiGrowth: which records stay authoritative, how the connection should be scoped, what the first bounded workflow should be, and how to tell whether it worked.
The records that matter are Account, Contact, Lead, Opportunity, Task, Event, and Campaign. Salesforce keeps Lead and Contact as separate objects until conversion, so the same human can exist twice with no link between the records. Match on Account first and resolve the Lead/Contact split explicitly; matching on email alone silently creates duplicate work on converted leads.
Salesforce is a live, governed UbiVibe connection today: it is authorized through an OAuth grant your workspace approves, scoped to the access you approve, and tenant-scoped so no other organization can see your data.
Grow is the usual destination for this connection, because the value shows up as outreach, reply handling, scheduling, and pipeline execution against the connected records.
Why teams evaluate this connection
Integrations create value when they remove operating friction.
The first design decision is not which API endpoint to call; it is which system owns the record, what event should trigger work, who owns the exception path, and what successful completion means.
The recurring failure with a Salesforce integration is not connectivity. It is that the CRM ends up holding a record of what someone remembered to log, while the work itself happened in an inbox, a call, a spreadsheet, and a separate AI tool that never saw the account.
When that gap exists, everything built on top of it inherits it. Forecasts describe logged activity rather than real activity, outreach is written without the reply history that would make it relevant, and the team spends its day reconciling systems instead of working accounts.
You're likely here because
- Pipeline data is only as current as the last time someone logged activity
- Outreach is generated without the account history that would ground it
- The same account context is rebuilt in several tools each day
Record model
What a Salesforce integration actually reads and writes.
Integration design starts from the objects the system really exposes, not from a generic connector diagram. These are Salesforce's.
Identity and matching
Salesforce keeps Lead and Contact as separate objects until conversion, so the same human can exist twice with no link between the records. Match on Account first and resolve the Lead/Contact split explicitly; matching on email alone silently creates duplicate work on converted leads.
Start here
Read open Opportunities with no Task dated in the last 14 days, assemble the account history, and stage a specific next action for the owner to approve. Read-only until the queue is demonstrably right.
What this will not do
It will not repair pipeline hygiene on its own. If reps do not log activity, a connected workflow reads the same gap faster; the fix is making the next action visible, not syncing more fields.
The constraint to plan around
Validation rules, required custom fields, and record-type-specific page layouts reject writes that look valid against the standard object. Every org is effectively its own schema, so validate against the actual instance rather than the object reference.
Build notes
What you actually have to reason about in Salesforce.
The fields that carry meaning, how the connection authenticates, and whether the event surface can be trusted. This is the part that decides whether the integration works in month three.
| Field | Why it matters |
|---|---|
| StageName | the pipeline position everything forecasts from, and a picklist whose values differ per record type |
| CloseDate | drives every forecast rollup; reps move it rather than losing the deal, so its edit history is the real signal |
| IsClosed / IsWon | read-only formula fields derived from StageName — check these rather than string-matching stage names |
| OwnerId | decides visibility under the sharing model, so an integration reading as one user sees one owner's slice |
| LastActivityDate | rolls up Tasks and Events, and is the closest thing to a truthful staleness measure |
Authentication
Connected App with OAuth, and the flow choice matters more than the credential: a JWT bearer flow tied to an integration user gives a stable, auditable identity, while username-password flows are being retired and refresh tokens can be revoked by an admin without warning. The integration user needs a profile and permission set built for it, not a copy of a sales manager's.
Events and delivery
Platform Events and Change Data Capture are the supported push surfaces, and both are replay-based with a bounded retention window — a consumer down longer than that window has a gap it cannot recover from the stream. Outbound Messages still exist and still retry, but they carry no ordering guarantee.
Workflow
How the Salesforce workflow runs.
The operating sequence, from reading the source system through to the result landing back where it belongs.
Step 01
Read the pipeline as it stands
The workflow starts from live Salesforce accounts, contacts, and opportunities rather than an export, so prioritization reflects today's pipeline.
Step 02
Assemble the account context
Reply history, documents, and prior activity are brought together so the next action is grounded in what actually happened with the account.
Step 03
Decide the next action
ARIA proposes the specific next step for the account, with the supporting context attached, instead of producing a message with no stated reason.
Step 04
Execute through Grow
Outreach, reply handling, and scheduling run against the same record, staged for review while the motion is being proven.
Design decisions
The CRM decisions this connection forces.
Each of these has to be settled before the Salesforce workflow is allowed to write anything.
Step 01
Resolve the account identity
Decide how a person and a company are matched between Salesforce and the rest of the stack before any write happens. Most CRM integration damage is duplicate records created by a weak match rule.
Step 02
Keep execution attached to the opportunity
Outreach, replies, meetings, and stage changes should resolve back to the same opportunity, so the CRM reflects what actually happened rather than a parallel activity log.
Implementation path
How to implement the Salesforce workflow.
- 01
Decide which fields Salesforce owns and which the workflow may write, and write that decision down before enabling anything.
- 02
Define the identity match rule for contacts and companies, including what happens on an ambiguous match.
- 03
Start read-only. Prove that the workflow reads the right records before it is allowed to change any of them.
- 04
Once the next-action queue is trusted, close the loop: write the outcome of the action back to the Opportunity as an activity so the CRM records what happened rather than only what was proposed.
Governance
Controls that matter.
Control 01
CRM write scopes are limited to the specific objects the workflow needs, never blanket admin access.
Control 02
Duplicate creation is treated as a defect, not an acceptable side effect of syncing.
Control 03
Stage changes and closed-won updates stay under human control; automation prepares them rather than deciding them.
Failure modes
How a Salesforce integration breaks in production.
Not generic integration advice. These follow from how this system actually behaves, which is why they look nothing like the list on the next guide over.
Symptom 01
Writes start failing for one record type only, having worked for months.
Cause
An admin added a required custom field or a validation rule scoped to that record type.
Fix
Read the field describe for the record type at runtime rather than caching a field list at build time, and surface the validation message instead of a generic error.
Symptom 02
A nightly sync stops part-way through, leaving some records updated and some not.
Cause
Governor limits or the daily API allocation were exhausted mid-run — the allocation is org-wide and shared with every other integration.
Fix
Use the Bulk API for volume, checkpoint progress so a resumed run does not restart, and monitor the org's API usage rather than your own call count.
Symptom 03
The same contact appears three times after a marketing import.
Cause
Lead and Contact are separate objects until conversion, so a match rule that only checks Contact misses every unconverted Lead.
Fix
Resolve against both objects and the Account before creating anything, and treat an ambiguous match as an exception for a human rather than a new record.
What changes at scale
The daily API allocation is per org and per edition, shared by every connected system. An integration that is comfortable in isolation can exhaust the org's allocation and break the marketing sync, which is discovered as someone else's outage.
Examples
What a working Salesforce workflow looks like.
Bounded scenarios rather than a feature list. Each one can be verified against work the team already does.
Pipeline context
With Salesforce connected, ARIA works from live account, contact, and opportunity records instead of an export, so prioritization reflects the pipeline as it stands today.
Grounded outbound
Grow drafts outreach against the account history already in Salesforce, so the message references what actually happened with the account rather than a generic template.
Limitations and considerations
What to validate before you depend on this.
- Validation rules, required custom fields, and record-type-specific page layouts reject writes that look valid against the standard object. Every org is effectively its own schema, so validate against the actual instance rather than the object reference.
- Salesforce runs your write through validation rules, triggers, flows, and Apex, in an order the org owns rather than you. A bulk update can therefore fire thousands of downstream automations, hit governor limits mid-batch, and leave the org half-updated with no transaction to roll back.
- When the process genuinely lives outside the commercial relationship. Modelling delivery, support, or finance as custom objects makes the org harder to change for everyone, and every subsequent integration inherits that weight.
- If Salesforce data is incomplete, the workflow inherits that gap. Connected context is not automatically accurate context.
- Custom objects, custom fields, and heavily-customized permission models change what an integration can safely do; validate them against your own instance rather than the vendor default.
FAQ
Salesforce integration questions.
What records does a Salesforce integration actually work with?
The primary records are Account, Contact, Lead, Opportunity, Task, Event, and Campaign. Salesforce keeps Lead and Contact as separate objects until conversion, so the same human can exist twice with no link between the records. Match on Account first and resolve the Lead/Contact split explicitly; matching on email alone silently creates duplicate work on converted leads.
What should the first Salesforce workflow be?
Read open Opportunities with no Task dated in the last 14 days, assemble the account history, and stage a specific next action for the owner to approve. Read-only until the queue is demonstrably right.
What will a Salesforce integration not do?
It will not repair pipeline hygiene on its own. If reps do not log activity, a connected workflow reads the same gap faster; the fix is making the next action visible, not syncing more fields.
What is the main constraint to plan around?
Validation rules, required custom fields, and record-type-specific page layouts reject writes that look valid against the standard object. Every org is effectively its own schema, so validate against the actual instance rather than the object reference.
What changes about a Salesforce integration at scale?
The daily API allocation is per org and per edition, shared by every connected system. An integration that is comfortable in isolation can exhaust the org's allocation and break the marketing sync, which is discovered as someone else's outage.
How does authentication work for Salesforce?
Connected App with OAuth, and the flow choice matters more than the credential: a JWT bearer flow tied to an integration user gives a stable, auditable identity, while username-password flows are being retired and refresh tokens can be revoked by an admin without warning. The integration user needs a profile and permission set built for it, not a copy of a sales manager's.
Does Salesforce support webhooks, and can they be trusted?
Platform Events and Change Data Capture are the supported push surfaces, and both are replay-based with a bounded retention window — a consumer down longer than that window has a gap it cannot recover from the stream. Outbound Messages still exist and still retry, but they carry no ordering guarantee.
What is the risk of writing to Salesforce?
Salesforce runs your write through validation rules, triggers, flows, and Apex, in an order the org owns rather than you. A bulk update can therefore fire thousands of downstream automations, hit governor limits mid-batch, and leave the org half-updated with no transaction to roll back.
When is connecting Salesforce the wrong call?
When the process genuinely lives outside the commercial relationship. Modelling delivery, support, or finance as custom objects makes the org harder to change for everyone, and every subsequent integration inherits that weight.
What should a Salesforce integration automate first?
Start with one bounded workflow that removes a measurable handoff, duplicate-entry step, reporting delay, or follow-up gap. Expand only after the first workflow is reliable.
Does UbiGrowth require Salesforce to be replaced?
No. The operating model is designed around connecting to systems that should remain authoritative and building workflows around them rather than forcing a wholesale replacement.
Is connector availability identical for every workspace?
No. Availability can depend on provider configuration, authentication, scopes, workspace setup, and deployment state. Validate the required connection before treating it as an operational dependency.
Will this create duplicate records in Salesforce?
Only if the identity match rule is weak. Define how people and companies are matched, and how ambiguous matches are handled, before enabling any write path.
Does Salesforce stay the system of record?
Yes. The design assumption is that Salesforce remains authoritative for the objects it owns and the workflow builds around it rather than replacing it.
Can pipeline stages be updated automatically?
Stage progression should stay under human control. Automation can prepare and propose the update, but deciding that a deal moved is a judgment call.
How this access is governed
What ARIA is allowed to do in Salesforce, and who decides.
Connecting Salesforce is a permission decision, not just a setup step. These are the controls that decide what ARIA can reach, what it can change, what gets recorded, and how you take the access back.
Required permissions
ARIA works through the scopes the connection was granted, and no others. Authorization happens at the provider, so the permissions being requested are shown by the system itself before anything is connected.
What it can reach
Reachable systems are the intersection of what your organization approved in the connector registry and what the requesting identity is permitted to use. Identity resolves before execution, not after.
What it can do
Actions run through explicit execution paths with state, spend, and failure boundaries — a bounded worker path rather than an open-ended agent loop with a credential.
Credential handling
Credentials live in the governed connection layer and are resolved through canonical connection identity. They are not pasted into individual workflows, prompts, or generated artifacts.
Action logging
Execution carries state and traces: what triggered the work, which connection it used, and what came back — including an explicit failure when something did not run.
Approval and revocation
Consequential actions can be made to require a person to approve them. Access can be changed or revoked at the connection, and ARIA loses that reach without unpicking the work already completed.
Start with ARIA
Ask ARIA to run this integration.
Describe the outcome you need across this system. ARIA works out the scopes, data, and actions the job requires, and operates inside the access you grant — which you can change or revoke.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Turn the integration into a working business outcome.
Start with ARIA to describe the outcome, then continue into the product path that fits the workflow. Connector availability and required scopes should be validated for the specific workspace before production use.