Identity Proxy
Messages appear from the correct sender across all platforms. No anonymous bot accounts, no 'via SyncRivo' suffixes — users see the right name and avatar on every platform.
The guest account problem
Traditional cross-platform messaging integrations solve identity in one of two costly ways: every sender becomes an anonymous bot account (destroying attribution), or every sender requires a full guest account on the destination platform (creating directory sprawl and licensing overhead). An enterprise with 500 Slack users connecting to a Teams organization should not need 500 Teams guest licenses just to preserve sender names. SyncRivo's identity proxy solves this at the routing layer — no guest accounts, no bot ambiguity.
How SyncRivo's identity proxy works
- Display name mappingSyncRivo maintains a per-integration identity map between source and destination user profiles. When a message is routed, the sender's display name is carried through to the destination platform's message attribution field.
- Platform-native attributionAttribution uses each platform's native mechanism: the Teams displayName field, Slack's username, Google Chat's displayName, and so on. This means identity displays correctly in native platform UIs — not as a suffix or metadata annotation.
- No directory sync requiredSyncRivo's identity proxy does not require user directory synchronization between platforms. Identity mapping is resolved at message routing time using lightweight profile data, not a full AD/LDAP sync.
Benefits
- No Teams guest licenses needed
- No Slack guest account sprawl
- Messages attributable in audit logs
- RBAC controls per integration
How the Identity Proxy works in SyncRivo
SCIM provisioning and OIDC/SAML binding
At tenant onboarding, SyncRivo connects to the customer's identity provider (Okta, Azure AD/Entra ID, Google Workspace, OneLogin) via SCIM 2.0 for user and group provisioning, and OIDC or SAML 2.0 for authentication. Each user is assigned a stable syncrivo_subject claim that is independent of any messaging platform's local user ID — this claim becomes the root of the identity map. When an IdP deprovisioning event fires (user offboarded), the SCIM active: false flag is propagated within seconds, and all bridged destinations stop attributing new messages to that user.
Per-platform identity mapping and resolution
When a message arrives from a source platform, SyncRivo resolves the sender's syncrivo_subject by looking up the platform's native user ID (Slack U01XYZ, Teams AAD object ID, Google Chat users/12345, Zoom zoid, Webex person ID) in the tenant-isolated identity map. The routing engine then resolves the corresponding native user ID on every destination platform and sets the outbound message's display name, avatar URL, and profile link accordingly. Mapping lookups happen in-memory with a sub-millisecond cache fed from Postgres — identity resolution adds under 2ms to the routing hot path.
RBAC, audit, and display-name attribution
The identity map is governed by RBAC policies: only tenant admins with the identity:write role can create or modify mappings, and every change is recorded in the compliance audit log with actor, before/after values, and timestamp. At delivery time, messages are posted using each platform's native display-name override — Slack's username and icon_url fields, Teams' Bot Framework from.name, Google Chat's Chat app sender override, Zoom's bot name parameter, Webex's person-proxy markdown — so users see the correct human attribution in every native client, not a generic "via SyncRivo" suffix.
Platform-specific behavior
Here is how the Identity Proxy behaves across each messaging platform we support. Attribution fidelity depends on each platform's bot API for display-name impersonation.
| Platform | Behavior | Known limitation |
|---|---|---|
| Slack | Full display-name and avatar override via chat.postMessage username/icon_url; profile link points to Slack user. | Enterprise Grid shared channels require bot to be installed per workspace for attribution to resolve. |
| Microsoft Teams | Bot Framework from.name override; per-message avatar via Adaptive Card sender block. | Teams strips third-party avatar on older desktop clients — default bot icon shown as fallback. |
| Google Chat | Chat app posts with senderDisplayName override and avatar from People API lookup. | Google Chat enforces a "Via app-name" badge that SyncRivo cannot remove — visible but muted. |
| Zoom Team Chat | Bot name parameter set per-message; avatar loaded from Zoom Contacts API. | Zoom does not support per-message avatar override — bot-level avatar is used for all users. |
| Cisco Webex | person-proxy markdown plus actorDisplayName field on card posts; profile link opens Webex person card. | Webex compliance org requires bot to be added to compliance officer allow-list before identity override activates. |
Three-Platform Bridges
Slack + Teams + Google Chat
Bridge all three major enterprise messaging platforms.
Slack + Teams + Webex
Connect Slack and Teams users with Cisco Webex.
Slack + Teams + Zoom
Unify Slack, Teams, and Zoom Team Chat.
Slack + Google Chat + Zoom
Three-way bridge for Slack, Google Chat, and Zoom.
Slack + Google Chat + Webex
Unify Slack, Google Chat, and Cisco Webex.
Slack + Zoom + Webex
Bridge Slack with both Zoom and Webex.
Teams + Google Chat + Zoom
Connect Teams, Google Chat, and Zoom Team Chat.
Teams + Google Chat + Webex
Bridge Teams, Google Chat, and Cisco Webex.
Teams + Zoom + Webex
Unify Teams, Zoom, and Webex in one bridge.
Google Chat + Zoom + Webex
Connect Google Chat with Zoom and Webex.
Ready to connect? Slack ↔ Teams connection setup →
Frequently asked questions
- What is an identity proxy in messaging integration?
- An identity proxy ensures that messages bridged between platforms display the original sender's name and identity — not a generic bot or service account. Without an identity proxy, all bridged messages appear from a single bot account, making conversations impossible to follow. SyncRivo maps sender identity across platform boundaries so Teams users see the Slack user's name, and Slack users see the Teams user's name.
- Does SyncRivo create bot accounts in Teams or Slack?
- SyncRivo uses a lightweight identity representation — not full guest accounts. Messages are attributed to the correct sender using platform-native display name features. This avoids the directory sprawl and license overhead of full guest accounts while maintaining conversation clarity.
- What happens to user identity in regulated environments?
- In HIPAA and SOC 2 regulated environments, SyncRivo's identity proxy works within your data governance policies. User display names are mapped but no PII is stored on SyncRivo infrastructure beyond the routing event's transit period. The identity mapping configuration is stored in your tenant-isolated routing database with RBAC controls.
Related integration guides
Three-Platform Bridges
Connect three enterprise messaging platforms simultaneously with SyncRivo's cross-platform bridges.