> For the complete documentation index, see [llms.txt](https://docs.range-mate.co.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.range-mate.co.uk/for-club-admins/membership-workflows.md).

# Membership Workflows

A **workflow** is a club-defined journey made up of ordered **stages**, with **requirements** (conditions) on each stage. It lets you spell out exactly what a member must do to move from one membership status to the next, instead of every move being a manual decision.

You can have:

* one **membership workflow**, whose stages map onto your membership statuses (probation, full member) and drive the real membership changes; and
* any number of **separate tracks** (for example, a Range Officer qualification) that don't touch membership.

Build and manage these under **Membership Workflows** in the admin menu.

{% hint style="info" %}
Only one **membership** workflow is allowed per club. Adopting workflows seeds a starter one that mirrors your existing probation → full member journey, which you can then customise.
{% endhint %}

## Creating a workflow

1. Go to **Membership Workflows → New workflow**.
2. Give it a **name** and **description**, and choose its **purpose** (membership or a separate track).
3. Add your **stages** and their **requirements** (below).
4. **Publish** it. Only published workflows apply to members. A workflow stays in **draft** until it has stages members can actually work through (a lone stage with no required conditions would finish instantly), and, for a membership workflow, every stage has a membership status.

A workflow moves through **draft → published → archived**. Archiving stops it applying to members. You can unarchive back to draft and re-publish.

## Stages

Add your stages. Their order **is** the path members follow, so it matters. You don't have to get it right first time: use the **up/down arrows** on each stage to rearrange them whenever you like. The first stage is where members start, and the last is where they finish.

For a **membership** workflow, each stage can be tied to a **membership status** (for example, probation) and given a **membership action** that runs when a member finishes the stage (for example, "passed probation").

{% hint style="info" %}
Each membership status maps to **one** stage. To break a long list of conditions into smaller steps, add more **requirements** to that stage rather than another stage for the same status. Two stages sharing a status would leave the second one unreachable, so the builder only offers each status once and won't let you save a duplicate.
{% endhint %}

{% hint style="success" %}
Tying a stage to a membership status drives the **real** membership changes when a member moves on. Billing, membership records and history all run exactly as they do today. See [The membership lifecycle](/for-club-admins/membership-lifecycle.md).
{% endhint %}

## Moving a member on

In this release, moving a member to the next stage is **always done by an admin**. The system works out when a member has met everything required and shows them to you to confirm. You make the actual move.

This is deliberate. Moving someone on usually needs a decision the system can't make for you: which membership tier to upgrade them to, whether they've paid, issuing a comp card. For a membership stage, you move them on with the **usual membership action** (for example, "passed probation"), which still collects the tier and payment as it does today. The workflow just tells you they're ready.

{% hint style="info" %}
A future release may add **automatic** moves for stages where no such decision is needed.
{% endhint %}

## Requirement types

This release ships six requirement types:

* **Manual sign-off.** You confirm it yourself, with an optional note. Use it for an admin's say-so, with nothing checked automatically.
* **Declaration signed.** Met when the member signs a declaration you choose. See [Declarations](/for-club-admins/declarations.md).
* **Attendance count.** Met when the member has a set number of **checked-in attendances**, optionally limited to **specific events**, **events with a given tag**, locations or event types. Use **Limit to specific events** to require attendance at a particular event. For example, set the count to 1 and pick your **safety day** or **induction** to mean "must attend the safety day". A recurring event counts as one event here, however many times it runs, so members can meet an "attend 3 times" requirement across its dates. Stress to members that **bookings don't count, attendance does**. See [Attendance & range logs](/for-club-admins/attendance-and-range-logs.md).

{% hint style="info" %}
**Picking an event vs tagging events.** The specific-event picker matches one event, which suits a **recurring** event (it stays the same event every time it runs). If you instead create a **brand-new event each time** you hold, say, a safety day, use **Limit to events tagged** instead. Tag every safety day the same (for example `safety-day`) and the requirement counts attendance at any of them, where pinning to one specific event would only ever match that one. See [Creating & managing events](/for-club-admins/managing-events.md#tagging-events) for how to tag an event.
{% endhint %}

* **Minimum time in stage.** Met once a minimum time has passed since the member entered the stage (for example, a legally required **three-month minimum probation**, and you can set longer). It updates on its own and just holds completion back until the time has passed.
* **ID approved.** Met once you've approved the member's proof of ID on their profile. Use it to make a stage wait until their ID is checked.
* **Police check cleared.** Met once the member's police check has come back clear. Sending or skipping a check does not satisfy it, so a stage with this requirement waits for the result. You record the result on the member's profile. If you want to let someone through without a clear check, **waive** the requirement for them.

### Required vs optional

Mark each requirement **required** or **optional**. Required ones decide when a member can move on. Optional ones are suggestions the member can tick off themselves, and never hold them back.

### What counts

By default a requirement counts from when the member **entered the stage**. You can change it to count **all time** instead.

{% hint style="warning" %}
Re-entering a stage (for example, after moving a member back) restarts the "since stage entry" counts for that stage.
{% endhint %}

## Reviewing and moving members on

A member's progress shows on their profile, with each requirement's status and who signed it off. From there you can:

* **Sign off** a manual requirement (with a note).
* **Accept** an automatic requirement by hand, for example a member who did the equivalent at another club. This sticks: the system won't overwrite your decision.
* **Waive** a requirement (with a reason) so it no longer holds a member back.
* **Reset** a requirement back to not done if you made a mistake.
* **Confirm** the move when a member's ready, or **force** it through if you need to.

Members who've met everything on their current stage appear in your to-do list under **Members ready to move on**.

{% hint style="warning" %}
**Resetting** a requirement can pull a member back below the bar for a stage they've already passed. **Force advance** moves a member on even though their conditions aren't all met. Both ask you to confirm first.
{% endhint %}

## Editing a live workflow

Editing a **published** workflow affects members part-way through it:

* **Disable, don't delete.** A requirement that members have started against is **disabled** (its history is kept) rather than deleted. A disabled requirement can be **re-enabled** at any time, and it then applies to members on that stage again. If you're sure you don't want it, a disabled requirement also has a **Delete** button that removes it for good, along with every member's history of it. That can't be undone.
* **Raising a target moves progress back.** If you raise a count (for example, attendances from 3 to 10), members who'd met it go back to "in progress" (3 of 10) at the next check.
* **Reordering or re-tying stages** reshuffles the path for members already on the workflow.

When you add, edit, disable or re-enable a requirement on a live workflow, the members already working through it are **refreshed automatically**, so the change takes effect straight away. You don't have to do anything. (A nightly refresh also keeps everyone up to date as a backstop.)

{% hint style="warning" %}
These changes apply to members part-way through, so make them deliberately. The builder warns you where it matters.
{% endhint %}

## Enrolments overview

**Club Settings → Workflow Enrolments** gives you the whole picture in one place: everyone currently working through a workflow, the stage they're on, how many of their required conditions are done, and whether they're ready to move on. Filter by workflow or status, and use the per-workflow **active members by stage** breakdown to see how people are spread out.

From here you can **refresh** progress, which recalculates it against the current setup. Handy if you've just changed a workflow and want to be sure everyone's caught up:

* **Refresh** on a single row updates that one member.
* **Refresh all** updates everyone in the workflow you're viewing.

{% hint style="info" %}
Refreshing is always safe. It recalculates automatic requirements and picks up ones you've added or re-enabled, but it **never** undoes a sign-off or waiver, and **never** moves a member's stage. Each member's profile still has the full detail and the sign-off, waive and move-on actions.
{% endhint %}