INTEGRATIONS
Read what is true. Change what is approved. Reread what became true.
Every listed connector has operated inside a live SupraOS transition. Customer systems remain authoritative; the operating contract defines what can enter, move and count as completed.
READAccount, opportunity, renewal and commercial state
ACTApproved field, stage and ownership changes
OBSERVEObject version, fields and resulting commercial state
PRODUCTION OPERATING CONTRACT
Each connector declares five things before the first write.
Logos do not establish enterprise readiness. The repeatable boundary is what SupraOS reads, what it may change, who authorizes the move, how completion is checked and what evidence remains.
| System | What SupraOS reads | What may change | Who authorizes it | How completion is checked | What remains |
|---|---|---|---|---|---|
| Salesforce | Account, opportunity, renewal, owner and commercial state | Approved field, task, stage and ownership changes | Customer policy or named revenue authority | Object version, field values, links and resulting commercial state are reread | Transition Receipt and audit trail |
| Zendesk | Cases, incidents, commitments and customer evidence | Approved ticket, escalation and evidence actions | Service policy or named support authority | Status, owner, evidence and persistent closure are reread | Transition Receipt and audit trail |
| Snowflake | Usage, finance, product and customer-defined facts | Usually read-only; scoped evidence preparation where approved | Data-owner policy or named data authority | Facts are reconciled against the completed operating state | Source lineage and evidence references |
| Slack | Decisions, ownership and collaboration context | Assignments, notices and bounded approval requests | Workspace policy or named operating owner | Delivery and thread state are checked; the commercial result is verified in its source | Decision and execution trail |
| ServiceNow | Incidents, changes, approvals, owners and remediation state | Approved workflow, change and task actions | Customer workflow policy or named change authority | Destination state, deadline, evidence and delayed obligations are reread | Transition Receipt and audit trail |
| Jira | Defects, dependencies, releases and evidence | Priority, assignment, linkage and approved issue changes | Product or engineering policy, or named owner | Issue version, status, assignee, links and release state are reread | Transition Receipt and change history |
| Ironclad | Contract, approval, obligation and artifact state | Approved contract-workflow actions | Legal policy or named contracting authority | Status, final artifact and obligation confirmation are reread | Transition Receipt and contract audit trail |
Customer-defined APIs remain supported. Their read, action, authority, readback and evidence boundary is defined by the customer interface before execution.