Skip to main content

Disabling a member's account (admin)

There is no single "Disable this user" button in v0.62.1. As a national admin, "disabling" someone is done by a combination of three distinct actions — each with different scope, reversibility, and audit trail. This page lays out what each does so you can pick the right tool. These are all admin-initiated — distinct from a member's own self-disable (see Account security).

The three levers​

LeverEffect on platform accessEffect on dataReversibilityUse when
Force logout (admin password reset)Member is logged out everywhere; needs new password to sign back in. Account still active.None — all data preserved.Member re-signs-in with the new password.Lost device, suspected credential leak, suspicious activity.
Status change → InactiveMember retains platform access (still in the directory, still sees the app), but excluded from active counts and most communications.All data preserved.Status change back to Undergrad/Associate/Alumni.Off-cycle members, leave of absence, sabbatical.
Status change → DisaffiliatedMember loses platform access entirely. Cannot sign in.All data preserved.Status change back. Account record still exists.Off-boarded, disciplinary removal, no longer a brother/sister.

There is no admin-initiated equivalent of the member's own self-disable. The self-disable card on Account Settings sets is_active=False on the user record and blacklists their tokens — only the member can trigger it on themselves.

When to use which​

Suspected credential compromise — force logout​

A member's laptop was stolen. A phishing email was clicked. You see a session from a country no one is in.

Use the Admin Password Reset flow. Open the member's detail page and reset their password — pick either "Email a reset link" or "Set a temporary password and notify them."

What happens:

  • A new password is set (or a reset link is emailed).
  • All of their outstanding refresh tokens are blacklisted, so any active session anywhere is forced to re-authenticate.
  • They receive a notification (email; in-app once they sign back in).
  • The action is written to the audit log with action UPDATE on resource password-reset.

The account itself remains active. Once they sign back in with the new credentials, everything is as it was. This is the right move for any "I'm worried about session security" scenario.

See Inviting admins for related admin-management actions in the same surface.

Off-cycle membership — status change to Inactive​

A member is on academic suspension. A brother took a year off. An alumnus paused engagement.

Use Status change → Inactive. From the member's detail page, change their membership status to inactive (or request the change if you're a chapter officer; org admins approve the request through the Approvals queue — see Approvals queue).

What happens:

  • Membership row's status flips to inactive.
  • They're excluded from active member counts, dues calculations, and most automated communications.
  • They still have platform access — they can sign in, see the directory, and engage if they want to. "Inactive" is a stats category, not a lockout.
  • The change is audit-logged.

If you want to keep someone in the system but stop counting them, this is the right lever.

Off-boarding or expulsion — status change to Disaffiliated​

A member has been removed from the organization. They no longer should have access.

Use Status change → Disaffiliated. Either as a direct admin status change or via the standard status change request flow.

What happens:

  • Membership status becomes disaffiliated.
  • They lose platform access — sign-in is blocked because their only membership grants no platform-access privileges (PLATFORM_ACCESS_STATUSES excludes disaffiliated).
  • Their authored content (forum posts, comments, donations, etc.) remains, but their profile is filtered out of active member views.
  • Active sessions are not immediately blacklisted by the status change alone. If you also need an immediate logout, follow up with Admin Password Reset to force token blacklist.

This is the appropriate lever for involuntary removal, disciplinary off-boarding, and any case where "no, they should not be in the system anymore."

What happens to their data​

Across all three actions, no member data is deleted.

  • Profile, memberships, custom field data: preserved.
  • Forum posts and comments: preserved and attributed.
  • Donations made: preserved and attached to the donor record.
  • Election votes cast: anonymized vote totals remain; vote audit log entries are kept.
  • Big/Little relationships: preserved; they remain in the family tree.
  • Compliance submissions: preserved.

If a member subsequently requests true deletion under GDPR/CCPA, that's a separate workflow — see Privacy & GDPR. The user-initiated deletion flow has a 30-day grace period before purge. Admins cannot bypass that grace period on a member's behalf.

Re-enabling​

Reversing a status change​

Status changes are themselves audited, requestable, and approvable. To re-enable someone from inactive or disaffiliated, open the member detail page, change the status back to undergrad / associate / appropriate alumni status, or submit a status change request that org admins approve. Their access returns immediately.

Reversing a force logout​

A force logout doesn't disable anything — once the member receives and uses the temporary password or reset link, they're back in. No additional step is needed.

Reversing self-disable​

Members who self-disable get a "Your account has been disabled. Contact an administrator to re-enable it." message. There is no in-product admin action to re-enable a self-disabled account in v0.62.1. The platform team can flip is_active=True directly in the database, but it's not exposed in the org admin UI. If a member self-disables and changes their mind, point them at the platform team.

What officers see that you don't​

Chapter officers can request status changes for members in their chapter, but they cannot approve the changes themselves — those land in your Approvals queue (see Approvals queue). Officers cannot trigger admin password resets at all; that's a national-admin-only action.

Regional admins can approve chapter officers' status change requests within their region, but otherwise share the officer scope for these actions.

Mobile differences​

All three actions are reachable on mobile via the iOS or Android apps. The member detail page renders well; the status change picker is a native select. Admin password reset includes a "set temporary password" sub-flow that's easier to complete on desktop because of the password field and copy-to-clipboard handling. None of the actions are mobile-blocked.

Errors and edge cases​

"Member still appears in active counts after status change to Inactive." Counts are cached briefly. Refresh after a minute. If it persists, the status change may not have been approved — check the Approvals queue.

"I disaffiliated them but they're still logged in." Disaffiliation alone prevents future sign-ins but doesn't blacklist active refresh tokens. Follow up with Admin Password Reset to force token blacklist. The combination guarantees they cannot continue.

"I want to disaffiliate the sole admin." You can't. You cannot disaffiliate yourself when you're the only active admin, and you cannot disaffiliate another admin without first removing their admin role. The system enforces at least one active admin.

"A member said they 'deleted their account' and wants it back." Two cases: (1) they self-disabled — no in-product re-enable; platform team is needed; (2) they requested deletion — they had 30 days to cancel using the token sent in the response; the platform team can look up the token if they lost it.

Troubleshooting​

"I don't see the password reset button." You need to be a national admin viewing the org member detail page. Regional admins and officers don't have it.

"Status change is stuck pending." It needs an approver one tier above the requester. As an org admin, you can usually apply status changes directly from the member detail page without going through the request flow — chapter officer requests always go through approval, but admin-direct changes don't.

"I want to nuke someone immediately and permanently." Three-step workflow: (1) Status change → Disaffiliated; (2) Admin Password Reset (blacklists tokens); (3) for data purge, file a GDPR/CCPA deletion request or coordinate with the platform team. There is no single-click "purge this user" admin action.

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