Overview
Before you create your first Competency, it's worth deciding how the whole set should be structured. A good competency framework maps cleanly to the real qualifications your operation tracks, scales as you add rides and staff, and makes the gating on Schedules and RideOps easy to reason about. This article covers the design principles; for the mechanics, see Utilizing Competencies and How to create a Certification Process.
Why this matters: Competencies are referenced everywhere — Schedules, RideOps positions, prerequisites, reports. Restructuring them after they're in use means touching all of those places. A little design up front saves a painful migration later.
Core principles
Principle | What it means |
One Competency per real qualification | Create a Competency for each distinct thing a person can be qualified to do — not per ride, per person, or per shift. Coaster Operator is a qualification; Zone A Monday Crew is not. |
Reuse across gates | The same Competency can gate a Schedule and a RideOps position. One Loader Competency can gate both the pre-opening inspection and the Loader position. One award, many gates. |
Right level of granularity | Too broad and you can't tell who's qualified for what; too granular and you drown in near-identical Competencies. Match the grain at which your real training and sign-offs happen. |
Tiers via prerequisites | Use a Process's Required Competencies (prerequisites) to build progression — a User must hold the lower tier before they can start the next. |
Choosing the right granularity
The most common design question is how finely to split Competencies. A useful test: create a separate Competency wherever a separate sign-off happens.
If every coaster requires the same operator training, one Coaster Operator Competency is enough — don't make one per coaster.
If a specific ride has unique, certifiable controls, that genuinely distinct sign-off justifies its own Competency.
If two "different" Competencies would always be awarded together by the same training, they should probably be one.
Best practice: Start broader than you think you need. It's easy to split a Competency later by introducing a more specific one; it's painful to merge a sprawl of over-granular Competencies that are already wired into Schedules and RideOps.
Building tiers with prerequisites
When a role has progression — trainee, operator, lead — model it as separate Competencies linked by prerequisites on each Certification Process:
The Operator Process lists Trainee as a Required Competency, so only Users who already hold Trainee can start it.
The Lead Process lists Operator as a prerequisite, and so on up the chain.
Note: A Process's Required Competencies are prerequisites to start — distinct from a Schedule's Required Competencies, which gate who can do the work. Same field name, different layer. See How to create a Certification Process.
Naming and expiration
Name for the qualification, with a tier marker where relevant — Coaster Operator – Tier 2 reads clearly to operations, training, and frontline staff alike. Avoid abbreviations only insiders understand.
Version when requirements change — if a training program materially changes, a new versioned Competency stops old Certifications from silently carrying forward as if they met the new bar.
Prefer relative expiration for recurring training — expiration measured from each User's completion date builds renewal cadence into the Competency itself, rather than a shared calendar deadline that won't fit everyone.
Example: a three-tier ride operator path
Scenario
A park wants a clear progression for ride staff: Trainee → Operator → Lead Operator, with each tier unlocking more responsibility.
Setup
Three Competencies: Ride Trainee, Ride Operator, Lead Operator.
Three Certification Processes, each awarding its Competency, with prerequisites chained: Operator requires Trainee; Lead Operator requires Operator.
RideOps Operator positions require Ride Operator; the shift-lead position requires Lead Operator.
Each Competency expires 1 year after completion (relative expiration).
Result
A new hire can only start the Operator Process once they hold Trainee, and Lead once they hold Operator — the progression enforces itself. RideOps automatically offers each person only the positions their current tier qualifies them for, and renewals come due on each individual's anniversary rather than all at once.
Anti-patterns to avoid
Watch out for these, which make a framework hard to maintain:
One Competency per ride when the training is identical across rides — you get dozens of duplicates that all mean "can operate a coaster".
Competencies named after people or shifts — these aren't qualifications and won't reuse across gates.
Fixed-date expiration for rolling training — forces an artificial all-staff deadline instead of per-User renewal cadence.
Skipping prerequisites on a tiered path — without them, anyone can jump straight to the top-tier Process.
Frequently asked questions
Q: Should I make one Competency per ride?
A: Only if each ride truly has a distinct, separately certified sign-off. If the operator training is the same across rides, use one Competency and require it on each ride's RideOps positions.
Q: How do I model a progression like trainee → operator → lead?
A: Separate Competencies, chained with prerequisites on each Certification Process so each tier requires the one below it.
Q: We're changing our training program. New Competency or reuse the old one?
A: If the bar has materially changed, create a new versioned Competency so existing holders don't carry forward as meeting the new standard automatically.
Q: How many Competencies is too many?
A: There's no hard limit, but if you can't explain what distinguishes two Competencies, they should probably be one. Aim for the set that maps to your real sign-offs.