Workforce Rollout Detail
A live rollout plan for company-email onboarding, employee approvals, organization channels, and direct-deposit readiness.
The rollout detail page should make the active company onboarding template visible from the first screen.
Batch size and pending approvals belong on the rollout detail page, not a hidden config lane.
The launch owner should always know the next rollout checkpoint without opening a second planning tool.
That gives operations, security, and the program owner one shared surface for understanding what is about to go live and which employees will be touched first.
That way the organization can see whether it is actually ready to onboard people instead of discovering missing approvals after employees already tried to join.
That is especially important when one company is running several parallel workforce launches with different permissions, market groups, and onboarding templates.
{
"rollout_id": "wrk_rollout_q2_northstar",
"organization_id": "org_northstar_logistics",
"template": "northstar-launch-q2",
"domains": ["northstar.example"],
"invite_batch_size": 840,
"pending_access_requests": 46,
"blocked_company_aliases": 3,
"next_launch_checkpoint": "2026-03-18T13:00:00Z"
}A rollout detail view should combine launch readiness, employee access state, and the linked payroll/wallet program in one operator surface.
The launch detail should show exactly how much queue pressure is left before the wave goes live.
Email-domain and alias restrictions should be visible before the invite batch is sent.
The rollout owner needs the next checkpoint on the first screen, not hidden in a side menu.
The current employee invite wave should stay visible from the rollout detail page.
The employee-approval wave linked to this launch remains one click away.
Direct-deposit adoption and wallet setup are part of the same rollout, not a disconnected finance task.
The active onboarding template stays visible so operators know which employee experience is shipping.
The initial company-email batch is already out, so the real bottleneck is no longer invite send volume.
Most of the cohort is already inside the workspace, but the remaining queue still matters before launch day.
Payroll-linked wallet setup is moving more slowly than approval throughput right now.
The current batch moved into the employee inboxes with role and department tags attached.
Operations, finance, and managers meet on the next rollout checkpoint before the next approval wave.
The organization markets and channel templates are reviewed before the employee cohort fully opens.
A workforce rollout should show the exact company domains, onboarding template, permission model, and market groups the organization is preparing to launch.
That gives operations, security, and the program owner one shared surface for understanding what is about to go live and which employees will be touched first.
The detail view should keep invite batch size, approval owner, pending requests, and any blocked company-email ranges visible before the first employee invite goes out.
That way the organization can see whether it is actually ready to onboard people instead of discovering missing approvals after employees already tried to join.
A rollout detail page should connect directly to the employee queue and payroll-linked wallet program that support the same launch. Those links keep setup work tied to the exact rollout instead of scattering it across unrelated admin views.
That is especially important when one company is running several parallel workforce launches with different permissions, market groups, and onboarding templates.