Overview
This guide covers permission configuration, role assignments, capacity management, waitlist behavior, and data administration for the Group Session Scheduling feature (PM-04).Permission Key Reference
Default Role Assignments
These assignments are seeded by the PM-04 database migration (pf_role_permissions):
Note: The org_admin role automatically receives all active permissions via the platform trigger. Custom roles can be configured in Settings > Permissions.
Managing PM-04 Permissions
- Navigate to Settings > Permissions (requires
org_adminrole). - Select the Practice Management module from the module list.
- Locate the Group Definitions, Group Schedule, and Group Enrollments permission groups.
- Assign or revoke permissions per role using the toggle interface.
- Changes take effect immediately for newly issued tokens; existing sessions refresh on next page load.
Capacity and Waitlist Configuration
Capacity Fields
Automatic Capacity Enforcement
When a patient is enrolled via the UI or API:- The system counts current enrollments with
status = 'enrolled'for that group. - If the count is below
max_capacity, the patient is enrolled withstatus = 'enrolled'. - If the count equals or exceeds
max_capacity, the patient is automatically placed on the waitlist withstatus = 'waitlisted'and assigned the nextwaitlist_position.
Waitlist Auto-Promotion
When an enrolled patient is disenrolled (status changed todisenrolled):
- The system queries the waitlist for that group, ordered by
waitlist_position ASC. - The patient with the lowest
waitlist_positionis automatically promoted tostatus = 'enrolled'. - Their
waitlist_positionis cleared (NULL). - A toast notification informs the user of the promotion.
Manual Override
Administrators can override capacity by directly editing themax_capacity field on the group definition. Reducing capacity below current enrollment does not automatically disenroll patients — the group will display as over-capacity until resolved manually.
Soft Delete and Data Retention
Group definitions and enrollments use soft deletion — thedeleted_at column is set to the current timestamp, and records are hidden from standard views.
Soft delete behavior:
- Records remain in the database for audit and recovery.
- Application queries filter
deleted_at IS NULL. - RLS policies enforce this at the database level.
- Schedule occurrences linked to deleted groups are not affected.
Database Tables
All tables have RLS enabled with
FORCE ROW LEVEL SECURITY. The pm_has_org_access SECURITY DEFINER helper function prevents RLS recursion by checking organization_id membership.
Key Columns
pm_group_definitions:organization_id— Tenant isolation (required)group_type— CHECK constraint:therapy,psychoeducation,skills_training,support,iop,php,otherfacilitator_id,co_facilitator_id— References to staff profilesmax_capacity,min_capacity— Enrollment limitsdeleted_at— Soft delete timestampcustom_fields— JSONB for org-specific extensions
group_definition_id— FK topm_group_definitionssession_date,start_time,end_time— Session timingstatus—scheduled,completed,cancelledcancellation_reason— Required when status iscancelled
group_definition_id— FK topm_group_definitionspatient_id— FK topm_patientsstatus—enrolled,waitlisted,disenrolledwaitlist_position— Integer position when waitlisteddeleted_at— Soft delete timestamp
Domain Events
These events are available for downstream consumers (e.g., CL-14 clinical documentation) via the Platform Integration Layer.
Related Resources
- User Guide
- PM-04 Specification
- Implementation Log
- Patient Registration Admin Guide (PM-01)
- Platform Permissions:
src/platform/permissions/constants.ts