Cohesio fits next to your stack, not instead of it

• GD

  Google Drive

  Once connected, every accepted original and every signed manifest mirrors into a Google Drive folder structure that matches your existing client organization — no new taxonomy for your team to learn. The sync is one-directional, Cohesio to Drive, and fires the moment an item is accepted or an engagement closes, so files land in Drive within moments of the decision, not on a batch delay. Permissions requested are limited to creating and writing files inside a folder you designate; Cohesio never reads or lists the rest of your Drive.

  Setup: Point it at an existing folder from Settings → Integrations → Google Drive.

• Db

  Dropbox

  Dropbox behaves identically to Google Drive: accepted originals and manifests mirror one-directionally into a folder your firm already uses, triggered by acceptance and close events rather than a scheduled sync. The Dropbox app permission requested is scoped file access to the single app folder (or a shared folder you designate), so Cohesio can write there without visibility into anything else in the account. This is the right choice for firms that standardized on Dropbox before ever adopting Cohesio and don’t want a second storage habit.

  Setup: Authorize the app folder from Settings → Integrations → Dropbox.

• SP

  SharePoint & OneDrive

  For Microsoft 365 firms, accepted originals and manifests mirror into a per-client SharePoint or OneDrive library rather than a generic folder, and any retention label already applied at the library or folder level is honored rather than overridden. The connector authenticates through the same Microsoft account used for Entra ID SSO where that’s configured, avoiding a second consent flow. Direction is one-directional from Cohesio, triggered on acceptance and close; permissions requested are limited to reading library structure and writing files, not full Graph API access to mail or calendars.

  Setup: Pick the target library per client from that client’s Integrations tab.

• G

  Gusto

  The Gusto connector pulls payroll summary data — gross pay, tax withholding and net pay totals by period — directly into an engagement instead of asking the client to export and upload it themselves. It’s read-only and one-directional: Cohesio never writes to Gusto or touches payroll administration, run approval, or employee records. The trigger is engagement issuance for a client with a linked Gusto account; summary data becomes available as soon as Gusto’s own payroll run for that period is finalized. The OAuth grant requests read-only access to payroll reports for the connected company.

  Setup: Link a client’s Gusto company once from that client’s Integrations tab.

• GW

  Google Workspace SSO

  Staff sign in with their existing Google Workspace account instead of a separate Cohesio password, and role assignment maps automatically from Google Groups membership to Cohesio roles — add someone to the right group, and their access is correct the moment they first sign in. This is identity federation only: Cohesio doesn’t read mail, calendar or Drive content through this connection, only the identity assertion needed to authenticate. The admin console grant requests domain-wide delegation limited to SSO and directory group membership.

  Setup: Configure the SAML app in your Google Workspace admin console, then map groups to roles in Settings → Security.

• E

  Microsoft Entra ID

  Microsoft Entra ID (formerly Azure AD) provides SAML single sign-on plus SCIM provisioning, meaning group membership changes in Entra automatically add or remove the corresponding Cohesio seat and role — there’s no separate offboarding step for a firm admin to remember when someone leaves. The connection is bidirectional in one specific sense: Cohesio both accepts SAML assertions for sign-in and receives SCIM push updates for provisioning, but never reads mail, files or other Microsoft 365 data. Available on the Scale plan, where seat provisioning ties into the plan’s staff limits.

  Setup: Generate SAML metadata and a SCIM token from Settings → Security → Single sign-on.

• engagement.issuedFires when an onboarding or monthly engagement is created and the client’s checklist link is sent.
• item.receivedFires the moment a client submits a file or answer against a specific requirement, before AI extraction runs.
• item.acceptedFires when a staff reviewer accepts an AI-proposed fact or a client submission as-is.
• item.correction_requestedFires when a reviewer sends a submission back to the client with a specific, cited reason.
• item.waivedFires when a reviewer waives a requirement instead of accepting a submission for it, with the reason attached.
• exception.raisedFires when AI extraction flags a likely mismatch between a submission and expected values, before any human decision.
• engagement.closedFires when a reviewer signs the decision manifest and the engagement is handed off as complete.
• client.createdFires when a new client record is added, whether created manually or through bulk import.

{
  "event": "item.accepted",
  "workspace_id": "wksp_7f2a...",
  "engagement_id": "eng_9c31...",
  "item_id": "item_4b08...",
  "occurred_at": "2026-09-15T14:22:07Z",
  "data": {
    "requirement": "Merchant processor statement",
    "accepted_by": "staff_2a91...",
    "source": {
      "document": "square-statement-aug-2026.pdf",
      "page": 2,
      "version": 1
    }
  }
}