What’s the User Experience for End Users?

Users will need to access the account's TrackVia subdomain to utilize SSO. 

👀 NOTE: If you've checked the box to "Only Allow Single Sign On Authentication", inviting a new user to your account will automatically add them to the account. However, the user will NOT receive an invitation email with a link to join your account, and so it's recommended that Admins direct new users to the correct subdomain to log in to TrackVia after they've been added to the account. 

How Password Expiration interacts with SSO and API Users

API Users are not affected by the Security Policy tab

A user with the "Set as API User" checkbox checked is a special class of user that can only authenticate via API calls, using its associated Auth Token. This kind of user is not governed by the account's Security Policy tab (including password expiration) — instead, it's governed by the expiration of the Auth Token it's using.

This holds true regardless of the account's SSO configuration — whether SSO is off, enabled, or strictly enabled, an API User always authenticates with its Auth Token. (If a password was set on the user before it became an API User, that password is simply ignored — unless the user is later reverted back to a regular user, at which point the Security Policy tab governs it again.)

Regular users making API calls are still bound by the Security Policy tab

If a regular user (without "Set as API User" checked) is used for API access — for example, in a script or integration using plain username/password — that access is still subject to the Security Policy tab, including password expiration. If the password expires, whatever is authenticating with it will need to be updated with the new password.

Strict SSO requires an API User

Regular username/password authentication for API access is only supported when SSO is off, or when SSO is enabled without strict enablement. If Strict SSO is turned on, regular username/password can no longer be used for API authentication at all — you must use an API User with an Auth Token instead.

Before enabling Strict SSO: if anything integrating with your account (see the Workato example below) depends on regular username/password authentication, confirm it can be moved to an API User + Auth Token first — Strict SSO will otherwise cut off that access.

Why enable Password Expiration at all, if SSO is already enabled?

This depends on your organization's own security policies:

• If Strict SSO is not enabled, local (non-SSO) login is still available as a fallback — meaning users could bypass your SSO provider's password policy entirely by logging in locally instead. If your SSO policy requires a password change every 90 days, for example, enabling the same Password Expiration policy locally prevents users from working around that requirement through local login.
• If Strict SSO is enabled, local login is disabled, and the only Security Policy tab setting still enforced is session timeout — password expiration and the other local-login-related settings no longer apply, since there's no local login left to apply them to.

Can Roles be automatically assigned based on Active Directory data (e.g., group or job title)?

Not natively — TrackVia's automatic user provisioning creates the user profile, but it does not assign or create a Role based on Active Directory group membership or job title. Getting that behavior requires building it yourself with integration code; there's no built-in setting for it.

Two general approaches:

• Event-triggered: Have an event originate from TrackVia (for example, when a new user is created) that calls out to Active Directory to fetch that user's data, then updates their Role accordingly.
• Polling-based: If there's no TrackVia-side event to hook, use the Public API to build a polling mechanism instead — periodically check for new or unassigned users and update their Role based on data pulled from Active Directory.

Either approach is a custom integration you'd need to build (via a Microservice, App Script, or an external script against the Public API) — see Application Scripts and the TrackVia API overview for the building blocks.

SSO FAQs

🧠QUESTION - How do new user profiles get created in TrackVia? 
🎓ANSWER - A new user will be added in TrackVia when a new email address that isn't already associated with a user profile in TrackVia accesses your TrackVia account through the identity provider.

🧠QUESTION - Will enabling SSO have any impact on changing a user's status in TrackVia to "Inactive"?
🎓ANSWER - No, provisioning only works for creating new users. Users that are deactivated in the identity provider are not deactivated in TrackVia, and vis versa. 

🧠QUESTION - If a person's name changes (i.e. due to marriage), will their TrackVia user profile be updated to reflect the name change?
🎓ANSWER - Yes, if the email address in TrackVia matches the email address of the user who accesses the account through the identity provider, then the name will be changed in TrackVia.

Identity Provider Documentation

Azure Active Directory integration with TrackVia
Okta integration with TrackVia