Core Platform

Saved views are among SEAtS ONE's most powerful productivity features. Instead of rebuilding the same filter combination each time, save it once and return with a single click. Over time, a well-built view library becomes the backbone of your daily workflow.

• Open the filter panel on any list and combine conditions: programme, year, attendance %, engagement band, open case status, last contact date
• Filters stack with AND logic — all conditions must be true for a student to appear
• Click "Save view", name it descriptively (e.g. "Year 2 Business — Below 75%"), and it appears in your sidebar
• Shared views can be made available to colleagues with the same data access level
• Edit or rename views from the sidebar context menu without affecting shared copies

Every list view is fully configurable — choose which columns appear, their order, and whether any are pinned. Column configuration is saved per view per user, so changes you make don't affect what colleagues see.

• Click the column picker icon (top-right of any list) to open the selector panel
• Toggle columns on or off, then drag to reorder — changes apply and save immediately
• Module-specific columns (engagement score, compliance status) only appear if your institution has that module
• Pin any column to the left edge so it stays visible when scrolling wide datasets
• Use "Set as default" to make your layout the starting point for future visits; "Reset to system defaults" for a clean start

Bulk actions let you act on multiple students at once — send a group email, assign a cohort to a colleague, open cases in bulk. Every action is individually logged against each student's timeline automatically, so you get bulk efficiency without losing individual audit trail.

• Tick the header checkbox in any list to select all visible students (up to 500 per page)
• Use individual checkboxes to hand-pick a subset — combine with filters for targeted groups
• The bulk action bar slides in at the bottom of the screen once two or more students are selected
• Bulk emails support mail-merge fields (first name, programme, tutor name) and are sent from your institution's address
• All bulk operations appear in the audit log with your username, timestamp, and the full list of affected students

The timeline is the single source of truth for everything that has ever happened with or around a student — automated events, staff notes, case activity, attendance records, and communication logs. Learning to navigate it efficiently is a core skill for anyone in a support or advisory role.

• Use event type filter chips: Attendance, Alerts, Cases, Contacts, or System events
• Pin important entries (safeguarding notes, formal warnings) so they remain visible at the top
• Click any entry to see full detail, linked cases, attached files, and the creating user's name
• The date range picker jumps to a specific period — useful for preparing for a student review or committee
• All timeline content is included in Subject Access Request exports — write notes accordingly

Managing users in SEAtS ONE involves two distinct layers: system roles (what actions a user can take) and data access (which students they can see). Understanding this separation is essential before making any user management changes.

• Create accounts in Admin → Users → New User; assign the system role (Read-Only, Case Worker, Supervisor, Module Admin, System Administrator) at creation
• Bulk-import accounts via CSV in Admin → Users → Import — field definitions are in the template headers
• Deactivating a user blocks login immediately but retains all case notes, timeline entries, and audit history permanently
• Use Admin → Users → Last Active to identify dormant accounts — review at the start of each academic year
• Role changes take effect immediately and are logged in the audit trail

Data access permissions are separate from system roles and operate on a need-to-know principle. A personal tutor should see only their tutees; a head of department should see their department's students. Each access scope is configured independently — and testing effective permissions before a user goes live is a critical step that prevents data breaches.

• Department restrictions limit visibility to named departments — configured in Admin → Users → [User] → Data Access
• Personal tutor assignments are managed in bulk via CSV (Admin → Personal Tutors → Import) or one-by-one in student profiles
• Named cohort access grants visibility of a defined group — useful for cross-departmental welfare teams
• Use "View as user" in Admin to simulate the exact access of any account before it goes live
• Access changes take effect immediately with no restart required

Every action in SEAtS ONE is logged — the acting user, the affected record, the change, and a timestamp. The audit log is exportable as CSV and is appropriate for governance reviews, Data Protection impact assessments, and Subject Access Request responses.

• Access the audit log via Admin → System → Audit Log — filter by user, action type, date range, or student
• Large date ranges export in paginated 10,000-row CSV files
• The Data Access Report (Admin → System → Data Access Report) shows every profile view — required for SAR compliance
• Bulk operation logs include the full list of affected students within each entry
• Audit data is retained for a minimum of 7 years — confirm your institution's retention policy with your DPO

SEAtS ONE exposes a read-only reporting API for pulling data into Power BI, Tableau, or custom dashboards. The API returns paginated JSON and is documented fully in the SEAtS developer portal. Access is credential-scoped and rate-limited to protect system performance.

• Request API credentials from your project manager — read-only by default and cannot make any data changes
• Rate limit: 1,000 requests per hour per credential set
• Full documentation at developer.seatsone.ai
• A pre-built Power BI connector template (attendance, engagement, at-risk analysis) is available from your project manager on request
• Store API credentials in your institution's secrets manager — never in shared scripts or version control