Identity and SSO
Objective. Be able to answer 'how do users sign in and can it use our identity provider?' at the right altitude - name the shape honestly, say what is safe to commit, and route every exact SSO, provisioning and identity-security question to a specialist without guessing.
Identity is usually the first IT question on any enterprise deal and the first thing a works-council or security review probes. This gives Sales and CSM a confident, honest high-level answer about sign-in and access, and a hard line at every specific SSO/provisioning claim - because the wrong promise here blocks a rollout or breaks a security review.
See it in the demo
What identity and SSO are in Time Champ terms
Identity is simply 'how a person proves who they are and gets the access that matches their role'. Everything downstream - which teams, sites, clients and screens a user can see - depends on that person being the right person with the right role (see PLAT-03 and F05). In the demos you can see that access is role-scoped and that RCM Insights even exposes a sample role sign-in, which demonstrates that the product thinks in terms of authenticated users mapped to roles and scope.
Single sign-on (SSO) means a customer's users sign in through the customer's own identity provider rather than a separate password per tool. For an enterprise buyer this matters for three reasons: it is one less credential to manage, it lets their IT enforce their own authentication policy, and it lets joiners and leavers be governed centrally. Those are the business concerns behind the question - keep the conversation there rather than on protocol detail you have not verified.
What a Sales or CSM person can say confidently
Safe to say: 'Users authenticate and are mapped to a role and scope, so each person sees only the slice of the organisation their role allows.' That is demonstrably how the product behaves.
Safe to say: 'Enterprise sign-in and provisioning are standard topics we handle with your IT - I will bring in our specialist so we commit to exactly what your environment needs rather than something approximate.' Framing the specialist as precision, not delay, is the credible move.
Safe to position for CSM: at onboarding, confirming the right people hold the right roles is step zero of trust - before any dashboard is believed, the access model has to be correct (F05, C02).
Do not name specific protocols, identity providers, token behaviours, MFA enforcement or auto-provisioning as supported or not supported. You almost certainly cannot verify the exact answer for a given customer's environment, and a wrong 'yes' here surfaces painfully during security review.
What always escalates to security or product
Route to a specialist, every time, without a provisional answer:
- Whether a specific SSO protocol or a specific identity provider is supported for this customer.
- Multi-factor authentication enforcement, session and token lifetime, and conditional-access behaviour.
- Automated user provisioning and de-provisioning (joiner/mover/leaver) and directory sync.
- Password, lockout and credential-recovery policy.
- Anything a security questionnaire or RFP asks about authentication controls.
The rule from F09 applies in full: never guess on identity security. 'I will get you the precise answer' is always stronger than an approximate commitment that a security team later disproves.
The honest limit
What the demos support: the product authenticates users and maps them to role and scope, and role-scoped sign-in is shown. That is the ceiling of what you can assert from the demo.
What the demos do not establish: the exact SSO/identity-provider support matrix, provisioning automation, MFA and session policy, and credential security for a specific customer. Treat all of these as configuration-and-security facts owned by product and security.
Separate cleanly: 'the platform is built around authenticated, role-scoped users' (safe) from 'your identity provider and your MFA policy will work exactly like this' (confirm with product/security).
Interpretation check
Showing that the product authenticates users and maps them to role and scope is not the same as committing to a specific SSO protocol, identity provider, MFA policy or provisioning behaviour - the first is demo-supported, the second is always a product/security confirmation.
In the field
In a ~6,000-seat account like KnackGlobal, IT will ask about SSO and provisioning early; the credible move is to confirm the role-and-scope model, then bring a specialist to commit to the exact identity integration rather than risk an approximate promise in a security review.
Practical task
Draft the two-sentence answer you would give an enterprise IT lead who asks about sign-in and SSO: one sentence stating what is true (authenticated, role-scoped users) and one sentence routing specifics to a specialist. Then list the five identity questions you will never answer yourself.
Self-check
A prospect's IT lead asks 'does it support our identity provider and enforce our MFA policy?' What do you say?
Confirm the product authenticates users and maps them to role and scope, then route the exact identity-provider, SSO and MFA questions to a specialist so the commitment is precise - do not answer yes or no from memory.
Why is a wrong 'yes' on SSO support especially damaging?
Authentication claims are checked in security review and implementation; an approximate commitment that fails there blocks the rollout and costs trust, whereas a specialist answer is simply accurate.
What identity facts are safe to state from the demo alone?
That users are authenticated and mapped to a role and scope, and that role-scoped sign-in is shown - nothing about specific protocols, providers, MFA, session policy or provisioning.
Name two identity topics that always escalate.
Any of: specific SSO/identity-provider support, MFA enforcement, session/token lifetime, automated provisioning/de-provisioning, password and recovery policy, or any security-questionnaire authentication item.
Verified vs demo. Authenticated, role-scoped users with sample role sign-in are shown in the demos; specific SSO/identity-provider support, MFA and session policy, and automated provisioning are product/security facts to confirm, never asserted.