Integrations / CRM
Salesforce + UbiVibe
Connect Salesforce so ARIA can read and act on your real pipeline data.
UbiVibe connects to Salesforce through a governed OAuth connection — no CSV exports, no manual re-entry.
Once connected, ARIA can build dashboards from your real pipeline, flag deals that need attention, and take approved actions inside your existing sales process.
The connection is tenant-scoped: your Salesforce data is never visible to another organization on the platform.
Most teams arrive here because their Salesforce data is accurate but unusable in practice: it lives in reports nobody opens, gets exported to a spreadsheet once a week, or is summarized into a slide that is already stale by the time it is presented.
UbiVibe reads Salesforce through the same provider-agnostic connector path every other integration uses, so the same pipeline context is available to ARIA in conversation, to a dashboard Launch builds, and to a Grow revenue workflow — without maintaining three separate integrations.
Salesforce stays the system of record. UbiVibe adds an operator on top of it: one that can notice a condition, explain it in plain language, and take an approved action about it.
Everything below describes the same connection. One OAuth grant, read through one connector path, used by ARIA, Launch, and Grow according to what each workflow is actually permitted to do.
The practical test for any CRM integration is whether it changes what happens on a Tuesday. Reading pipeline is table stakes; noticing that four commit-stage deals have gone quiet, saying so before the forecast call, and drafting the follow-ups is where the connection earns its place.
Set-up is deliberately small. One OAuth grant, a short conversation about which objects and fields are authoritative in your org, and one workflow worth measuring — broader automation is something you add after the first one has proven itself, not before.
How Salesforce connects
The problem
What breaks without a Salesforce connection.
Without a connector, every question about pipeline becomes a manual retrieval job. Someone runs a report, exports it, pastes it into a spreadsheet, reconciles stage names against last quarter, and rebuilds the same view they built last month. The work is not analysis; it is transport. And it has to be redone from scratch every time the question gets asked again.
Stale data does not just cost effort — it changes the decision. In a Monday-morning export, a deal that went quiet fourteen days ago looks identical to one that had a call on Friday. The condition that should have triggered action is invisible precisely because the snapshot flattens it, and the follow-up that would have saved the deal happens a week late or never happens at all.
The workaround most teams reach for — pasting a CRM extract into a general-purpose AI chat — introduces two new failures. The assistant only knows what fit inside the paste, so its answer is confidently scoped to an arbitrary slice of your pipeline. And there is no tenant boundary, no record of where the data came from, and no way to verify that what it summarized is what your CRM actually says.
The last gap is the expensive one: nothing the assistant concludes can be written back. A good recommendation ends its life in a chat log rather than becoming a task, an owner, and a next step inside the system where the sales team actually works. The insight was real and it changed nothing.
None of this is a Salesforce problem. The CRM is doing exactly what it was built to do, which is hold the record. What is missing is something that reads that record continuously, notices the conditions that matter, explains them without a report-building exercise, and can act on the ones that are unambiguous.
There is also a compounding cost that rarely gets counted. Every hour spent transporting CRM data is an hour not spent on the accounts, and every decision made from a week-old snapshot slightly miscalibrates the next one. The individual instances are each small enough to tolerate, which is exactly why the pattern survives for years without anyone deciding to keep it.
You're likely here because
- Pipeline reviews start with someone exporting a report
- Deal hygiene gets checked manually, if at all
- Dashboards are rebuilt by hand every quarter
- AI tools you have tried can read a pasted export but cannot act on it
Architecture
How the Salesforce connection actually works.
None of this is Salesforce-specific plumbing. The same chain — governed OAuth, tenant-scoped connection, proxied read, provenance stamp, approval-aware write — runs for every connector, which is why connecting a second system does not mean adopting a second integration model.
Step 01
Governed OAuth grant
You authorize Salesforce from inside UbiVibe and the OAuth exchange is brokered through the connector layer. There is no username, password, or security token pasted into a form, and the resulting credential is held against your tenant rather than embedded in application code or shipped to the browser. Revoking the grant in Salesforce ends UbiVibe’s access immediately, because there is no secondary copy of the credential left to clean up.
Step 02
Tenant-scoped connection record
The authorized connection is written into the connection registry with your team identifier attached, and every subsequent read resolves the active connection for that team before a request is made. That is the mechanism keeping one organization’s Salesforce data out of another organization’s workspace, and it is enforced at the lookup rather than as a filter applied to results afterwards.
Step 03
Provider-agnostic read path
Reads go through the same connector service used for every provider. It proxies the call to Salesforce using the stored credential and refreshes the token when it has expired, so there is no Salesforce-specific execution lane to maintain, secure, or audit separately. A hardening fix or a retry improvement made for one provider applies to every provider on the same day.
Step 04
Cached with provenance
Fetched records land in a team-scoped cache with a time-to-live, stamped with the connection id, provider key, team id, and the moment the read was verified. Data is presented as live only when it is both fresh and carries that stamp — a provider label on its own is not treated as proof. Where provenance cannot be established, the platform reports the gap instead of serving the cached copy as current.
Step 05
ARIA reads context, not credentials
When ARIA answers a pipeline question or Launch builds a dashboard, it works from those cached, provenanced records. The Salesforce credential itself is never handed to the model, exposed to the browser, or written into generated page code — a dashboard holds a query against connector-backed data, not a key that could be lifted out of the page source.
Step 06
Approval-aware writes
Actions that change Salesforce run back out through the connector action path and stay subject to the workflow’s approval configuration. A write is an explicit, logged step with a request and a result. What was proposed, what was approved, and what actually changed all remain distinguishable afterwards, which is what makes widening automation a reversible decision rather than a leap.
Workflow examples
What teams can connect through Salesforce
Pipeline health and deal-priority reporting
Account and opportunity context for revenue workflows
Approved updates back into the existing sales process
Forecast-change and stage-movement reporting between reviews
Ownership and territory context for account handovers
Implementation path
How it gets connected.
- 01
Confirm the Salesforce objects and fields that are authoritative
- 02
Connect through the governed OAuth path and verify tenant scope
- 03
Start with one measurable revenue workflow before adding broader automation
- 04
Agree which stages and close-date rules count as authoritative before automating anything
- 05
Verify the connecting user’s field-level access against what the workflow actually reads
Controls
Controls that matter.
Control 01
Keep write actions approval-aware
Control 02
Preserve Salesforce as the system of record where required
Control 03
Measure exceptions and stale-data conditions rather than silently filling gaps
Control 04
Escalate ambiguous records instead of inferring a missing stage or amount
Control 05
Keep the connection scoped to the objects the workflow genuinely needs
Examples
What this looks like once Salesforce is connected.
Deals that went quiet
ARIA compares last-activity timestamps against open opportunities and surfaces the three deals in commit stage with no logged activity in fourteen days. It names the owner on each, explains why each one qualified, and drafts a follow-up for review. Nothing leaves the building until someone approves it, so the question you are evaluating is the quality of the detection, not the risk of the send.
A pipeline dashboard that stays current
Instead of rebuilding a board deck every month, Launch builds a dashboard from live Salesforce objects: stage distribution, coverage against target, and movement week over week. Because it reads through the connector rather than from a pasted export, the numbers have moved the next time someone opens it, and nobody has to remember to refresh anything.
Stage hygiene as an exception report
Opportunities with a close date already in the past but still marked open, late-stage deals missing an amount, records owned by someone who left the team. These surface as a short list to fix rather than as a metric that quietly degrades every forecast built on top of it, which is how bad CRM hygiene usually announces itself — too late.
Context that follows into outbound
When Grow stages an outbound sequence, it can check Salesforce first: is there already an open opportunity, is another rep already working the account, was it closed-lost six weeks ago. Accounts that should not be touched get filtered at the list step instead of being apologized for after the send.
A forecast question answered in the conversation
Rather than commissioning a report, someone asks what changed in the commit category since last week and gets an answer that names the deals that moved, the ones that slipped, and the difference in amount. The obvious follow-up question does not require a second report, which is usually the difference between a number being examined and a number being accepted.
Onboarding a rep onto real pipeline
A rep inheriting a book of accounts asks what is happening on them and gets current state — open opportunities, last activity, recent history — assembled from Salesforce rather than from whatever the previous owner had time to write in a handover document. The ramp is spent on the accounts instead of on reconstructing them.
Limitations and considerations
What the Salesforce integration does not do.
- Scope is bounded by the OAuth grant. If the connected user cannot see an object, field, or record in Salesforce, UbiVibe cannot see it either — the integration inherits your existing permission model rather than working around it.
- Write actions stay approval-gated. UbiVibe is not designed to mutate CRM records silently; supported writes run through the connector action path and remain subject to whatever approvals the workflow requires.
- Salesforce remains the system of record. UbiVibe does not keep a parallel copy of truth to fall back on, and it does not silently resolve conflicts between what your CRM says and what another connected system says — it reports the disagreement.
- Reads are cached, so figures can lag the CRM by up to the configured time-to-live. For a question where seconds matter, check Salesforce directly; for pipeline review and reporting, cached-with-provenance is the right trade.
- Salesforce API limits apply to your org, not to UbiVibe. Very large object scans are batched and can take longer than an interactive question allows, so scope the fields that actually drive the workflow instead of pulling everything.
- Heavily customized orgs need a mapping conversation first. Custom objects, renamed stages, and non-standard close-date semantics are readable, but deciding which of them are authoritative is a judgement your team makes — not one the connector should infer.
- Field-level security and sharing rules apply as written. If a field is hidden from the connected user, workflows built on it are missing that input, and the correct failure mode is an incomplete answer rather than a substituted value that looks plausible.
- The cache is not a backup. Deleted or newly restricted records drop out of UbiVibe’s view rather than being retained, because it reflects what the connection could read at the time rather than archiving your CRM’s history.
FAQ
Salesforce integration FAQ
Does UbiVibe replace Salesforce?
No. The integration is designed to let UbiVibe and ARIA work with Salesforce as an existing system of record when that is the business requirement.
Can ARIA act on Salesforce data?
ARIA can use connected Salesforce context and can take supported, approved actions through the governed connector path.
Where is my Salesforce credential stored?
The OAuth credential is held against your tenant in the governed connection path rather than in application code or client-side JavaScript. ARIA and any generated dashboard work from connector-fetched records; neither receives the credential itself.
How current is the Salesforce data ARIA sees?
Connector reads are cached with a time-to-live and stamped with the connection they came from, so data is presented as live only when it is both fresh and provenanced. Figures can lag your CRM by up to the configured cache window.
Do I need a Salesforce admin to connect it?
You need someone whose Salesforce permissions cover the objects and fields the workflow depends on, because the connection inherits that user’s access. That is often an admin, but the real requirement is the scope of access rather than the job title.
What happens if the Salesforce connection breaks?
Expired or revoked credentials surface as connector health rather than as quietly missing data, and workflows that depend on the connection report the gap instead of continuing against a stale cache as though nothing changed.
Related pages
Other integrations and related pages
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 work in it.
Describe what should happen in this system. ARIA connects through scoped credentials you control, takes only the actions you permit, records what it did, and can require your approval before consequential changes.
- 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
See it connected to your salesforce
Start on the public ARIA path before creating an account. Describe what you want built or operated, confirm ARIA’s interpretation, and continue into the right product from there.