How policy versioning and re-consent work

This page explains how MapleGather keeps a versioned record of the policies your members agree to, and how it asks members to re-accept a policy when it changes.

The short version

MapleGather keeps a versioned history of the policies your members agree to — your privacy policy, terms of service, waiver, membership terms, email marketing consent, and similar documents. Each time you change one, you publish a new version. Published versions are permanent, so you always have an exact record of what each member agreed to and when. Waivers and membership terms can apply to your whole org or to a single membership level.

How it works

The version lifecycle

A policy version moves through three states:

Draft — you’re still writing it. Only admins see it, and you can edit the text freely.
Published — the current, active version. Its text is locked, and members consent to this version.
Superseded — a newer version has replaced it. It’s deactivated but kept for your records, so older consent records still point to the exact text the member saw.

Publishing supersedes the previous version

When you publish a new version of a policy, MapleGather automatically supersedes the previous current version of that same policy. There’s only ever one current version of a policy at a time — for a given scope (see level scoping below).

Published versions can’t be edited

A published version is immutable. If you need to change the wording, you publish a new version instead of editing the old one. This is deliberate: a consent record is only trustworthy if the document behind it never changes after the fact. Publishing itself is also final — there’s no un-publish; a correction ships as a new version.

Org-default vs. level-scoped waivers and terms

Two of the member-facing policy types — the waiver and the membership terms — can be scoped. A version is either:

Org default — it applies to every member whose level doesn’t have its own version, or
Level-scoped — it applies to one membership level’s members.

When a member’s level has its own level-scoped version, that version wins for them; otherwise they fall back to the org default. So a member on the “Youth” level sees the Youth waiver if one is published, and the org-default waiver if it isn’t — and a member on a different level never sees the Youth waiver. An org-default version and a level-scoped version of the same type can both be current at once, each tracked independently. Publishing a level-scoped version supersedes only the previous version of that same level — it never removes the org-default fallback that other levels rely on. Every other policy type (privacy policy, terms of service, and so on) applies org-wide only.

When you publish, you choose how members handle the change:

Require re-consent — members are asked to review and accept the new version. Until they do, a persistent banner appears on every portal page — they can keep using the portal, but the banner returns until they accept.
Notify only — members are told by email that the policy changed. No acceptance is required, and there is no in-app banner — the change is announced by email only.

What a member sees

For a require-re-consent publish, a member sees a banner the next time they open the portal: “We’ve updated our [policy] — please review.” Selecting Review and accept opens the published text, and selecting Accept records their acceptance. A member is only ever shown the version that applies to their level. For a notify-only publish, the member receives an email — nothing appears in the app, and there’s nothing to accept in the portal.

What gets recorded

Every acceptance adds a new “Accepted policy” event to the member’s consent history, carrying the exact policy version they accepted. This is true for the re-consent banner and for the waiver or membership terms a member accepts when they join or renew — all of them land in the same consent history as an “Accepted policy” event tied to a specific version. Because superseded versions are never deleted, that reference always resolves to the precise text. Consent history is append-only: acceptances, opt-ins, opt-outs, and corrections are all added as new rows, never overwritten.

Why it works this way

If a member or a regulator asks “which version of the waiver did this member agree to, and when?”, the versioned, append-only record answers exactly. Editing a published policy in place would break that guarantee — the record would point at text that no longer exists. Asking members to re-consent (rather than assuming it) gives you a defensible, member-by-member trail for material changes. Level scoping lets an org hold one legal document for most members and a different one for a level that needs it (say, a youth or a family plan) without losing the org-wide default.

Edge cases & boundaries

A superseded version stays in the list so historical consent records always resolve — it’s never deleted.
A notify-only version has no re-consent follow-up list, because no acceptance is required, and it produces no in-app notice — the member is informed by email only.
An org-default waiver and a level-scoped waiver of the same type can each be current at once; a member sees only the one that applies to their level.
Jurisdiction-specific policy text for non-US audiences is available but gated behind an extra permission; US is the default.
An admin can record a member’s acceptance on the member’s behalf — for example, after a phone call. This clears the member from the follow-up list.