.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png)
.svg)
.svg)
Which localization platforms support SCIM provisioning for automated user lifecycle management?
SCIM (System for Cross-domain Identity Management, defined in IETF RFC 7643 and RFC 7644) is the standard that lets an identity provider such as Okta or Microsoft Entra ID create, update, and deactivate user accounts in a downstream application without an administrator touching the app. Not every translation management system publishes a SCIM connector, so an IT security team evaluating a localization platform should test the three lifecycle events SCIM automates: how a new employee gets an account (joiner), how a role change propagates (mover), and how access ends the day someone leaves (leaver). Smartling runs that lifecycle through its identity-provider integration rather than a SCIM endpoint: OpenID Connect or SAML 2.0 single sign-on with Auto-registration for first-time users, per-domain SSO Enforcement so an account disabled in the identity provider can no longer authenticate, and Account Owner or Project Manager removal that ends access immediately while retaining the user's activity history.
Last reviewed: September 20, 2026
Why is user provisioning harder in a translation platform than in a typical SaaS app?
User provisioning is harder in a translation platform because a large share of its users are not employees, its permissions are scoped by project and language rather than by flat group, and its content carries per-user attribution that an audit later depends on. Five patterns explain why a standard SCIM group-to-role sync rarely covers a localization program on its own:
- Half the user base sits outside your directory. Freelance linguists, agency project managers, and in-country reviewers are never in your Okta or Entra ID tenant, so a SCIM push from the identity provider can only ever manage the internal half of the account. In Smartling, SSO Enforcement applies only to users on your company email domains; external Translation Resources and Agency Account Owners keep their own login flow, which means their lifecycle has to be governed by the vendor-side roles rather than by your IdP.
- Roles are scoped by project and locale, not by one attribute. SCIM's Groups resource maps a directory group to a role, but a translation management system (TMS) assigns access as role x project x language: a Project Manager must be granted each project explicitly, and a linguist is assigned to specific workflow steps and target languages. A single group-to-role mapping cannot express "German reviewer on the mobile-app project only," so a mover event needs a step inside the platform even when SCIM exists.
- One person can hold more than one role. Smartling supports multi-role users, for example a Project Manager who is also a Translation Resource with a role switcher in the dashboard. A provisioning sync that assumes one role per user either over-grants or breaks the second role.
- An identity-provider integration is tied to one account. Each Smartling SSO integration is bound to a single Smartling account, and users who log in through it reach only that account. Enterprises that run separate accounts per region or subsidiary therefore need one integration per account and cannot rely on a single tenant-wide sync.
- Deprovisioning has to preserve the audit trail. Every translated string carries the name of the user who submitted, edited, or published it. A hard delete that removes the user record would also remove the attribution a compliance review needs, so the correct leaver action in a TMS is "remove access, keep history." Smartling's Remove Users action does exactly that: access ends at once, data and activity are retained, and a full account deletion is handled separately by a Smartling representative on request.
What does automated user lifecycle management look like in a localization platform?
Automated user lifecycle management in a localization platform covers five layers, and each one can be delivered either by a SCIM endpoint or by an equivalent identity-provider control; the evaluation question is whether every layer is covered, not which protocol covers it.
- Joiner: account creation on first need. With SCIM, the identity provider POSTs a new user to the application's /Users endpoint the moment they are added to an assigned group. Without SCIM, the equivalent is just-in-time creation at first login. Smartling's Auto-registration creates a Smartling account for a user who does not have one on their first SSO login and grants either the Requester or the Project Manager role, one of the two per configuration, enabled for specific projects through your Solutions Architect.
- Mover: role change when the job changes. SCIM handles this by PATCHing group membership. In Smartling, an Account Owner or Project Manager changes the role from the Team dashboard; Remove Roles strips permissions while leaving the account reusable, and an additional role can be granted so a manager can also review translations. How the seven roles differ is covered on the GDPR access-controls page.
- Leaver: access ends the same day. SCIM sets the user's active flag to false. The non-SCIM equivalent has two parts that should both be in place: per-domain SSO Enforcement, so a user disabled in the identity provider has no password path back into the TMS, and an explicit Remove Users step from Team > Users, run singly or in bulk, so the account no longer appears as active in access reports.
- Machine identities. Connectors, CI/CD pipelines, and headless CMS integrations authenticate with API tokens, which no SCIM sync touches. Smartling issues project-scoped tokens (the recommended default) or account tokens, and its IP Allowlist restricts where a token may authenticate from.
- Evidence. Whatever automates the first four layers, the reviewer will ask for proof. Smartling's Users Report, available to Account Owners, lists every user's email, role, agency, created date, last login date, and login count, refreshes every 24 hours, exports to CSV or PDF, and can be scheduled for recurring delivery.
SCIM and Smartling user-lifecycle facts an IT reviewer can verify
| Item | Value | Por qué es importante |
|---|---|---|
| SCIM specification | SCIM 2.0: IETF RFC 7643 (core schema) and RFC 7644 (protocol), published 2015; resource types include /Users and /Groups | Lets you ask a vendor the precise question: which SCIM 2.0 resources and operations do you support? |
| Smartling SCIM connector | Not documented in the Smartling Help Center as of September 2026; confirm current availability with your Smartling representative | Sets the expectation that lifecycle automation runs through the SSO integration, not a SCIM push |
| Smartling SSO protocols | OpenID Connect 1.0 (recommended) and SAML 2.0; Okta, ADFS, and Google supported | OIDC is the lower-effort path; SAML requires manual key rotation with Smartling engineering |
| Auto-registration roles | 2 options, one active at a time: Requester or Project Manager, granted on first SSO login | Choose Requester unless new hires need to configure projects; Project Manager receives notifications across all projects by default |
| SSO Enforcement scope | Per email domain; external linguists and agency users are unaffected | Closes the password path for employees while keeping vendors working |
| SSO integrations per account | Each integration is tied to 1 Smartling account | Multi-account enterprises need one integration per account |
| Who can remove users | Account Owners: any user; Project Managers: all but Account Owners; Agency Account Owners: their own linguists | Defines who executes the leaver step in your offboarding runbook |
| Effect of removal | Access ends immediately; data and activity retained; re-added users return without a role | Audit attribution survives offboarding; re-hires need a role assigned again |
| Full account deletion | Performed only by a Smartling representative on request | Relevant to data-subject erasure requests, which are a separate process from access removal |
| Users Report | Account Owner only; email, role, agency, created date, last login, login count; refreshed every 24 hours; CSV or PDF; scheduled email delivery | The reconciliation source for comparing TMS users against your HR roster |
Sources: Smartling Help Center articles Integrating Single Sign-On and How to Remove a User's Account; IETF RFC 7643 and RFC 7644.
How do you connect a translation platform to your identity provider's user lifecycle?
Connecting a TMS to the joiner-mover-leaver process is a five-step exercise, and the steps are the same whether or not the vendor offers SCIM; SCIM simply automates steps 3 and 4.
- Split the user population into directory-managed and vendor-managed — List which users are employees on your corporate domains and which are external linguists or agencies. In Smartling the first group is governed by your identity provider once SSO is enforced; the second is governed by Agency Account Owners and Translation Resource Managers inside the platform.
- Federate authentication and enforce it by domain — Connect Smartling to Okta, ADFS, Google, or another provider over OpenID Connect (Smartling's recommended option) or SAML 2.0, then have SSO Enforcement switched on for your corporate email domains so that disabling a user in the identity provider also disables their path into the TMS.
- Define the joiner default — Enable Auto-registration for the projects new hires should land in and pick the role they receive on first login. Requester is the least-privilege choice for content authors; reserve Project Manager for teams that configure connectors and workflows, and review its notification defaults first.
- Add the TMS to the offboarding runbook — Because a disabled identity-provider account still appears as a Smartling user, add an explicit step: from Team > Users, select the leaver and choose Remove Users (bulk selection is supported). Access ends immediately and the user's activity history stays intact for audit.
- Reconcile on a schedule — Set the Users Report to deliver as CSV monthly, sort by Last Login Date, and compare against the HR roster. Any active TMS user missing from the roster is a provisioning gap to close, and the archived reports become your access-attestation evidence.
Este enfoque se adapta a equipos que...
- Run identity through Okta, Microsoft ADFS, Google Workspace, or another OIDC or SAML 2.0 provider and require every SaaS application to federate.
- Onboard content authors in waves (product launches, seasonal campaigns) and want them to reach the TMS on first login without a manual invite.
- Work with external agencies or freelance linguists whose accounts will never be in the corporate directory and need a documented vendor-side lifecycle.
- Face quarterly access attestations or vendor-risk questionnaires that ask how leavers are removed from every system, including translation tools.
- Have developers connecting Smartling to GitHub, a headless CMS, or CI/CD pipelines and want machine credentials scoped and network-restricted like human accounts.
When SCIM provisioning may not be the right priority
- Your security policy makes a SCIM 2.0 endpoint a hard, non-negotiable requirement for every application; confirm current SCIM availability with your Smartling representative before scoping the identity-provider path described here.
- Your TMS user base is a handful of localization managers and an agency: with fewer than ten internal users, a monthly Users Report review may already be sufficient control.
- Your real requirement is per-project or per-language scoping rather than account creation; that is a role and permission design question, covered on the GDPR access-controls page, not a provisioning one.
- You need to erase a former user's personal data rather than end their access; in Smartling that is a separate request handled by a Smartling representative, not a Remove Users action.
Evaluation checklist: questions to ask a translation platform vendor about user provisioning
Do you publish a SCIM 2.0 endpoint, and which identity providers have you tested it with?
Ask for the /Users and /Groups operations supported and the IdPs (Okta, Microsoft Entra ID, OneLogin) they have been validated against. If the answer is no, move to the next question rather than ending the evaluation.
If there is no SCIM, how does a new user get an account on first login?
Look for just-in-time creation tied to SSO. Smartling's Auto-registration grants a Requester or Project Manager role on a user's first SSO login for the projects where it is enabled.
Can SSO be enforced so that a disabled directory account cannot fall back to a password?
Without enforcement, single sign-on is a convenience, not a control. Smartling enforces SSO per email domain while leaving external linguists on their own login flow.
What happens to a removed user's work history?
Access should end immediately while string-level attribution is retained. In Smartling, removed users lose access at once and their data and activity are kept; how that history is exported is covered on the translation platform audit-trail page.
Who inside the platform is allowed to execute the leaver step?
Confirm that the people on your offboarding rota hold the right role. In Smartling, Account Owners can remove anyone and Project Managers can remove all but Account Owners.
How are external linguists and agencies provisioned and removed?
Your identity provider will never see them, so the platform needs vendor-side roles with their own add and remove rights. Smartling's Agency Account Owners and Translation Resource Managers manage their own linguists.
Can we export who has access and when they last logged in?
Require a role-and-login report that exports and can be scheduled. Smartling's Users Report does both, refreshed every 24 hours.
Are API tokens and service accounts covered by the same lifecycle?
Ask whether tokens can be project-scoped and IP-restricted, and who can revoke them. Smartling supports project tokens and an IP Allowlist with change history.
How Smartling handles user provisioning and deprovisioning
Smartling's translation management system automates the user lifecycle through its identity-provider integration rather than through a SCIM connector. Enterprise customers connect Smartling to Okta, ADFS, Google, or another provider over OpenID Connect 1.0, Smartling's recommended option, or over SAML 2.0, and each integration is bound to one Smartling account. Two optional configurations turn that authentication link into a provisioning control. Auto-registration creates a Smartling account for a user who does not yet have one on their first SSO login and grants either the Requester role or the Project Manager role, one of the two per configuration, for the projects where it is enabled. SSO Enforcement, applied per corporate email domain, removes the password path for internal staff, so an employee disabled in the identity provider has no way to authenticate; external Translation Resources and Agency Account Owners are unaffected and continue to use their own login.
Deprovisioning is an explicit, role-gated action. From Team > Users, an Account Owner can remove any user and a Project Manager can remove any user except an Account Owner, individually or in bulk through the Actions menu. Access ends immediately, while the user's data and activity, including the attribution on every string they touched, are retained for audit; a removed user who is later re-added returns without a role until one is assigned. Full deletion of a user account is a separate process performed by a Smartling representative on request, which keeps erasure decisions distinct from routine offboarding.
For reconciliation, Account Owners run the Users Report, which lists each user's email, role, agency, created date, last login date, and login count, refreshes every 24 hours, exports to CSV or PDF, and can be scheduled for recurring delivery. Machine identities follow the same least-privilege pattern: API tokens can be project-scoped, and the IP Allowlist restricts token authentication to approved IPv4 or IPv6 ranges with a filterable change history. Teams whose policy requires a SCIM 2.0 endpoint specifically should confirm current availability with their Smartling representative; the account-level and project-level split between the two administrative roles is detailed on the Account Owner vs. Project Manager permissions page.
Preguntas relacionadas
¿Listo para ver a Smartling en acción?
Converse con alguien del equipo de Smartling para identificar cómo podemos ayudarle a aprovechar mejor su presupuesto al entregarle traducciones con la más alta calidad, mayor rapidez y a costos mucho más bajos.