What SAGARIS reads, what it would write, and what gates it

SAGARIS reads Salesforce live: records, activity and attachments come out of the connected org. Write-back is built and switched off in production, so it runs as a dry run: SAGARIS computes the change and records it without sending it. When it is switched on, activity SAGARIS generates lands as standard Task and Event records. Switching it on is a rollout decision on our side, not a setting in your org.

What moves in each direction

Reading is live. Records, activity and attachments are extracted from the connected Salesforce org into SAGARIS, and the record in SAGARIS is the one the pipeline gates and the agents act on.

Writing back is switched off in production. It is gated by two deployment settings that SAGARIS controls, a global flag and a per-workspace allowlist, and in production both are off, so every write resolves to a dry run. The resolver treats anything other than an explicit live value as a dry run, so the safe state is the default rather than something an operator has to remember to choose. Switching it on is a rollout decision on our side, not a setting in your org.

Note

A dry run computes the exact mutation it would send and does not send it. That is what makes it useful for inspecting a new connection: the payload is real even when the write is not.

What SAGARIS would write into your org

When write-back is switched on, activity is written as standard Salesforce objects rather than a custom package, so nothing needs installing in the org. In production today it is switched off, and these same records are computed and recorded as a dry run instead of being sent.

Task: The default shape for logged activity. Calls are written with a Call subtype and emails with an Email subtype, so they report as the native activity types your reports already count.
Event: Used where the activity is a scheduled meeting rather than a completed touch.

When a write is sent, mutations are addressed to the standard REST data API path for the target object, creating a record where there is no target id and updating that record where there is. Each write carries an idempotency key, so a retry after a network failure does not produce a second Task for one call.

When both systems changed the same field

The conflict is recorded rather than silently resolved, and the decision is reviewable. Neither system is treated as automatically correct, because the case that matters is the one where a rep edited the record in Salesforce while an agent was acting on it in SAGARIS.

If you are on HubSpot instead

HubSpot connects too, in the same posture: reading is live, and for HubSpot the write-back path runs as a dry run, switched off in production. The tier requirements HubSpot imposes on what an app may do inside a portal are set out on the HubSpot integration page.

What this connects to

Developers and integrations

Building on it? Bring your use case.

Book a demo