Identity, Purposes, Roles & Providers
Manage registration identity, purpose-role dependencies, provider classification, routing, access and acceptance references.
Purpose
Use the existing Purpose collection. Preserve public/internal and active flags used by registration.
Purpose Name | Purpose Description | Actions |
|---|
Cluster
Use the existing Cluster collection and connect each cluster to the applicable Purpose records.
Name of Cluster | Actions |
|---|
Role
Preserve the existing Role collection. Provider roles are filtered Role records, not a duplicate collection.
Description | Role Name | Actions |
|---|
Role Specialisation
Preserve the existing Role Specialisation collection and its parent Role relationship.
Name | Description | Actions |
|---|
Business Cluster Categories
Classify business-provider activity beneath the appropriate platform cluster where this collection already exists.
Name of Category | description | Actions |
|---|
Provider Types
Use for provider registration and classification without duplicating Role.
Name | Description | Actions |
|---|
Business Types
Describe the legal or operating form of a provider organisation.
Name | Description | Actions |
|---|
Service Coverage Types
Describe local, district, provincial, national, cross-border or other supported service coverage.
| Coverage type | Description | Status | Actions |
|---|---|---|---|
| ExampleProvincial | Selected province coverage | Demo only |
Credential Types
Classify credentials that may be requested; actual evidence belongs in protected verification records.
| Credential type | Applies to | Status | Actions |
|---|---|---|---|
| ExampleProfessional certificate | Relevant professional provider | Demo only |
Licence Types
Classify licences used by provider verification; actual licences and expiry dates remain operational records.
| Licence type | Applies to | Status | Actions |
|---|---|---|---|
| ExampleOperating licence | Regulated provider activity | Demo only |
Account Types
Differentiate individual, organisation and authorised internal account structures.
| Account type | Description | Status | Actions |
|---|---|---|---|
| ExampleIndividual | Account owned by one person | Demo only |
Account Statuses
Control the account lifecycle separately from profile, registration, verification and subscription status.
Display Name UI Label | Description | Actions |
|---|
Profile Statuses
Track profile readiness or publication separately from account access.
| Status | Description | Status | Actions |
|---|---|---|---|
| ExampleComplete | Required profile information supplied | Demo only |
Registration Statuses
Describe incomplete, in-progress and completed registration states without replacing step tracking.
Description | Name | Actions |
|---|
Registration Stages
Represent the current seven live registration pages and preserve stable sequence values.
| Stage name | Sequence | Status | Actions |
|---|---|---|---|
| ExamplePurpose and role selection | 3 | Demo only |
User Purpose Types
Use only if this collection classifies Purpose records. Do not duplicate the selectable values in Purpose.
| Purpose type | Description | Status | Actions |
|---|---|---|---|
| ExamplePublic purpose | Selectable during registration | Demo only |
Dashboard Route Keys
Keep route keys unique and stable; validate every destination before activation.
| Route key | Destination | Status | Actions |
|---|---|---|---|
| ExampleFAMILY_ORGANIZER | /family-dashboard | Demo only |
Invitation Access Levels
Reference vocabulary only. Actual access must be enforced through DrapCode permissions.
Name | Description | Actions |
|---|
Permission Groups
Group permissions for administration; changes require least-privilege review.
| Group name | Scope | Status | Actions |
|---|---|---|---|
| ExampleProvider management | Provider administration permissions | Demo only |
Registration Sources
Record direct registration, staff assistance, invitation, referral, campaign and other known sources.
Name | Description | Actions |
|---|
Authentication Providers
Record email/password and supported external identity providers. Disabled providers may remain inactive until implemented.
Name | Description | Actions |
|---|
Acceptance Types
Classify the legal or consent item accepted without storing acceptance evidence here.
Name | Actions |
|---|
Acceptance Sources
Record where acceptance occurred, such as registration step, checkout, policy update or account settings.
Name | Actions |
|---|
DrapCode connection notes
- Create or duplicate this page at the route above and restrict write access to authorised identity and platform administrators.
- Bind each accordion table and Add/Edit action to the existing collection represented by its heading. Keep current technical names until dependencies are checked.
- Configure and test Purpose → Cluster → Role → Role Specialisation in that exact order. Do not replace Role with a separate Provider Roles collection.
- Keep User, Permission, Role and User Login Activity as distinct existing collections. These reference tables must not replace user accounts, permission assignments or login records.
- Keep provider businesses, credentials, licences and verification evidence in their operational collections. These tables only supply controlled values.
- Registration Source, Authentication Provider, Acceptance Type and Acceptance Source provide evidence context. Actual values must be written automatically to User, registration tracking, acceptance records and Audit Logs at the relevant event.
- Changes to role, access, permission, route or acceptance configuration must create Audit Logs and notify the appropriate administrator.
- After changes, test all seven registration pages, the routing checkpoint, dashboard redirects, provider registration, permissions, non-admin direct URL access and acceptance recording.