AdminDefinitions, paths & steps

The definition is the structural template behind a cycle. It holds the paths a user can take and the steps they'll complete.

Open the definition

Click Manage Definition on any cycle row. The definition editor opens as a full-screen modal.

Definition → Tree view. Paths sit in the centre column; steps fan out to the right. Click any card to edit it.

Two views toggle in the toolbar:

• Tree — a visual layout of paths and their steps. Best for understanding flow and adding/reordering items.
• Tables — flat tables of all paths and all steps. Best for bulk edits and seeing details like Required, Prerequisites, and assigned Roles.

Tables view: see everything at a glance

Switch to Tables when you need to scan many paths or steps at once.

Definition → Tables view. The Paths table shows which path is default; the Steps table shows every step with its membership and gating flags.

• Paths table columns: Name, Default (one path is marked with a star), Steps, Enrollments.
• Steps table columns: Title, Paths (a step can live on more than one path), Content count, Required, Prerequisites, Roles.

Configure a path

Click Edit on a path to open the path editor — two tabs: Path and Path Conditions.

Path tab. Name, description, and a default flag — users are assigned to the default path when they enrol unless conditions override that.

Path Conditions tab. Hide a path from users whose enrollment context doesn't match — useful when different roles or cohorts should see different tracks.

Path Conditions let you control path visibility based on enrollment context — values populated by form submissions earlier in the program. For example: only show an advanced path to users whose form submission set their experience level to Senior.

Configure a step

Click Edit on a step. The editor has five tabs covering everything from content to sign-off.

Step tab — basics & content

Step tab. Title and description, plus the content this step delivers and a Required toggle for completion gating.

• Step Title and Step Description — what users see on the step strip.
• Content — pick the content item this step delivers (Static Content, Video, Quiz, Activities, Learning Portfolio, etc.). A step can carry multiple content rows.
• Required — when on, the step must be completed for the program to count as complete.

Access tab — who sees it and when

Access tab. Limit a step to specific roles, allow read-only viewing for others, and require completion of earlier steps.

• Role Access — restrict the step to certain roles (Member, Reviewer, etc.). Drag to set the order if ordering is enforced.
• Allow read-only view for non-assigned roles — others can see the step but can't act on it.
• Prerequisites — other steps that must be completed first.

Mentorship tab — require review

Mentorship tab. When enabled, every content item in this step must be approved by a mentor before completion.

Step Conditions tab — automatic status

Step Conditions tab. Auto-set a step's status (e.g. Exempt) when enrollment context values match.

Useful for skipping steps that don't apply — e.g. mark the New Hire Orientation step as Exempt for anyone whose context says they've been with the org > 1 year.

Sign-off Chain tab — multi-stage approval

Sign-off Chain tab. Define an ordered list of roles that must each sign off after the user finishes the step.

The chain runs top-to-bottom: the first role signs off, then the second, and so on. Leave it empty to skip sign-off entirely.

Share definitions across cycles

When you create next year's cycle, point it at the same definition. Changes you make to that definition apply to both cycles. Want to evolve the structure without touching the live cohort? Duplicate the definition first, then attach the copy to the new cycle.