Roles and access control
Objective. Explain how access is scoped by role and organisation position so you can answer 'who can see what' honestly, use scope to size a deal, and route exact permission granularity to product rather than promising a fixed role matrix.
Access control is where the privacy promise is kept or broken and where many metric disputes begin. This teaches the role-and-scope model the platform is built on, what is safe to say about it, and the hard line at exact permission detail - because a wrong permission claim is both a trust and a compliance exposure.
See it in the demo
What roles and access control are in Time Champ terms
Access in Time Champ is scoped by role and by where a person sits in the organisation. An administrator configures collection, mappings, standards and permissions; a manager sees and acts within their team or site; an employee sees their own data and what policy exposes; a business user in RCM Insights operates within a role scope that bounds which data a question can reach. The RCM Insights demo makes this concrete with role-scoped data and a sample role sign-in.
The design truth to carry: it is role-and-scope, not all-or-nothing. The same dashboard correctly shows a team leader their team, a site head their site and an executive the enterprise, because scope is applied to one shared model (PLAT-02). Access control is therefore not a bolt-on; it is how the product keeps the privacy promise (F04) and how it keeps metrics meaningful inside a boundary (F05, F06).
What a Sales or CSM person can say confidently
Safe to say to an access question: 'Views are scoped by role and by where someone sits in the org - a team leader sees their team, not the site next door. The shape is role-and-scope, not everyone-sees-everything.' That is demonstrably how the product behaves.
Safe for sales scoping: a tightly scoped start (one site, one process, one client) is more credible and easier to prove, and the access model is what makes that boundary real.
Safe for CSM: validating role and scope is step zero of trust. Before reconciling any metric, confirm the denominator population and the client/process boundary are modelled correctly and that access matches the customer's intended policy (C02, C05).
Do not promise a specific permission behaviour - who exactly can see which field, whether a custom role can be created, how granular a restriction can be. State the shape, not the matrix.
What always escalates to security or product
Route to a specialist:
- The exact production role definitions and permission granularity (field-level, action-level, record-level).
- Whether custom roles can be created and how finely access can be restricted for a specific customer.
- How role assignment integrates with the customer's identity provider and provisioning (links to PLAT-01).
- Any access-control item in a security questionnaire, including segregation-of-duties and least-privilege commitments.
- Whether a specific person or role can or cannot see a specific data category - never assert this without verification, because a wrong answer is simultaneously a trust breach and a compliance exposure.
From F09: never guess on access and security. The exact role matrix is a configuration-and-security fact.
The honest limit
Demo-supported: access is scoped by role and organisation position; administrator, manager, employee and business-user scopes exist; role-scoped data and sample role sign-in are shown.
Confirm with product/security: the exact role matrix, permission granularity, custom-role capability, provisioning integration and any least-privilege or segregation-of-duties commitment for a specific customer.
Separate cleanly: 'scope is a first-class concept here and access is role-and-scope' (safe) from 'your specific roles will behave exactly like this and user X cannot see field Y' (confirm with product). The first wins the trust conversation; the second, if wrong, loses the account.
Interpretation check
Access is designed to be bounded by role and org position - that shape is demo-supported - but the exact permission granularity for a given customer is a product/security fact; stating a specific permission behaviour you have not verified is both a trust and a compliance risk.
In the field
In a ~6,000-seat account like KnackGlobal, the CSM validates that each role sees only its intended team, client and payer scope before any cross-team comparison is shown - so a displacement story rests on correctly bounded, trusted data rather than a leaked view.
Practical task
Build a simple role-to-scope table for a sample account (administrator, manager, employee, business user) from the Work Output and RCM Insights demos. For each cell, mark whether you can state it from the demo or must confirm the exact permission with product before telling a customer.
Self-check
A customer asks whether a team leader can see another site's employee data. What is the responsible answer?
Views are designed to be scoped by role and org position, so a leader sees their own team rather than the site next door - with exact permission granularity confirmed with a specialist rather than promised on the call.
Why is a wrong access-control claim worse than most wrong claims?
It is simultaneously a trust breach (the wrong people seeing the wrong data) and a compliance exposure, so an unverified 'yes' or 'no' can both break employee trust and fail a security review.
How does the access model help a sales person size a deal?
Role-and-scope makes a tightly bounded start (one site/process/client) real and credible, so the smallest useful scope produces trusted numbers fast and de-risks expansion.
Which access facts are demo-supported and which escalate?
Demo-supported: access is role-and-scope with administrator/manager/employee/business-user scopes and role sign-in. Escalate: exact role matrix, permission granularity, custom roles, provisioning integration and any security-questionnaire item.
Verified vs demo. Role-and-scope access with administrator/manager/employee/business-user scopes and role sign-in is shown in the demos; the exact role matrix, permission granularity, custom-role capability and provisioning integration are product/security facts to confirm.