Approval chains

An approval chain is the list of tiers that must sign off before a record counts as approved. You configure one chain per surface — the kind of thing being approved — from Settings → Approval Chains.

The surfaces you can configure

Each surface lists three checkboxes — Chapter, Regional, National — and approvals always travel in that order. Not every checkbox is available on every surface: Service hours greys out Regional for a reason unrelated to national review — see Service hours is different below.

National is always required — with one named exception

The National checkbox is ticked and greyed out on every surface except Service hours. On every other surface the platform refuses a chain that does not end at national review, so there is no configuration in which a record becomes approved without your headquarters seeing it.

A tier you leave unticked is simply not part of the chain — it is skipped, and nobody is ever asked to review at it.

Service hours is different

Service hours is the one surface where national review is optional rather than mandatory. Its default chain is chapter only — officers keep approving their own chapter’s logged hours exactly as before this shipped. The reasoning the platform enforces at the code level (a surface has to declare why it is allowed to skip national, not just that it does): the fact being attested — “this member did this work” — is verifiable locally, and a large, multi-chapter organization would otherwise put thousands of entries a month in front of headquarters for no additional certainty.

You are not limited to the default: National can be ticked here, exactly like any other surface — an organization that wants headquarters oversight of logged hours configures chapter → national and gets it.

Ticking National on Service hours creates a new admin surface that did not exist before: entries awaiting the national tier show up in an org-wide queue rather than on any single chapter’s page, because no chapter-scoped screen can show work that is not that chapter’s to finish. See Service hours settings → The national approval queue for where to find it and how it works.

Payment plans cannot add tiers

Dues payment plans is the mirror case: it is national-only, fixed. The chapter and regional checkboxes are not offered at all — you cannot widen this chain the way you can widen Service hours. See Payment plans → Regional review is deprecated for what this replaced. Because the chain cannot change, saving never moves a payment plan request.

Saving a change tells you what it will move first

Adding a tier changes work that already exists. Press Save and the platform counts, before writing anything:

• In review — records currently sitting in a pending state. On Compliance requirements, Member add requests, Account requests, Member status changes and Big/little assignments, within a few seconds of saving, each record in review is put in the queue of the first tier in the new chain that has not signed off. Sign-offs from earlier tiers still count. If you add a tier ahead of one that has already signed off, the record goes through the new tier first and then back through that later one. Other surfaces do not move records yet: each keeps its status until someone acts on it, and only the tier the new chain says is next can act.
• Already approved — records that are finished today. These are not reopened. A record that has been approved stays approved; a newly ticked tier applies to work that is still in review and to everything submitted from now on. The figure is reported so you can see how much settled work the new tier will never have looked at.

If the in review count is above zero you get a confirmation dialog naming both numbers, and nothing is saved until you confirm. Removing a tier never reopens anything, so it saves without a prompt. On Compliance requirements, Member add requests, Account requests, Member status changes and Big/little assignments, records that were waiting on the removed tier move on to the next tier still owed.

A requirement with its own approval chain is not moved by a change to your organization’s chain. An account request that names no chapter has only the national tier, so it never moves.

No more auto-escalation

Before approval chains, a national admin reviewing a record that was still sitting at the chapter or regional tier could approve it outright and the platform would escalate through every remaining tier at once. That made a configured tier advisory — it could be bypassed, and nothing recorded that it had been.

That behaviour is gone. Each tier is now approved by someone who holds that tier, one decision at a time. A national admin who tries to approve at the chapter tier is refused.

The same collapse existed on member add requests and big/little assignments and went with them:

• A national admin reviewing a member-add request at the regional tier used to clear the organization tier in the same click, and a national admin submitting one approved it outright.
• Big/little requests were never really tiered at all. The three “pending” labels only decided where a request entered; whichever tier looked at it first approved the whole thing.

A member add request now has a chapter tier your officers can action — the chapter tier existed on paper before and no officer could review anything. And a big/little relationship is written only when the whole chain completes, not when the first reviewer clicks Approve.

Big/little pairs that cross chapters

A big and a little can be in different chapters, and different regions. Either side may review: the chapter tier is held by an officer of either chapter, and the regional tier by an admin of either region. Which tiers apply is decided by the little’s chapter — they are the person the relationship is recorded on — so a little in a chapter with no region has no regional tier even if the big does. When you change the chain, in-flight pairings are re-routed using the same either-side rule for who may review.

One-step adds still exist, and now leave a record

A national admin adding a member from the chapter page, or recording a big/little pairing directly, still does it in one step. What changed is that the platform now writes an override for every tier that step skipped, attributed to you and with a reason, so the record says who was never asked.

If your organization has switched overrides off, that one-step path cannot record what it skipped — so it quietly becomes an ordinary queued request that walks the chain instead. Nothing fails; the shortcut is simply unavailable, which is what turning overrides off asks for. That queued request counts your own sign-off, so if you later change the chain and an earlier tier is left waiting, the request comes back to you to approve again at the end.

Skip tiers with no reviewer

Each surface has a Skip tiers with no reviewer switch, on by default. When a configured chapter or regional tier has nobody eligible to review it, the record advances instead of waiting in front of nobody.

Every automatic skip is recorded on the record, exactly like an override you recorded yourself and labelled as the system’s, so the history shows that the tier was never actually reviewed. It is also permanent for that record: if you appoint a regional admin next month, records that already passed the skipped tier are not dragged backwards to it.

Turn the switch off if you would rather a record sat visibly stuck than advanced without that tier looking at it. You will then need to seat a reviewer, or record an override, to move it.

When a tier has nobody, somebody is told

When a record is waiting on a tier with no eligible reviewer, the platform no longer treats “notified nobody” as a successful notification. It is logged, and the organization’s national admins are notified — they are the only people who can record an override and unstick it.

Skipping a tier on purpose: the override

Chains still get stuck — an officer graduates, a regional admin goes dark, a deadline is real. A national admin can record an override for a specific tier on a specific record. An override:

• requires a reason, which is stored with it;
• is attributed to the admin who recorded it, and audit-logged;
• advances the record to the next tier that still has to act.

Where to record one

Open the org Compliance page, open the chapter’s card, and expand the requirement in the drill-down. A Skip a tier button sits under the submissions. It appears only when all of the following are true, because anything else the server would refuse:

• you are a national admin of the organization;
• overrides are enabled for the surface;
• the record is awaiting review; and
• there is a tier left to skip that is not the last one in the chain.

You cannot override the last tier

The final tier of a chain — in practice, national — cannot be overridden, and the option is not offered. Skipping it would leave nobody to act, so the record would settle as Approved with no reviewer recorded against it: an approval attributed to no one, produced by the one mechanism that exists to make every skip attributable. If you want a record approved, approve it.

An override ends when the chain restarts

An override lasts until something restarts the record’s chain. A rejection is the usual one: rejecting a submission clears every tier’s sign-off so the new evidence is examined by everybody, and the override is superseded at the same moment for the same reason — a decision made about last term’s evidence is not a decision about the new file. Resetting a numeric requirement does the same.

The record’s progress shows the tier as satisfied, with the override as the explanation for why it was never actually reviewed; a superseded one stays visible, labelled as no longer applying, so the history reads honestly.

What this means for a chapter with no seated officers: you will need a fresh override each time the chain restarts. If that chapter’s submission is rejected and resubmitted, the chapter tier is waiting again and somebody has to record a new skip with a current reason. That is the intended behaviour — an exemption granted in September should not still be silently clearing tiers in March — but it does mean an officer-less chapter is not a one-time fix. Seating an officer is.

Status changes, account requests, and PNM fraternal names now use this too

Member status changes, account requests, and PNM fraternal name approvals were each a single national-admin decision before this release — every review action on them required the national role, full stop. They now walk the same chain-configuration model as everything else here: tick Chapter and/or Regional and a chapter officer or regional admin can action a record before it ever reaches your national admins.

A national admin can no longer approve one of these at the chapter or regional tier on the strength of holding the national role — the same refusal that already applies to member-add and big/little requests now applies here too. Their only remaining one-step path is the same override mechanism: a recorded, reasoned skip of each tier that step bypassed.

Account requests have one wrinkle. The person requesting an account isn’t a member yet, so there’s no chapter to derive the chapter tier from. It resolves against whichever chapter the request is asking to join — and if the request doesn’t name one, the chapter (and, with it, the regional) tier simply doesn’t apply, and the request goes straight to your national admins. If an admin later assigns a chapter to such a request while approving it, that does not reopen the decision or send it back down the chain — the approval that just happened stays final.

PNM fraternal names are a different thing from PNM applications. This surface only covers a PNM’s proposed name — whether “Robert” registers as “Bob” or “Rob” on the roster. It has nothing to do with whether the applicant is accepted, which is the separate PNM applications row above.

What existing organizations got on upgrade

Organizations that were already running the chapter → regional → national compliance ladder were seeded with exactly that chain, so review routing did not change on the day this shipped. What changed for them is auto-escalation, which stopped. Member add requests and big/little assignments were seeded the same way when they moved onto the engine, and member status changes, account requests, and PNM fraternal name approvals were seeded identically when they moved onto the engine in this release.

Organizations created after the upgrade start with each surface’s own default: national only for every surface except Service hours, which starts chapter only (see above), until you tick more tiers here.

Service hours was grandfathered the same way as compliance: every entry that was already approved before this shipped is stamped as satisfied at every tier, so ticking a new tier here never reopens historical entries — it only starts applying to entries still pending review and to anything logged from now on. Dues payment plans needed no grandfathering the same way, because the migration moves every organization to [national] regardless of what Regional admins may review requests used to be set to (see Payment plans).

PNM applications

An applicant is reviewed on their own record, and this row is the chain that governs it — chapter and national by default, with regional available if you want it. National review is always the last tier and can’t be removed, as on every surface above except Service hours.

Widening this chain re-routes applications already in review: an applicant currently satisfied through the chapter tier who suddenly needs regional review too goes back in front of a reviewer. As with any surface, Save reports the impact before it writes anything — how many applications are in review and would move, and how many are already decided and won’t be reopened — so you can see the effect before you confirm it. See PNM program and Reviewing applicants.

Giving one requirement its own chain

The chain on this page governs every compliance requirement in the organization. When one requirement needs a different one — a short intake form that should not wait on a regional review, say — you set that on the requirement itself rather than narrowing the whole policy.

Go to Compliance → Manage Requirements, then Edit a requirement (or Ad-hoc Requirement to create one). The form carries an Approval chain section with two choices:

• Use the organization policy — the default, and what every requirement does unless you say otherwise. The chain it will run on is named underneath.
• Custom chain for this requirement — tick the tiers that must approve this one requirement.

National approval cannot be removed, on this page or on a requirement, so it is shown ticked and locked. Any tier this surface has no reviewer path for is shown locked too, with the reason on hover.

Changing a requirement’s chain re-routes that requirement’s in-flight records, the same way changing the policy above re-routes the surface’s. Requirements that carry their own chain are marked Custom chain in the requirements table.

This page tells you how many there are. Below the chain table, the Requirements with their own chain card reads “N requirements override this chain” and Review them opens the requirements table filtered to exactly those requirements, across every semester. The chain above is the answer for every requirement that is not marked Custom chain; the card is how you find out whether there are any without leaving this page.

The card counts requirements, not chapters or records, and it does not say what each one’s chain resolves to — that varies by chapter, since a tier with no region, no chapter or no eligible reviewer is dropped for that chapter.

Related

• Multi-tier compliance approval — what each tier does
• Compliance program overview
• Service hours settings — the national approval queue this surface’s chain can create
• Payment plans — policy & review queue — why this surface cannot add tiers
• Permissions matrix