Intercom Scim
You set up intercom scim by linking your identity provider to your support workspace. This link creates, updates, and removes seats when staff join or leave your company. Teams use this flow to stop manual account work and cut down on old logins. Yet identity groups often map to broad workspace roles that grant too much power. When every support agent gets admin rights by default, one bad action can expose customer data. How intercom scim works in your identity stack The System for Cross-dom
Scim: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up intercom scim by linking your identity provider to your support workspace. This link creates, updates, and removes seats when staff join or leave your company.
Teams use this flow to stop manual account work and cut down on old logins. Yet identity groups often map to broad workspace roles that grant too much power. When every support agent gets admin rights by default, one bad action can expose customer data.
How intercom scim works in your identity stack
The System for Cross-domain Identity Management is an open standard for user sync. Your identity provider acts as the single source of truth for all staff profiles. When HR adds a new hire, the identity tool sends a web request to the support app. The support app reads this request and builds a new user profile right away.
To make this work, admins generate a secret token inside the support workspace. They paste this token and a target URL into their identity provider settings. Both systems now share a trusted link for user updates.
Group mapping handles role assignments across the team. Admins link identity groups like Tier One Support to matching roles inside the support app. When a user moves to a new department, their group changes in the identity tool. That tool then tells the support app to swap the user role to match.
Deprovisioning follows the exact same path in reverse. When an employee leaves the company, an admin turns off their main identity profile. The identity provider sends a disable signal to the support app within minutes. The app revokes the user seat and ends their active web sessions.
What identity sync solves and what it misses
Automated user sync fixes the problem of orphaned accounts across your SaaS tools. Security teams no longer need to hunt down old logins after an employee exits. It also saves hours of manual setup work for IT staff during busy hiring weeks. Auditors can check one central directory to see who holds a seat in the support app.
Scim: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, user sync only controls who can log in and which static role they hold. It stops at the front door and cannot see what users do inside the app. Once a support agent logs in, their standing role stays active all day long.
Support workspaces hold sensitive customer data like emails, phone numbers, and card numbers. An agent or developer with a broad role can view or export these records at any time. Syncing user seats does not block a rogue query or a bulk data download.
Engineers also build internal tools and scripts that talk to the support API. These backend jobs often use shared tokens that sit outside the identity sync loop. User provisioning does not watch database queries, API calls, or terminal commands run during a support ticket.
Managing day-to-day support and backend tasks
Real security needs controls that work while people run commands and read records. Static roles from an identity sync are too blunt for daily backend work. A developer fixing a bug might need to check one customer record for five minutes. Giving them a permanent group role exposes the whole database every single day.
Teams should separate seat creation from live data work. Let the identity provider handle basic app seats and sign-in rules. Then add step-up checks and field masking for actual queries against production systems. When a script or engineer queries user data, masking rewrites matched fields like emails and phone numbers in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does intercom scim sync custom user attributes?
It syncs core profile fields like name, work email, and group membership. Support teams rely on group mappings rather than custom attributes to set workspace permissions.
What happens to open tickets when SCIM removes a user?
When the identity provider sends a removal signal, the workspace revokes the user seat right away. Their assigned conversations stay in the workspace so managers can route them to active staff.
Can we use SCIM without single sign-on enabled?
Most identity providers require you to turn on SAML single sign-on before you set up user sync. Single sign-on checks who the user is, while provisioning manages their account lifecycle.