RosterBeamScope of this page. This information describes current implementation practices reviewed on 3 August 2026. It does not certify compliance, define a service level, or replace an executed agreement and Statement of Work.
School-specific architecture and access
- Each school deployment has its own hostname, application credentials, database and document storage. RosterBeam does not place school rosters in a shared database distinguished only by tenant identifiers.
- School applications are reached over HTTPS. The application validates the load-balancer-signed identity and expected Auth0 organization before applying Viewer, Planner or Admin permissions on the server.
- Production onboarding requires multi-factor authentication to be configured and verified in the school’s identity provider. This is an identity-provider configuration, not an application setting.
Information protection
- The school database runs in private isolated network subnets. Uploaded documents use non-public object storage with encryption at rest, SSL-only access and object versioning.
- Application and management credentials are supplied through AWS Secrets Manager rather than plain task-definition environment values.
- The public RosterBeam website is separate from authenticated school applications and has no analytics, advertising trackers, account registration or contact-form database.
Software delivery and integrity
- Application changes pass automated tests, Python compilation and a container build before deployment. Locked dependency files make application and browser-extension builds reproducible.
- Production container images are scanned when pushed to the private image repository. Engage Bridge packages carry recorded checksums and are available only through short-lived authenticated downloads.
- RosterBeam is delivered as a centrally managed SaaS application, so application updates do not require school users to install them. Service deployments use health checks and automatic rollback when a new deployment cannot stabilize.
Continuity and recovery controls
The production database is deletion-protected and configured for 14 days of automated backups. Uploaded documents are versioned, infrastructure is defined in source, and key storage resources are configured to be retained. Application health checks allow failed tasks to be replaced, while deployment rollback protects the last stable task definition. These controls support recovery but do not state a recovery-time or recovery-point objective and do not replace an agreed disaster-recovery plan and test schedule.
Review and approval controls
Scheduling inputs, exceptions, warnings and generated revisions remain visible to authorised school staff. Proposed exceptions must be accepted or rejected before solving, validation errors prevent approval, and the latest roster revision must be approved before an Excel export becomes available. Administrative deletion and reset controls are restricted to the Admin role.
Contract boundary
Specifications, licence rights, service levels, service reporting, service credits, maintenance notices, support response, incident reporting, migration, disaster recovery and disengagement arrangements must be defined in the executed agreement and Statement of Work where applicable. Nothing on this page creates those terms.
Requesting supporting evidence
Security, privacy and procurement questions can be sent to support@rosterbeam.com. Please do not include student or staff information in an initial request.