Handshakes

Handshakes

What a handshake is

A handshake is a structured agreement step between two (or more) participants in a program. Instead of one person filling out a form on their own, a handshake asks the people involved to confirm something together before it counts as settled.

Two common examples:

• A coach and mentee agreeing on how they’ll work together — a shared working agreement, often built from a form both sides review.
• A support receiver sharing their development goals with a manager or coach for approval — the goals are captured once, then shared for the other side to review and sign off on.

Because a handshake is a two-way (or multi-way) confirmation rather than a single submission, it always tracks who still needs to respond and won’t be marked complete until the required people have weighed in.

Where it lives: inside the program journey, not a separate menu

Handshakes are not a standalone section of the admin app. They are configured as one step type within a program’s journey — alongside the program’s other steps (forms, sessions, exercises, and so on). If you’re looking for “handshakes” in the main navigation, you won’t find a dedicated menu for it; it lives inside the program builder as an item you add to the journey.

There is a separate, tenant-wide Handshake Templates library. This is where reusable handshake blueprints are created once and then reused across multiple programs, so a program admin doesn’t have to configure the same agreement from scratch every time. When setting up a program, an admin can either start from one of these templates or configure a handshake step directly for that program’s journey.

When it happens: typically right after a match is formed

The most common moment for a handshake to fire is right after two people are matched together (for example, a coach and the person they’ll be supporting). Once that pairing is confirmed, the handshake step is triggered automatically and the relevant participants are asked to complete their part.

Handshakes can also be configured to trigger at other points in the journey — for instance, when someone joins a cohort or after they’ve set their development goals — but “right after matching” is the typical and most common trigger point admins should expect.

The decision flow, in plain terms

Once a handshake is triggered, it moves through a simple back-and-forth:

1. Someone proposes or shares content. Depending on the handshake type, this might mean submitting a form (a working agreement) or sharing a set of development goals.
2. The other party reviews it. They can do one of three things:
   • Approve it — accepting the agreement or goals as presented.
   • Reject it — declining outright. This ends that handshake; a new one would need to be started if the parties want to try again.
   • Ask for changes — sending it back with feedback. The first party can then revise and resubmit, and the review cycle starts again.
3. It’s complete once the required approvals are in. Depending on how the handshake step is configured, that might mean everyone involved needs to approve, only the higher-authority participant (e.g. a manager) needs to approve, or just one person’s approval is enough to finish it.

While a handshake is waiting on someone, it’s shown as awaiting that person’s response, so it’s always clear whose turn it is to act. Once approved or rejected, a handshake is final — it won’t reopen on its own.

Key terms admins will see

• Working agreement / Coach-Mentor agreement — a form-based handshake used to set expectations between a coach and the person they’re supporting.
• Development goal handshake — a handshake used to share and approve a person’s development goals.
• Approval rule — the setting that decides whether all participants must approve, only the senior participant must approve, or any one approval is enough.