Cross-Platform File Sharing

The file sharing problem in multi-platform teams

When engineering shares a Figma export in Slack and the design review discussion happens in Teams, the file never crosses the bridge — colleagues in Teams have to ask for it to be re-shared, breaking the conversation flow. SyncRivo solves this by routing file attachments and their metadata bidirectionally, so shared content follows the message wherever it goes.

How cross-platform file routing works

• 1

  File event detection

  SyncRivo detects file_share events from each platform API in real time via native webhooks.

• 2

  Secure link generation

  SyncRivo requests a time-limited download link from the source platform API — no file content is transferred to SyncRivo infrastructure.

• 3

  Metadata extraction

  File name, MIME type, size, and preview thumbnail URL are extracted and included in the destination message payload.

• 4

  Native attachment rendering

  The destination platform receives the file attachment in its native message format — Slack's file block, Teams's attachment card, or Google Chat's Drive attachment — so it renders natively without appearing as a bare link.

How Cross-Platform File Sharing works in SyncRivo

Event ingestion and file-reference extraction

File-share events arrive via the same webhook pipeline that powers message routing: Slack file_shared events, Microsoft Graph change notifications for Teams messages with attachments, Google Chat Pub/Sub file events, Zoom Webhook file uploads, and Webex message events with attachment URLs. Each webhook is HMAC-verified and parsed into a canonical file reference: the source platform's native file ID, owner user ID, MIME type, size, and SHA-256 content hash if exposed. SyncRivo never copies the file bytes into its own storage — only metadata pointers move through the routing engine.

DLP scan-then-forward pipeline

On Enterprise plans with DLP enabled, SyncRivo streams the file through a per-tenant inspection gateway backed by the customer's DLP provider (Nightfall, Microsoft Purview DLP, or Google Cloud DLP via API). Scanning runs inside the tenant's region of record and blocks forwarding when a policy violation — PII, PHI, source code fingerprints, credential strings — is detected. Blocks surface to the sender as an ephemeral message in the source channel with a policy reason code, and the blocked file-share event is recorded in the compliance archive as a file_share_denied audit entry.

Secure link generation and delivery guarantees

For each allowed file-share, SyncRivo mints a pre-authenticated URL using the source platform's API: Slack files.sharedPublicURL scoped to bridged workspace users, Microsoft Graph createLink with anonymous-view TTL, Google Drive shareable link with domain restriction, or Zoom/Webex file-access tokens. URLs are time-bounded (default 7 days, configurable on Enterprise) and carry an idempotency key so webhook retries never generate duplicate links. The destination platform renders the attachment natively — Slack file block, Teams Adaptive Card, Google Chat card v2 — so recipients see a proper preview rather than a bare URL.

Platform-specific behavior

Here is how Cross-Platform File Sharing behaves across each messaging platform we support. File-link TTL and preview fidelity vary because each platform uses a different native storage system.