Administration & Management
Two kinds of administration exist and must never be confused:
| Platform administration | Tenant administration | |
|---|---|---|
| Who | Spyrl staff with platform roles (platform_admin, support_engineer, billing_admin, release_manager) | Client staff with tenant roles (org_owner, hr_admin, finance_admin and others, see CONVENTIONS §4) |
| Where | apps/admin console on the control plane (admin.spyrl.app), reachable only through Spyrl's IdP with MFA and a WAF IP allow-list | The tenant web app (<slug>.spyrl.app) |
| Data | Tenant registry, cells, plans, usage, flags, versions. No tenant business data by default | The tenant's own data |
| Access to the other side | Only through break-glass support access (below) | None; tenants cannot see the control plane except their own subscription, usage and access log |
This page deepens §4 and §15 of the architecture. Permissions are listed in the RBAC matrix.
1. Platform admin console
1.1 Tenants
| Function | Details | Permission |
|---|---|---|
| Search and view | By slug, legal name, owner email, cell, plan, status. Shows plan, active employees (today and billing-month max), usage, cell, version, health score, open tickets | plt.tenant.read |
| Lifecycle | Extend trial, suspend (read-only), reactivate, mark churned, schedule deletion, place or lift a legal hold. Suspension inside the payroll window (25th–5th) needs a second approver | plt.tenant.manage |
| Plan changes | Upgrade, downgrade, add-ons, per-tenant overrides (for example an employee limit of 520 for a negotiated deal). Downgrades preview which features and data become read-only | plt.plan.manage |
| Data lifecycle | Trigger full export, deletion, tenant move between cells | plt.tenant.manage + a second approver for deletion and moves |
| Notes | Implementation notes, contract references, DPA version | plt.tenant.read |
1.2 Cells
| View | Content |
|---|---|
| Cell list | Type (pooled/dedicated), isolation model, version, wave, tenants, active employees, DB CPU at last peak, DB size, Redis memory, queue age, error budget remaining |
| Capacity | Distance to each new-cell trigger (architecture §13): DB CPU 60% at peak, 500 GB, 300 tenants, 30k employees |
| Rollouts | Current wave, per-cell status (pre-check, migrating, deploying, verifying, done, halted), halt reasons, resume or abort (plt.release.rollout) |
| Maintenance windows | Per cell and per dedicated tenant; the orchestrator refuses to deploy wave 2 outside them |
1.3 Plans, entitlements and flags
- Plans (Lite, Standard, Professional, Enterprise) are defined as data:
plan→entitlement(feature_key, limit). Add-ons (Field Force, Timesheets, LMS, face verification, WhatsApp) are entitlement bundles. - Overrides are per tenant with an expiry date and a reason. An override without expiry needs
platform_admin. - Feature flags (release flags, kill switches, connector toggles) target tenants, cohorts, plans or cells. The console shows who changed what and when; every change is an audit event and, for behaviour changes, appears in the tenant change log.
- Kill switches are usable by on-call at any time (for example
kill.att.face_verificationif the face provider misbehaves). Using one opens an incident automatically.
1.4 Break-glass support access
Support engineers have no standing access to tenant data. Access is requested per ticket, time-boxed and visible to the tenant.
Rules
- Default scope is read-only, without sensitive fields (salary, bank, PAN, Aadhaar stay masked). Unmasking needs explicit consent for that scope.
- Read-write access is allowed only for a named task (for example "fix an import mapping") and needs consent in every case.
- Support sessions cannot approve workflows, run or approve payroll, generate bank files, change roles, or export data. The guard enforces this regardless of consent.
- Maximum duration 4 hours; one extension with renewed consent.
- The tenant sees an access log (who, when, why, what) under Settings → Security, and can revoke a session immediately.
- Monthly review: the security lead samples support sessions against tickets.
1.5 Statutory reference-data publishing
Statutory values (EPF/EPS/EDLI rates and wage ceilings, ESI rates and ceilings, PT slabs per state, LWF per state, TDS slabs, cess, standard deduction, rebate thresholds, minimum wages where tracked) are a versioned statutory pack published centrally.
- Each pack version has an effective date range and a change log with sources (circular number, gazette notification). Values are labelled "verify" until a second reviewer confirms them against the source.
- Payroll runs record the pack version used, so recalculating a past month uses that month's pack (upgrades).
- Packs are data, not code. A pack never ships inside an application release, so a mid-month rate change does not wait for the release train or the payroll freeze.
- Permission:
plt.statutory_pack.publish(held byplatform_admin; the payroll SME drafts with a dedicatedstatutory_editorcapability within the platform admin role set).
1.6 Health scores
Computed nightly per tenant and shown to customer success.
| Component | Weight | Signals |
|---|---|---|
| Activation | 30% | Readiness score, employees imported vs licensed, activation rate |
| Adoption | 30% | DAU/MAU, punches per active employee per working day, leave requests through the app, ESS logins after payslip release |
| Reliability | 20% | Failed jobs, payroll run errors, integration connectors failing, p95 latency for this tenant |
| Relationship | 20% | Open tickets and their age, NPS/CSAT, billing status |
Score bands: green 75–100, amber 50–74 (CSM outreach within a week), red under 50 (call within 2 business days). Weights are a starting point; tune them against churn after the first two quarters.
1.7 Announcements
- In-app banners and emails targeted by plan, cell, role (for example only payroll managers) or tenant.
- Types: scheduled maintenance (7 days ahead for planned downtime; 48 hours for degraded-mode maintenance), statutory updates, new features, incidents (linked to the status page).
- Every announcement has an expiry; banners for incidents are posted by the incident commander (backup and DR).
1.8 Platform access control
| Role | Can | Cannot |
|---|---|---|
platform_admin | Everything in the console; approve emergency access; publish statutory packs | Read tenant data without a support session |
support_engineer | View tenants and health; request support sessions | Change plans, flags (except documented kill switches during an incident), billing |
billing_admin | Plans, invoices, credits, dunning, subscription sync | Support sessions, flags, rollouts |
release_manager | Start, pause, resume and abort rollouts; maintenance windows; minimum mobile version | Plans, billing, support sessions |
Platform accounts are in Spyrl's own IdP with hardware-key or TOTP MFA, reviewed quarterly, and removed on the day a person leaves.
2. Tenant-side administration responsibilities
What the client is responsible for, explained during onboarding and in the tenant admin guide.
| Area | Responsibility | Typical role |
|---|---|---|
| Users and roles | Invite and deactivate users promptly (leavers on the last working day); assign roles with least privilege; quarterly access review (the app produces the review list) | hr_admin, org_owner |
| Policies | Keep attendance, leave and payroll policies current; use effective dates for changes; review the statutory pack change log | hr_admin, finance_admin |
| Payroll correctness | Review and approve each run; check variance reports; file statutory returns and pay challans on time | payroll_manager, finance_admin |
| Employee data accuracy | Master data, bank details, statutory IDs; approve employee change requests | hr_manager |
| Consent and notices | Run consent campaigns for face and location; respond to employee data requests within the deadline (the app tracks them) | hr_admin |
| Devices | Kiosk tablets and biometric devices: physical security, connectivity, time sync, enrolment | hr_manager, site admin |
| Integrations | Configure and monitor their connectors (SSO, accounting, webhooks, bank formats) | hr_admin, finance_admin |
| Support access | Approve or deny Spyrl support access requests; review the access log | org_owner |
| Exports and retention | Keep exported statutory records for the legally required period after offboarding | org_owner |
3. Operational RACI
R responsible, A accountable, C consulted, I informed.
| Activity | Eng on-call | Release manager | Platform admin | Support | Customer success | Security lead | Payroll SME | Tenant admin |
|---|---|---|---|---|---|---|---|---|
| Tenant provisioning (self-serve) | I | — | A | I | R (follow-up) | — | — | C |
| Assisted onboarding and data migration | — | — | I | C | A/R | — | C | R |
| Dedicated-cell provisioning | R | C | A | — | I | C | — | I |
| Weekly release rollout | C | A/R | I | I | I | — | C (payroll changes) | I |
| Hotfix during the payroll window | R | A | I | I | I | — | C | I |
| Statutory pack update | — | C | A | I | I | — | R | I (accept/inherit) |
| Incident response (SEV1/SEV2) | R | C | A (incident commander rota) | R (customer comms) | C | C | C | I |
| Break-glass support access | — | — | A (emergency approver) | R | I | C (monthly review) | — | A (consent) |
| Backup verification and DR drill | R | I | A | — | — | C | — | — |
| Tenant offboarding and deletion | R (deletion job) | — | A | C | R (export, comms) | C | — | R (export receipt) |
| Access reviews (platform roles) | — | — | R | — | — | A | — | — |
| Access reviews (tenant roles) | — | — | — | I | C | — | — | A/R |
| Data principal requests (DPDP) | — | — | C | R (routing) | I | C | — | A (fiduciary) |
| Vulnerability remediation | R | C | I | — | — | A | — | — |
| Plan and billing changes | — | — | C | I | C | — | — | — (Spyrl billing_admin is R/A) |