Salesforce integration

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 live for Salesforce, gated by a deployed environment switch. The switch is a single environment flag, and 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.

What SAGARIS writes into your org

Activity is written as standard Salesforce objects rather than a custom package, so nothing needs installing in the org before a write can land.

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.

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, and its posture is different in one important way: for HubSpot the write-back path runs as a dry run. That difference, and the tier requirements HubSpot imposes on what an app may do inside a portal, are set out on the HubSpot integration page.