Administration & Settings

The NDSS CRM Administration Panel is the centralised hub through which Super Administrators and Organisation Administrators configure every aspect of the platform. Accessible via the left-hand sidebar under Administration → Settings, the panel consolidates user management, role configuration, audit logging, system settings, data operations, integrations, email templates, and backup procedures into a single, well-organised interface.

Who Can Access the Admin Panel?

Access to the Administration Panel is governed by the platform's Role-Based Access Control (RBAC) system. The following roles have varying levels of administrative access:

Admin Panel Navigation Structure

When a user with administrative privileges navigates to the Admin Panel, they see a tabbed interface with the following sections:

• Users - Manage all user accounts across the platform
• Roles & Permissions - Configure roles, assign granular permissions
• Audit Log - Immutable record of every action taken in the system
• System Settings - Organisation profile, branding, timezone, locale
• Data Management - Import, export, bulk operations, data cleanup
• Integrations - Third-party services, webhooks, API keys
• Email Templates - Customise notification emails
• Backup & Recovery - Automated and manual backup procedures

Technical Implementation

The Admin Panel is built using the following technologies:

• Frontend: Next.js (App Router) with React Server Components and TypeScript for type safety. TailwindCSS handles all styling. Radix UI primitives provide accessible dialog, dropdown, and tab components.
• Backend API: Next.js API routes handle CRUD operations. Python microservices process bulk data operations and generate analytics reports. PHP endpoints support legacy data synchronisation and third-party integrations.
• Database: PostgreSQL via Supabase / Oracle with Row-Level Security (RLS) policies ensuring administrators only see data within their organisational scope.
• Real-time: Supabase / Oracle Realtime subscriptions push audit log entries to connected admin sessions in real time.

The User Management module provides comprehensive capabilities for creating, editing, deactivating, and monitoring all user accounts in the NDSS CRM platform. Every person who accesses the system - whether they are a Super Administrator, Organisation Administrator, Manager, Support Worker, Clinician, Finance Officer, or Client - has a user record managed through this interface.

17.2.1 Users List View

The default view displays all users in a paginated, searchable, and filterable table. Administrators can quickly locate any user by typing into the search bar (which filters by name, email, or NDIS number) or by selecting a role filter from the dropdown.

17.2.2 Add New User

Clicking the + Add New User button opens a modal dialog with a multi-step form. The form is implemented using React Hook Form with Zod schema validation to ensure data integrity before submission.

Step 1: Personal Information

Step 2: Role & Access

17.2.3 Edit User

Clicking Edit on any user row opens the same multi-step form pre-populated with the user's current data. All fields are editable except the email address (which serves as the unique identifier). To change an email address, the administrator must deactivate the existing account and create a new one.

Key edit actions available:

• Update Personal Information: Change name, phone, address, date of birth.
• Change Role: Promote or demote a user. Role changes take effect immediately and the user is notified via email.
• Reassign Organisation/Team: Move a user between organisations or teams. Historical records remain associated with the original organisation.
• Reset Password: Send a password reset link to the user's email. The administrator cannot set passwords directly for security reasons.
• Force Logout: Invalidate all active sessions for the user, requiring re-authentication on next access.

17.2.4 Deactivate / Activate User

Users are never permanently deleted from the NDSS CRM platform. Instead, they are deactivated, which:

• Prevents the user from logging in
• Removes the user from all active shift rosters (future shifts only; completed shifts are preserved)
• Hides the user from assignment dropdowns (client allocation, shift assignment, etc.)
• Retains all historical data (notes, incidents, completed shifts, audit entries) for compliance
• Sends an automated notification email to the user and their direct manager

Reactivation reverses all of the above. The user regains their previous role and access level. The administrator may optionally send a reactivation welcome email.

The Role Management section allows administrators to define custom roles, assign granular permissions, and establish a role hierarchy that controls data visibility and action authorisation throughout the platform. NDSS CRM ships with a set of pre-defined system roles, but organisations can create additional custom roles to match their operational structure.

17.3.1 Pre-defined System Roles

17.3.2 Permission Categories

Permissions in NDSS CRM are organised into categories corresponding to platform modules. Each permission follows the pattern module.action (e.g., clients.create, shifts.approve).

17.3.3 Creating a Custom Role

To create a custom role, navigate to Admin → Roles & Permissions → + New Role. The creation form requires:

1. Role Name: A unique, descriptive name (e.g., "Regional Coordinator", "SIL House Manager")
2. Description: Brief explanation of the role's purpose
3. Role Level: Numeric level (1–10) determining hierarchy position. Lower numbers have higher authority.
4. Base Role (optional): Clone permissions from an existing role as a starting point
5. Permissions: Toggle individual permissions on/off using a grouped checkbox interface

17.3.4 Role Hierarchy Rules

• A user can only manage (create, edit, deactivate) users with a role level lower than their own.
• A user can only assign roles with a level lower than or equal to their own role level.
• Data visibility cascades downward: a Manager can see all data created by Support Workers in their team.
• Role changes are logged in the audit trail with the old role, new role, and the administrator who made the change.

The Audit Log provides a comprehensive, immutable record of every action performed within the NDSS CRM platform. Every user interaction - from logging in, to editing a client record, to approving an invoice - is captured with full context including the user, timestamp, action type, affected resource, details of the change, and the IP address from which the action originated.

17.4.1 Audit Log Interface

The audit log is presented as a searchable, filterable, and exportable table. Administrators can narrow results using the following filters:

• Date Range: Select start and end dates (defaults to last 7 days)
• User: Filter by specific user or all users
• Action Type: LOGIN, LOGOUT, CREATE, READ, UPDATE, DELETE, APPROVE, REJECT, EXPORT, IMPORT
• Resource Type: User, Client, Staff, Shift, Invoice, Incident, Setting, Role, etc.
• Severity: INFO, WARNING, CRITICAL

17.4.2 Audit Log Data Schema

Each audit log entry is stored in the audit_logs PostgreSQL table with the following schema:

CREATE TABLE audit_logs (
  id            UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  timestamp     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  user_id       UUID REFERENCES users(id),
  user_email    VARCHAR(255),
  action        VARCHAR(50) NOT NULL,   -- LOGIN, CREATE, UPDATE, DELETE, etc.
  resource_type VARCHAR(100) NOT NULL,  -- Client, Staff, Shift, Invoice, etc.
  resource_id   UUID,
  details       JSONB,                  -- Structured change data
  ip_address    INET,
  user_agent    TEXT,
  severity      VARCHAR(20) DEFAULT 'INFO',
  org_id        UUID REFERENCES organisations(id),
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Index for fast filtering
CREATE INDEX idx_audit_logs_timestamp ON audit_logs(timestamp DESC);
CREATE INDEX idx_audit_logs_user_id ON audit_logs(user_id);
CREATE INDEX idx_audit_logs_action ON audit_logs(action);
CREATE INDEX idx_audit_logs_resource ON audit_logs(resource_type, resource_id);

17.4.3 Audit Log Retention

Audit logs are retained for a minimum of 7 years in compliance with NDIS Quality and Safeguards Commission requirements and the Australian Privacy Act 1988. Logs older than 7 years are archived to cold storage (compressed and encrypted) rather than deleted. The retention policy is configurable per organisation in System Settings.

The System Settings section allows administrators to configure organisation-wide preferences that affect the behaviour, appearance, and defaults across the entire NDSS CRM platform.

17.5.1 Organisation Profile

17.5.2 Branding Settings

17.5.3 Notification Preferences

Administrators can configure which events trigger notifications and through which channels:

17.5.4 Timezone & Locale Settings

The Data Management module provides tools for importing, exporting, and maintaining data within the NDSS CRM platform. These operations are essential during initial setup (migrating from legacy systems), ongoing operations (bulk updates), and regulatory compliance (data exports for audits).

17.6.1 Data Import

NDSS CRM supports importing data from CSV, XLSX, and JSON files. The import wizard guides administrators through the following steps:

1. Select Data Type: Choose what type of data to import (Clients, Staff, Shifts, Invoices, etc.)
2. Upload File: Drag and drop or browse for the source file
3. Map Columns: Map source file columns to NDSS CRM database fields
4. Validate Data: The system runs Zod schema validation and reports errors
5. Review & Confirm: Preview the data to be imported with error highlighting
6. Execute Import: Process the import with progress tracking

17.6.2 Data Export

Data can be exported from any module in CSV, XLSX, JSON, or PDF format. Export operations respect role-based access control - a user can only export data they have permission to view.

• Quick Export: Export the current filtered view from any list page
• Full Export: Export all records of a specific type (admin only)
• Scheduled Export: Configure automated exports to run daily, weekly, or monthly
• Compliance Export: Generate NDIS-formatted data extracts for regulatory submissions

17.6.3 Bulk Operations

Bulk operations allow administrators to perform actions on multiple records simultaneously:

• Bulk Status Change: Activate or deactivate multiple users at once
• Bulk Role Assignment: Change the role of multiple users in one operation
• Bulk Shift Creation: Create recurring shifts for multiple staff members
• Bulk Invoice Generation: Generate invoices for all completed shifts in a date range
• Bulk Client Allocation: Assign multiple clients to a staff member or team

17.6.4 Data Cleanup

The data cleanup utility helps maintain data quality by identifying and resolving:

• Duplicate Records: Scans for potential duplicates based on name, email, NDIS number, or phone number. Presents matches for manual review and merge.
• Orphaned Records: Identifies records without required parent associations (e.g., shifts without a client, notes without an author).
• Stale Data: Flags records that have not been updated beyond a configurable threshold (e.g., client plans older than 12 months).
• Incomplete Records: Lists records missing required fields for compliance (e.g., clients without NDIS numbers, staff without qualification expiry dates).

NDSS CRM supports integration with a range of third-party services to extend platform functionality. The Integration Settings panel provides a centralised interface for managing all external connections, API keys, and webhook configurations.

17.7.1 Third-Party Integrations

17.7.2 Webhook Configuration

Webhooks allow external systems to receive real-time notifications when events occur in NDSS CRM. Administrators can configure multiple webhook endpoints, each subscribed to specific event types.

17.7.3 API Key Management

API keys allow external systems to authenticate with the NDSS CRM API. Each key is scoped to specific permissions and can be revoked at any time.

• Generate New Key: Creates a new API key with a specified name, expiry date, and permission scope
• View Keys: Lists all active API keys with creation date, last used date, and scope
• Revoke Key: Immediately invalidates an API key. All requests using the revoked key will return 401 Unauthorized.
• Rotate Key: Generates a new key and provides a 24-hour grace period during which both old and new keys are valid

NDSS CRM sends automated email notifications for various platform events. The Email Templates module allows administrators to customise the content, layout, and branding of these notifications. All templates use a variable substitution system, enabling dynamic content insertion.

17.8.1 Available Templates

17.8.2 Template Variables

Template variables are enclosed in double curly braces {{variable_name}} and are automatically replaced with actual values when the email is sent:

17.8.3 Template Editor

Each template can be edited using a rich-text editor that supports:

• Bold, italic, underline text formatting
• Heading levels (H1–H4)
• Bulleted and numbered lists
• Links and buttons
• Variable insertion via autocomplete dropdown
• Preview mode with sample data
• HTML source editing for advanced customisation
• Test send to a specified email address

Data protection is a critical responsibility for NDIS service providers. NDSS CRM implements a comprehensive backup and recovery strategy that ensures business continuity and data integrity in the event of hardware failure, data corruption, accidental deletion, or security incidents.

17.9.1 Automated Backups

17.9.2 Manual Backup

Administrators can trigger a manual backup at any time from the Backup & Recovery panel. Manual backups are recommended before:

• Major data imports or migrations
• System upgrades or configuration changes
• Bulk data operations (mass updates, deletions)
• Integration configuration changes

Manual backups are processed by a Python service that coordinates the database dump, file storage snapshot, and configuration export. The process takes approximately 5–15 minutes depending on database size and completes asynchronously with email notification.

17.9.3 Restore Procedures

Data restoration is a privileged operation available only to Super Administrators. The restore process follows these steps:

1. Select Backup: Choose from a list of available backups (date, type, size)
2. Select Scope: Full restore, specific tables, or point-in-time recovery
3. Pre-restore Backup: System automatically creates a backup of the current state
4. Confirmation: Multi-factor authentication required for restore operations
5. Execute Restore: System enters maintenance mode during restore
6. Verification: Automated integrity checks post-restore
7. Notification: All administrators are notified of the restore operation

17.9.4 Recovery Time & Point Objectives