Time and Activity: Privacy and access
Objective. Understand what this screen governs - who can see what, and the capture and privacy posture - enough to support an employee-communication conversation and escalate deep policy to product.
This screen answers 'who is allowed to see which data, and what are the privacy boundaries?' It is where access scope and privacy posture are expressed, which matters for both trust and for what any given user actually sees.
See it in the demo
What this screen answers
A CSM opens this to answer 'what will a manager, a lead or an employee each be able to see, and does that match what we promised staff?' Sales uses it to answer the surveillance objection honestly. It is the screen that backs the 'this is about availability of paid hours, not keystroke voyeurism' story, and it also determines the scope of data a signed-in user is shown.
The task (validate, do not re-engineer)
Confirm at a high level that access scope matches roles - managers see their own org scope, not everything - and that the privacy posture aligns with what the customer told employees. The key CSM move is to pair this with an employee-communication plan during onboarding, so the deployment is transparent. Detailed role design, data-retention and capture-policy configuration are specialist and product decisions; capture requirements and escalate rather than setting policy yourself.
How to read it
Two things to read correctly. First, access scope changes what a number means to its viewer: a manager restricted to their team sees a different denominator than an admin, so two people can honestly quote different figures. Second, do not present this app as surveillance - frame it as availability and exception visibility with an agreed privacy boundary. Capture-policy specifics (what is and is not collected) must be confirmed with product for the customer's deployment, never asserted from the demo.
Honest limits
This is an admin and policy screen; exact access roles, retention and capture settings are specialist and must be confirmed with product. It governs visibility and posture, not the quality of any metric. Getting access scope wrong is a trust and compliance risk, not just a display issue, so treat substantive privacy or access changes as escalations with the customer's own security and HR stakeholders in the room.
Interpretation check
Access scope changes what a figure means to the person viewing it, and this app is availability-and-exception visibility with an agreed privacy boundary, not surveillance. Capture specifics must be confirmed with product, not claimed from the demo.
Practical task
In the demo, write a two-line answer to the surveillance objection grounded in this screen, and note the one capture-policy item you would mark 'confirm with product' rather than claiming.
Self-check
Two users quote different utilisation figures for 'the team'. How can both be right?
Access scope differs - a manager restricted to their org sees a different population and denominator than an admin. Confirm each person's scope before reconciling.
A prospect raises the surveillance objection. How does this screen help?
It shows the privacy boundary and access scope, letting you frame the app as availability and exception visibility, not keystroke monitoring, and anchors an employee-communication plan.
A customer asks exactly what is captured. What is the honest answer path?
Confirm capture-policy specifics with product for their deployment. Do not assert capture details from the demo.
A customer wants retention and role changes. What is the CSM move?
Escalate to product and bring the customer's security and HR stakeholders in. Access and privacy changes are trust and compliance decisions, not quick toggles.
Verified vs demo. Screen is live in the demo at /#/privacy; exact controls and figures are SME-validation-pending.