The program journey (items)

What the journey is

Every program is built from an ordered list of items. Each item represents one thing a participant will encounter or do — a set of coaching sessions, a goal-setting step, a 360-feedback round, a training module, and so on. Together, in order, these items form the journey: the path a participant walks through the program from start to finish.

An administrator assembles the journey on the program’s Items page in the admin console. From there you can:

Add an item — pick a type from the “Add Items” menu and add it to the program.
Reorder items — drag items up or down to change the sequence participants see.
Enable or disable an item — turn a step on or off without removing it.
Remove an item — take it out of the program entirely.
Open an item to configure it — every item has its own settings screen for the details specific to that step (who’s involved, timing, forms used, and so on).

Adding an item validates its configuration before saving — for example, an item that points at a form checks that the form actually exists, and an item that points at an exercise package also checks that the package is visible to the program, so a journey can’t silently reference missing or inaccessible content.

Items that depend on each other

Some items can’t be disabled while another enabled item relies on them. The platform enforces these dependencies and explains the conflict instead of leaving the journey in a broken state:

Matching can’t be turned off while Sessions or a Handshake (which need a match) are still enabled.
Competencies can’t be turned off while Development goals (which can link goals to competencies) is still enabled.
Sessions can’t be turned off while Session evaluation or the SR report (which summarize session activity) are still enabled.

One of each — with exceptions

Most item types can only be added to a program once: they are a single step in the journey, and trying to add a second one is rejected. Content-style items are the exception and can appear multiple times — a program can have more than one package, assessment, survey, resource, or standalone form, and it can also have more than one handshake (for example a goal-setting handshake and a separate coach/mentor agreement in the same journey).

Programs vs. cohorts

The journey belongs to the program, not to an individual cohort. All cohorts running under the same program share the same list of items, in the same order, with the same configuration. There is no separate per-cohort item list — a cohort simply inherits whatever journey its program defines.

Items drive the journey timeline

The journey isn’t just an admin-side list — it generates the timeline participants see. Every enabled item produces one or more journey milestones appropriate to its type: a package gets a start and an end, a form or survey gets a send date and a deadline, an assessment or training module gets a start and a deadline, and so on. A “Program Start” milestone always exists.

The timeline stays in sync automatically: adding, enabling, disabling, or removing an item regenerates the program’s milestones, so a disabled step disappears from the participant journey without manual cleanup. On the participant side, the home screen’s next-step guidance uses these milestones to point each person at the right place — their sessions, their goals, a pending form, their handshake, or their 360 round.

One editor per item

Every item type has a single editor screen reached by opening it from the Items page. The editor presents that item’s options in clearly labelled sections with plain-language settings. Where an item wraps content that has its own dedicated authoring area, the item editor links out to it rather than duplicating it — form questions are built in the program’s Forms hub, exercise packages in the package library, and so on — so each thing is edited in exactly one place.

Two items take this to its logical end and are read-only summaries:

Sessions — the actual session settings (timing, meeting platforms, invitations, and so on) are edited on the program’s dedicated Sessions configuration tab. The Sessions item shows a summary of what’s configured, with a link to the real editor, so the two screens can never show conflicting settings.
Matching — matching is likewise configured in one place, the program’s Matching editor. The Matching item shows the current configuration (matching type, capacity per support giver, response window) and links across to it.

Item-level competency choices

Three items work with competency sets: Competencies (self-assessment), Development goals, and 360 feedback. By default each of them inherits the program’s competency configuration, but each item can also carry its own competency-set choice that overrides the program default for that item only. The item’s editor shows which is in effect — “using the program default” or “this item has its own copy” — and lets you switch between them at any time.

The override cascades into the participant experience for that item: for example, a Development goals item with its own set changes which competencies participants can link their goals to, without affecting the self-assessment or the 360 round.

One deliberate exception: cloning a program copies the program-level competency configuration, but not per-item overrides. Items in the cloned program start out inheriting the cloned program’s defaults, and you re-apply any item-level choices where you still want them.

Item type reference

Core participation

Sessions — the coaching or mentoring sessions themselves. Configured on the program’s Sessions tab (the item is a read-only summary, as above). Depends on matching being enabled.

Development goals — where participants set and track the goals they’re working toward. Key settings: how many goals participants set (minimum and maximum), whether each goal must have concrete actions and how many, and a cap on active goals. Goals can be linked to the program’s competencies (or to this item’s own competency set, if overridden). Goal-setting can also happen inside an exercise: exercise steps that collect a list of goals write those entries into the participant’s development goals when the step is submitted, so goals captured during an exercise and goals on the Goals page stay one list.

Handshake — a shared agreement step between two or more participants, such as a participant and their coach or mentor confirming shared goals, or formally agreeing to work together. A handshake item configures:

What kind of agreement it is — a development-goal handshake (the participant shares selected goals for approval) or a coach/mentor agreement (the agreement content comes from a form).
Who takes part — the participant roles involved and who has approval authority.
What starts it — for example once goals are set, once matching completes, when someone joins a cohort, at program start, or manually.
How approval works — everyone must approve, anyone can approve, or a higher authority signs off; optionally require a comment when rejecting, and allow revision cycles with a cap.
Timing — how many days after the trigger the handshake is due; for development-goal handshakes, when the participant must share their goals by (and how many goals they must select, from one to ten). Participants are reminded as the share deadline approaches.
Discussion checklist — optional prompts the participants work through during approval.

Because a program can contain more than one handshake, you might see a development-goal handshake and a coach/mentor agreement listed as separate steps in the same journey.

Matching — how support receivers and support givers (mentees and mentors/coaches) get matched. Configured in the program’s Matching editor (the item is a read-only summary, as above): matching type (self-service, admin-assigned, hybrid, or automatic), how many matches a support giver can hold, and how long a support giver has to respond.

Assessment & feedback

Competencies — the competency self-assessment step. Key settings: the rating scale, the assessment mode, and whether to run a baseline assessment at the start and a final assessment at the end. Uses the program’s self-assessment competency set unless the item carries its own.

360 feedback — the 360-degree feedback round: collecting and viewing peer/manager/self feedback about a participant. Key settings: which role receives the round, minimum and maximum number of responders, anonymity, whether a self-assessment is included, and how long the collection window stays open. Adding a 360 item creates a working default configuration automatically, which you then tailor.

Session evaluation — a short evaluation completed after a session. Key settings: which question blocks are on (overall rating of the support giver, a recommendation score, and free-text questions about gains, actions, and the next session’s topic), or alternatively using forms built in the Forms hub for the questions — one form the participant fills about the session, and an optional separate one that goes to program administrators. Visibility is explicit: you control whether the support giver sees the participant’s session feedback and whether admins see the evaluation, and you can additionally have support givers evaluate sessions from their side.

Assessment — a formal, scored evaluation such as a pre/post-program test. Key settings: when it runs (pre-program, mid-program, post-program, or a custom point), which role takes it, the passing score, an optional time limit, and whether retakes are allowed. Appears on the journey timeline with a start and a deadline.

Assessment report (PDF) — a catalog of externally produced assessment report PDFs. Admins define report types (each with a code and visibility rules), upload a PDF per participant, and can reference the reports from exercise content via their codes — useful when an external provider’s assessment results need to live inside the journey.

Forms & surveys

Form — a single, standalone form with its own place in the journey. The form itself is built and linked from the program’s Forms hub; the item configures which role fills it, what triggers it, whether it’s required, and the name it shows under on the timeline. A program can have several of these. A standalone form is an in-program step for people already in the program — a form that gates entry into the program belongs on the request/intake side instead.

Survey — a feedback-collection instrument such as a satisfaction survey, typically anonymous and reported in aggregate. The questions come from a form built in the Forms hub; the survey item configures who receives it, when it goes out (manually, mid-program, or at the end of the program), whether responses are anonymous, and a follow-up reminder delay. A program can have several surveys.

Learning & content

Package — a bundle of exercise steps and content modules grouped as one unit of the journey. Key settings: which exercise package to use, whether it’s assigned automatically when a participant joins a cohort, the completion requirement (percentage of steps), an optional deadline with a reminder schedule (one or several reminder days before the due date), and whether optional steps can be skipped. A package can also act as a prerequisite: require it (at its own completion percentage) before a participant is included in matching, or before sessions can start. The display name can be overridden, including per language, and the package can carry its own competency set for competency-selection steps inside it. A program can contain multiple packages.

Training — a training module with a start and a deadline on the timeline. Key settings: title and description, the content link, which role it targets, the due date (none, a fixed date, or a number of days after enrollment), whether it’s required, and whether completion is tracked.

Resource — reference material (a document, video, or link) participants access at their own pace. Key settings: title and description, the resource type and link, which role sees it, and whether it’s marked required. A program can have several resources.

Tasks (to-do) — a general-purpose task step on the journey. Key settings: title and description, which role it targets, the due date (none, a fixed date, or a number of days after enrollment), and whether it’s required.

AI & support

Sidekick — the AI assistant made available to participants. Key settings: which roles can use it and the assistant’s persona name.

Joining & reporting

Request form — the application/nomination step for getting into the program. Key settings: whether people can apply themselves and/or managers can nominate, the approval workflow (approval type, reminder and escalation timing, and whether approval is required before matching), the application window (fixed dates or always open), whether accepted applicants are auto-assigned to a cohort and which one, per-role application forms for support receivers and support givers, which roles are eligible, whether accounts are created automatically for new applicants, and an optional company email-domain restriction.

SR report — the report a support receiver (mentee/coachee) can generate and share summarizing their program activity. Key settings: how often it can be generated, whether goals and sessions are included, and whether it’s shared with the participant’s manager.