Officer transition checklist

GreekManage does not ship an officer-transition workflow in v0.62.1. There is no auto-transfer step at election close, no chapter-officer-handoff page, no role-change wizard, and no scheduled cron that flips roles on a date. A transition is a manual sequence: your national admin patches role on each affected membership, and you transfer institutional knowledge out-of-band. This page is the playbook so nothing slips through the cracks.

Who can use this

Carrying out a transition involves three people: the outgoing officer (you), the incoming officer (your successor), and a national admin at your org. Regional admins cannot promote or demote officers; the role-write guard rejects them.

How a role change actually happens

The role on a member's record is the source of truth — the choices are Member, Officer, President, Advisor, and Alumni. Only a national admin or platform admin can change someone's role. Officers and regional admins are blocked at the backend regardless of how their UI is configured, and the same rule prevents an admin from changing their own role (an admin who wants to step down has to ask another admin to do it).

When the role actually changes, the platform writes one audit-log row capturing who changed what, when, on whose membership, and from which role to which. The affected member also receives an in-app notification ("Your role in your chapter was changed from X to Y") that surfaces in the notification bell — it does not go out by email by default.

Practical sequence:

1. The national admin opens Members and navigates to your successor's profile.
2. They open the role dropdown and select Officer or President.
3. The PATCH fires; the audit row is written; your successor is notified.
4. The national admin then opens your profile and sets your role back to Member (or whatever the post-officer role should be).
5. Officer-only UI is hidden the moment role flips on each record — no logout/login needed.

That's it. There is no separate "handoff" entity, no shared "officer pool", no role expiry.

What the timing changes

A transition rarely happens on a clean week. Some scenarios to think about before you flip the roles:

• Mid-election — if an election is open in your chapter or org, do not transition until it closes. Officers and regular members both vote (one ballot, no role-weighted votes), so the vote is unaffected. The thing that breaks is authoring: only an org admin can finalise, but the new officer team should be in place before any post-election ceremonial action.
• PNM intake in flight — proposing PNM names is officer-gated. If you're mid-cycle, hand off the proposal queue to the incoming officer same-day; do not leave gaps where a new proposal would be rejected. See PNM proposing names for the officer workflow.
• Open compliance period — chapter-tier compliance submissions are officer-actionable. Make sure your successor knows which submissions are pending review and which are mid-draft.
• Active retain alerts — open alerts are visible across officers and admins, so a transition during an open alert is fine. Resolution notes follow the member, not the officer.
• Mid-billing-cycle — billing is read-only for officers, so timing doesn't matter for invoice generation. But if your treasurer is the officer transitioning, brief them on which invoices are open and what conversations are in flight with members.

If you can pick a date, the week after finals in a typical semester is the cleanest moment: fewer events, fewer submissions, and your successor has a real break before active duty starts.

Outgoing officer: two weeks before

Start a paper trail. Don't rely on memory.

• Confirm who's incoming with your chapter — election results, appointment, or however your org chooses officers.
• Schedule a 30–60 minute one-on-one with your successor.
• Clear what you can in Approvals → Big/Little so they aren't inheriting old items. Your successor will inherit the queue position; clearing it gives them a clean start.
• Submit any status-change requests you've been meaning to file. Officers can submit them but only national admins can approve; getting them in the queue ahead of transition is faster than hoping your successor remembers.
• Note which chapter advisors you've been working with. The advisor relationship doesn't auto-transfer; introduce your successor by email.

Outgoing officer: one week before

• Walk your successor through your weekly routine — what you check, when, and where.
• Show them the surfaces you use (Approvals, Compliance, Events, Retain) signed in side-by-side. There's no "shadow mode"; you can't impersonate them. The next-best thing is sitting next to them and pointing at the screen.
• Document where chapter files live (in Documents) so they don't get lost.
• Forward open conversations — DMs you've had with members about status changes, big-little disputes, or compliance — to your successor in plain email. The platform doesn't share DMs.
• Drop your saved member-directory views in a chat: those don't transfer either (SavedMemberView is keyed to the user).

Day of transition

• Email or message your national admin asking them to flip the officer role on both memberships — yours back to member, theirs to officer. Include both names and the chapter; the admin needs both PATCHes.
• Verify the change went through by opening your successor's profile in Members and confirming the new role. Then open yours and confirm you're back to plain Member.
• Spread the word in your chapter — chapter meeting, Engage post, whatever you normally use. There is no auto-broadcast.
• Optionally request a copy of your audit-log entries before your access narrows. National admins can pull them from Settings → Logging filtered on your user, on the role-change resource type, and on any other resources you actioned during your term.

Incoming officer: orientation

If you're the officer coming in, here's what to do in your first week:

• Open the docs site (you're reading it) and scan the Officers section. Three pages matter most: Overview, Approvals queue, Compliance submissions. The rest you can read as topics come up.
• Open the Approvals → Big/Little tab and clear anything pending. This is your most visible queue.
• Open Compliance and look at what's due in the next 30 days. Submit anything overdue or about to be.
• Open Events and look at the next two weeks. Mark anything mandatory.
• Open Retain and acknowledge any open alerts — even if you're not ready to resolve them, acknowledgement signals "an officer has eyes on this."
• Introduce yourself to your regional admin and your national admin via email. They're your escalation path for anything you can't do (role changes, refunds, bulletin posting, election authoring).
• Pin the docs URL in your phone browser. You'll come back here.

What national admins actually do during a transition

The national admin's part is small but load-bearing. They don't need to read this whole page — three things:

1. PATCH the incoming member's role to officer or president.
2. PATCH the outgoing member's role back to member (or alumni if they're graduating).
3. Confirm both audit-log rows wrote (check Settings → Logging).

Common admin mistakes:

• Forgetting to demote the outgoing officer. A chapter can have multiple officers, so this isn't a constraint violation, but it does mean the outgoing person still sees officer-only UI. Fix it the moment you notice.
• Demoting before promoting. It doesn't matter mechanically but a few minutes where neither member has officer access can stress everyone out. Promote first, demote second.
• Patching with "role": "Officer" instead of "role": "officer". The choices are lowercase. Capitalised values will be rejected by serializer validation.

Things that don't transfer automatically

Item	What happens
Officer-level menu items	Hidden as soon as your role flips. No logout / login needed — the navigation re-renders the next time it queries your role.
Pending approvals / submissions	Stay where they are. Reviewers and the new officer pick them up. The submitter is preserved; the reviewer is whoever clicks Approve next.
Things only org admins can do anyway (elections, bulletins, payment config, refunds, surveys, name-checks)	Untouched by officer transition — they were never officer-scoped.
Direct messages / saved drafts	Stay with you. The new officer cannot read your DMs.
Saved member-directory views (SavedMemberView)	Tied to your user. The incoming officer needs to recreate any filters they want.
Custom notification preferences	Tied to your user. Default settings apply for the incoming officer until they configure their own.
Forum subscriptions	Tied to your user. If you were subscribed to a chapter-leadership thread, your successor must subscribe themselves.
Forum-level admin role	Granted per forum, not automatically by chapter office. If you were a forum admin, your national admin must add your successor to the same forum's admins.
Bulletin / post authorship	Posts stay attributed to you. Don't delete them on your way out — they're history.
Outgoing audit-log access	You can see your own audit entries via the standard log viewer until your account loses officer access; ask for a copy of the relevant rows before that happens.
Compliance submissions you authored	Records of who submitted what are preserved. Your successor inherits the next due-date, not the audit trail.

Common pitfalls

• Don't assume the role flip happens automatically when an election finalises. It does not in v0.62.1. There is no signal handler on ElectionResult that promotes the winning candidate. The national admin must PATCH manually.
• Don't promote your successor yourself. The dropdown won't let you, and the role-write guard rejects the request server-side.
• Don't demote yourself. The self-demote guard blocks it; the API returns 403.
• Don't delete bulletins or posts on your way out. They're history. If something's actually wrong, ask an admin to moderate it; don't tombstone it from your account.
• Don't share your password with your successor. Officer access is a role on a membership, not a password. Have the admin promote them properly.
• Don't expect notifications to reach the new officer about old in-flight items. Notifications are sent to a recipient user_id; they don't follow the role.

Audit log

Every officer role change writes one audit-log row. Org admins can read these via Settings → Logging filtered on the role-change resource type. Each row includes:

• from_role and to_role
• The affected member's email
• Chapter ID, name, and designation
• The acting user (the national admin who made the change)
• IP address and timestamp

If you want a copy of your own role-change history for your records, ask the national admin to export the filtered log before you transition out.

Related

• Officer overview — what you can do as an officer
• Approvals queue — your most-used surface
• Compliance submissions — chapter-tier action
• Elections (officers) — you vote, you don't author

Last verified against v0.62.1 (2026-05-11).