Deactivation Workflow

Configure the approval process for deactivating members — controlling who can request it and who must approve it.

Deactivation is the process of removing a member's active status from your organization. Unlike deleting a member (which fellos does not support), deactivation preserves all historical data while revoking the member's ability to log in and participate. This ensures your organization maintains complete records while properly handling departures, suspensions, or other separations.

The Deactivations admin page lets you configure the approval chain for the deactivation process — who can start it and who must sign off before it takes effect.

Configuring the Workflow

The deactivation workflow has two groups of settings:

Requestors

Select which administrator levels can initiate a deactivation request. You'll see checkboxes for each level:

• Club Admin — Site-level administrators. Checking this allows club admins to request deactivation for any member in the entire organization.
• Org Admin — Mid-level administrators (regional, district). Checking this allows org admins to request deactivation for members within their organizational unit.
• Local Admin — Chapter-level administrators. Checking this allows local admins to request deactivation for members in their chapter.

You can check one, two, or all three levels. Most organizations allow all three levels to request deactivations, since the approval step provides the necessary oversight.

Approvers

Select which administrator levels must approve a deactivation before it takes effect. The same three checkboxes are available. When a deactivation request is submitted, it appears in the pending requests queue for administrators at the checked levels.

What Happens When a Member Is Deactivated

When a deactivation is approved and processed, the following changes take effect immediately:

1. The member's type is changed to the deactivation type. This is a special member type you designate in the Member Types settings by checking the "Deactivation type" flag on one of your member types.
2. The member's login access is revoked. They can no longer sign in to the fellos platform.
3. The member is removed from active listings. They no longer appear in the member directory or organization rosters for other members.
4. All historical data is preserved. Their profile, posts, event attendance, attachments, and workflow history remain in the system for record-keeping purposes.
5. The deactivation is logged in the audit log with full details: who requested it, who approved it, and when it was processed.

The Deactivation Member Type

Before the deactivation workflow can function, you need to designate one of your member types as the deactivation type. This is done in the Member Types settings by enabling the "Deactivation type" flag on a member type.

Common names for the deactivation type include "Inactive," "Former Member," or "Deactivated." This type typically has minimal permissions — no access to groups, events, or member directory. Since deactivated members can't log in anyway, the permissions are mainly relevant if the member is later reinstated and the type is used as a starting point for a new transition.

Reinstatement

Deactivated members can potentially return to active status. There are two paths for reinstatement:

• New onboarding — If your onboarding workflow allows applications from deactivated members, they can go through the standard onboarding process again, starting fresh with a new request.
• Transition rule — If you create a transition rule with the deactivation type as the "from" type and an active type as the "to" type, administrators can use the transition workflow to reinstate the member. This approach lets you require specific documentation (like a reinstatement application) and approval from the appropriate level.

Either way, reinstating a member restores their login access and changes their type to an active one. Their historical data — including the deactivation record — remains intact.

Best Practices

• Document your reasons — Even though the deactivation form doesn't require a message by default, encourage administrators to note the reason for deactivation in the request. This creates a clear record in the audit log.
• Set appropriate approval levels — Deactivation is a significant action. Consider requiring approval from at least one level above the requestor to prevent hasty or unauthorized deactivations.
• Communicate with the member — fellos handles the technical side of deactivation, but reaching out to the member directly about their status change is a good organizational practice.
• Review periodically — Check your deactivated members list periodically. Some may be candidates for reinstatement, especially if they left due to temporary circumstances.