Skip to content

RTOpacks Org Model

Status: Live (ROLES-01a/b — e773ed49 / 6160603c)
Last updated: 2026-04-07

Overview

RTOpacks serves Registered Training Organisations (RTOs) as L4 client organisations. Each org has members who access the platform at different levels. This document describes the org structure, membership model, and the decisions made in designing it.

Membership Types

Every person on the platform belongs to an org and has a membership type. There are three types:

Type Surface access Consumes seat
admin_member Admin + Workspace Yes
admin_only Admin only No
member Workspace only Yes

admin_member — The org principal. Full access to both the L4 admin surface and their own L4A workspace. Typically the RTO owner or manager. An org can have multiple admin_members — all count against the seat limit.

admin_only — Administrative staff who manage the account but don't need the training content workspace. Office managers, bookkeepers, practice managers. Does not consume a seat. Soft cap of 10 per org — beyond that, system notifies admin@rtopacks.com.au for review but does not hard block.

member — Trainers, assessors, staff who use the workspace. No access to the admin surface. Consumes a seat.

Seat Accounting

Each org has a seat_limit (default: 4) and an admin_only_limit (default: 10).

  • admin_member + member count against seat_limit
  • admin_only counts against admin_only_limit
  • Seat limit reached → soft block with message: "Upgrade your plan or deactivate an existing member"
  • Admin-only limit reached → allow, notify admin@rtopacks.com.au

Billing integration (Stripe) is a future brief (BILLING-01). Schema is billing-aware from day one — billing_tier and billing_status on both orgs and org_memberships.

Primary Admin

Every org has exactly one is_primary_admin. This is the first admin_member provisioned when the org is created. Rules:

  • Cannot be deactivated without first reassigning primary admin to another admin_member
  • Enforced at the API layer on DELETE /org/:id/members/:mid
  • L3 can reassign if needed from the RTOpacks admin panel

Surfaces

Two surfaces, one login. Same session, different surface — same pattern as Google Workspace.

Workspace (my.rtopacks.com.au) — The working environment. Training content, qual/unit lookup, KN, tools. All membership types with workspace access land here by default.

Admin (my.rtopacks.com.au/admin) — Org management. Team, billing, settings, activity. admin_member and admin_only only. Auth gate enforced at middleware — any other membership type redirects to /.

AccountMenu in workspace chrome has an Admin link for quick switching.

L4 Admin Surface — Navigation

/admin                    → Dashboard (seat usage, onboarding checklist)
/admin/onboarding         → First login onboarding flow (5 steps)
/admin/settings/org       → Org details — name, logo, address, contact
/admin/settings/scope     → Scope of registration management
/admin/team               → Team management (GSuite-style)
/admin/sessions           → Team session data (SESSION-01 L4 view)
/admin/billing            → Billing placeholder (BILLING-01)
/admin/activity           → Org audit log

Team Management

GSuite-style member list. Columns: name, email, type, status, last login, seat.

Seat counter displayed at top of team view: X of Y seats used · Z admin-only accounts

Member drawer — 4 tabs

Details — Name, email, position, phone, membership type, site assignment (future)

Security — Passkey status, active sessions, last login, last IP, device hint, force re-auth

Groups — Site/campus memberships. Empty state placeholder until sites feature ships.

Investigate — Per-member activity log. Last 20 events filtered by user_id. Login events, page views, qual lookups, session events. "View all" links to full activity log filtered to this member.

Invite flow

  1. Enter email, select membership type, optional display name
  2. Seat check performed before send
  3. Magic link sent via Resend (same pattern as platform auth)
  4. Member clicks link → onboarding flow for their membership type

Onboarding

L4 admin first login

Five-step flow at /admin/onboarding:

  1. Welcome — video (config: ONBOARDING_VIDEO_URL, placeholder until video produced)
  2. Confirm org details — pre-populated from TGA/ASQA: name, ABN, RTO code, address
  3. Confirm scope — qualifications pre-populated from org_scope table (seeded from TGA at org provision). Confirm, delete, or add manually.
  4. Your profile — personal details (name, position, phone) separate from org
  5. Done — onboarding_complete flag set, land in /admin dashboard

Onboarding checklist widget persists on dashboard until all steps confirmed.

L4A member first login

  • Welcome video (config: MEMBER_ONBOARDING_VIDEO_URL — separate from org admin video)
  • Name, position, contact details
  • Land in workspace dashboard

L3 Provisioning

L3 (RTOpacks operator) provisions new orgs from the admin panel at /orgs.

Provision flow: 1. Enter org name, RTO code, admin email 2. System seeds org details from TGA/ASQA data automatically 3. Creates first membership: admin_member, is_primary_admin: true 4. Sends welcome magic link to org admin email 5. Org appears in org list with status: pending (until admin completes onboarding)

Schema

orgs

Core org record. Includes seat limits, billing status, onboarding flag.

org_memberships

One row per person per org. Key fields: - membership_type — admin_only | admin_member | member - is_primary_admin — boolean, one per org - site_id — nullable, future use (multi-site/campus assignment) - role — nullable, future use (granular L4A permissions) - billing_tier — included | paid - billing_status — active | pending | cancelled

org_scope

One row per qualification on the org's scope of registration. Pre-populated from TGA at provision. confirmed flag tracks whether the org admin has reviewed each entry.

Future Hooks

site_id — Multi-site RTO support. A large RTO with campuses in Brisbane, Sydney, Melbourne can assign members to sites. Each site can have a manager with site-scoped visibility. When ready: add org_sites table, wire site_id on memberships. No logic yet.

role — Granular L4A permissions. An org admin can assign roles to members that control what they can see and do in the workspace. First clients will define what roles mean in practice. No logic yet.

BILLING-01 — Stripe integration. billing_tier and billing_status on both orgs and memberships are ready. Seat overage detection is ready. Just needs the payment layer wired.

SESSION-01 L4 team view — Team sessions in /admin/sessions. Deferred from SESSION-01 because it requires org membership data to scope queries. Now that ROLES-01 is live, this can be wired. Brief: SESSION-01c or included in next admin brief.

Decisions Made

Why admin-only accounts don't consume seats — An RTO shouldn't pay for seats for office staff who don't use the training content. Separating the billing from the admin access is a genuine commercial differentiator.

Why soft cap at 10 admin-only — Unlimited with no visibility is operationally risky. 10 covers every real use case. Beyond that, we want to understand why — it's a signal, not a restriction.

Why my.rtopacks.com.au/admin not admin.rtopacks.com.au — The RTOpacks admin panel at admin.rtopacks.com.au is L3 operator level (Tim). L4 org admin lives at /admin within the workspace domain. Keeps the surfaces distinct, avoids domain confusion.

Why GSuite mental model — RTO staff know GSuite. Users list, member drawer with tabs, invite flow, seat counter — all familiar patterns. Reduces training friction for the first clients.

Why pre-populate from TGA/ASQA — RTOpacks already has this data. Handing a new org admin a pre-configured environment is the first wow moment. They see their quals, their address, their RTO code — already there. Confirm and go.