> ## Documentation Index
> Fetch the complete documentation index at: https://docs.1club.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Documents and waivers

> Define signable documents (liability waivers, terms, policies) under Settings > Bookings > Waivers, and use document rules to require the right members to accept them, with audience targeting and mandatory gating.

Documents and waivers are the signable agreements your members accept - liability waivers, terms of service, codes of conduct, and policies. Each document is paired with one or more **document rules** that decide who must accept it and how strictly acceptance is enforced, so the right people are asked to sign the right agreements at the right moment. Owners and admins set up documents and rules, and members accept them during signup, in the portal, or in the app.

## When to use it

Rules target each agreement at the people it applies to, and a mandatory document gates a member until they accept it. You stop chasing signatures by hand, and nobody is asked to sign something that doesn't apply to them.

Typical uses:

* **A waiver for one plan only** - a climbing gym requires a lead-climbing liability waiver, with a typed name, only from members on its **Lead Climbing** plan.
* **A minor's waiver signed by the parent** - a jiu-jitsu academy targets its youth waiver at dependents, so the parent accepts it for each child during signup.
* **A release for every drop-in** - a padel gym asks every drop-in visitor who pays per court to sign a court-use release.

See [Worked examples](#worked-examples) for the exact rule settings.

## How it works

The same document can be targeted by several rules. When rules overlap, the strictest wins: any mandatory rule makes it mandatory, and any typed-name rule makes typed name required.

A signature counts as accepted regardless of the stored document version, so cosmetic edits to a published document don't re-gate members who already signed.

## Authoring a document

Manage documents and their rules from **Settings** > **Bookings** > **Waivers** (route `/settings/operations/waivers`). The page has two sections: **Documents** (the agreements themselves) and **Document Rules** (the targeting and enforcement layer on top of them).

A document is a CMS content item with its type set to `document`, so it is written in the same block editor as your other [content](/marketing/content) (posts, FAQs, reusable blocks), with the same title, slug, body, and language-variant support.

1. On **Settings** > **Bookings** > **Waivers**, click **Add document**. This opens the content editor with the type pre-set to `document`.
2. Give it a **Title** (for example, `Liability waiver`) and write the body in the block editor.
3. Set the **status** to **Published**. Only published documents are enforced - a draft or archived document is skipped by every rule, so members are never asked to sign it.
4. Save. The document now appears as a card in the **Documents** section and becomes selectable when you create a rule.

<Tip>
  Write one document per agreement (waiver, terms, code of conduct) so each can be targeted, versioned, and reported on independently. Use language variants on the document itself so members see the agreement in their own language when they sign.
</Tip>

## Creating a document rule

A rule connects a published document to an audience and sets how acceptance is enforced.

1. In the **Document Rules** section, click **Add Rule**.
2. Fill in the dialog:
   * **Name** - An internal label for the rule (for example, `Adults - liability waiver`). Members never see this.
   * **Document** - Pick the published document this rule enforces.
   * **Contact Filters** - Narrow the audience (see below). Leave a filter empty to place no restriction on that dimension.
   * **Optional** - Off by default, so documents are mandatory unless you flip this on.
   * **Require review and typed name** - Force the member to scroll through the document and type their full name before accepting.
   * **Active** - Whether the rule is currently in effect.
3. Click **Save**. To edit or delete a rule later, click its card in the **Document Rules** section.

## Contact filters (audience targeting)

Filters decide who a rule applies to. The four categories combine with **AND**: a contact must match every category that has values set. Within a single category, matching **any** value is enough (**OR**). A category you leave empty places no restriction, so a rule with no filters at all applies to everyone.

### Contact Types

Match on the kind of contact. The available types are **Member**, **Drop-in**, **Lead**, **Staff**, **Lapsed**, and **Contact**. Use this to ask, for example, only drop-in visitors to sign a one-time liability release, or only members to sign the full membership terms.

### Plan

Match on the plans a contact holds through an active membership. Select one or more [plans](/sales/plans); the rule then applies to anyone whose active membership is on one of those plans. During signup - before a membership exists - the rule matches against the plan the member is purchasing in the wizard.

### Tags

Match on contact tags (for example, a `competition-squad` or `under-18` tag). Use tags when your audience does not map cleanly to a contact type or plan.

<Warning>
  Tag filters are skipped during the public signup flow, because a brand-new contact has no tags yet. A rule that relies only on a tag filter will not surface at signup - it will apply later, once the contact is tagged. For documents that must be signed at signup, target by contact type, plan, or household role instead.
</Warning>

### Household Role

Match on a contact's role within a [household account](/members/accounts): **Owner**, **Adult**, or **Dependent**. This is how you route a minor's waiver to the `dependent` role so it is presented to the guardian to sign on the child's behalf.

## Mandatory gating vs optional

Every rule is **mandatory** unless you switch on **Optional**.

* **Mandatory** (default) - The member cannot finish using the platform until they accept the document. Mandatory documents feed the incomplete-setup state: an authenticated member with an unsigned mandatory document is gated until it is signed.
* **Optional** - The document is offered but never blocks access. Optional documents are useful for informational consents (marketing preferences, photo release) that you want to record but not enforce.

## Typed-name acceptance

**Require review and typed name** makes acceptance deliberate: the member must scroll through the full document and type their full name before the accept button unlocks. This produces a stronger evidentiary record for waivers and legal agreements.

This option is only meaningful on mandatory documents. If a rule is optional, the toggle is disabled and the setting is forced off - review and typed name can only be required on mandatory documents. If you make a mandatory rule optional later, its typed-name requirement is cleared automatically.

## Worked examples

### Climbing gym - lead-climbing waiver tied to one plan

A climbing gym requires a belay-and-lead-climbing liability waiver only from members on its **Lead Climbing** plan; recreational top-rope members do not need it.

1. Author a published document `Lead climbing liability waiver`.
2. Create a rule named `Lead climbers - liability waiver`:
   * **Document**: `Lead climbing liability waiver`
   * **Plan**: `Lead Climbing`
   * **Optional**: off (mandatory)
   * **Require review and typed name**: on
3. Now only members whose active membership is on the Lead Climbing plan are gated until they scroll through and type their name to accept.

### Martial arts - a minor's waiver signed by the guardian

A jiu-jitsu academy enrolls children through a household account, and the parent must accept the injury-risk waiver for each child.

1. Author a published document `Youth participation and injury-risk waiver`.
2. Create a rule named `Dependents - youth waiver`:
   * **Document**: `Youth participation and injury-risk waiver`
   * **Household Role**: `Dependent`
   * **Optional**: off (mandatory)
3. During signup, the guardian completing the wizard is shown the dependent's waiver and accepts it on the child's behalf. The resulting signature records the child as the subject and the guardian as the signer. See [Document signatures](/members/document-signatures) for how proxy signing is recorded.

### Racket sports - one-time release for drop-in visitors

A padel club lets non-members pay per court but wants a signed release from every drop-in.

1. Author a published document `Drop-in court-use release`.
2. Create a rule named `Drop-ins - court release`:
   * **Document**: `Drop-in court-use release`
   * **Contact Types**: `Drop-in`
   * **Optional**: off (mandatory)

### Whole-club code of conduct

To require every contact to accept a code of conduct, create a rule with **no contact filters** and leave it mandatory. An empty filter set means the rule applies to everyone.

## Tips and best practices

* **Publish before you target.** A rule pointing at a draft document silently enforces nothing. Confirm the document status is **Published**.
* **Name rules for their audience, not the document.** `Dependents - youth waiver` tells you at a glance who it hits; `Waiver rule 2` does not.
* **Prefer contact type, plan, or household role for signup-time documents.** Tag filters do not fire during public signup.
* **Keep documents single-purpose.** One agreement per document makes targeting, typed-name requirements, and the signatures ledger clean.
* **Use language variants** on the document so members sign in their own language; the signing flow resolves the variant that matches the member's locale.
* **Deactivate instead of delete** when you want to pause a rule but keep its history - toggle **Active** off rather than removing it.

## Troubleshooting

| Symptom | Likely cause | Fix |
| - | - | - |
| A member is never asked to sign a document | The document is not **Published**, or the rule is inactive | Publish the document; toggle the rule **Active** on |
| A rule does not fire at signup even though the audience seems right | The rule relies on a **tag** filter, which is skipped during public signup | Re-target by contact type, plan, or household role |
| The **Require review and typed name** toggle is greyed out | The rule is **Optional** - typed name is only allowed on mandatory rules | Turn **Optional** off to make the rule mandatory |
| Too many (or too few) members are gated | Filters combine with AND across categories | Widen by clearing a filter category, or narrow by adding values; remember an empty category means "no restriction" |
| A previously signed member is prompted again | Expected only when a new signature is genuinely required; cosmetic edits do not re-gate | Confirm the member has a signature on file in [Document signatures](/members/document-signatures) |
| A dependent's waiver is not offered during signup | The rule's **Household Role** does not include `Dependent`, or the document is unpublished | Add `Dependent` to the rule and publish the document |

## Related

* [Document signatures](/members/document-signatures) - The ledger of who signed what, when, and how, including guardian signing for dependents.
* [Content](/marketing/content) - The block editor and content types used to author document bodies and language variants.
* [Accounts](/members/accounts) - Household accounts and the owner/adult/dependent roles that household-role targeting uses.
* [Plans](/sales/plans) - The plans that plan-based targeting matches against.
* [Settings overview](/settings/overview) - Where Waivers lives among the other settings.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.