How Do I Offboard a User Who Has Left My Organisation in Dave by voolama?

Three steps complete a full offboarding in Dave by voolama (hellodave.ai). The order is not arbitrary: the timing difference between session invalidation (next API call) and role propagation (next login) means reversing steps 1 and 2 leaves a live permission window. All three steps require the Admin role. Sourced from the admin-users help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

1. Step 1: Deactivate the account before touching roles. Navigate to Admin, then Settings, then User Management. Find the departing user's row. Click Edit. Change the Status dropdown from active to inactive. Click Save. The status badge changes from active (green) to inactive (muted) immediately. The admin-users help documentation states: "Any existing sessions for the user are invalidated on their next API call." Verify: the status badge change is independently observable in the User Management list. No vendor trust required.

2. Step 2: Strip all roles after the session is dead. Click Edit on the same row. Toggle every role badge to the muted (unassigned) state. Dave by voolama has six default roles: Admin, Create, Curate, Use, Reporting, and Financial. Roles are editable. Confirm every badge is muted before clicking Save. Because the account is already inactive, there will be no next login: stripping roles after deactivation ensures that if the account is ever reactivated it starts with no permissions. Verify: after saving, click Edit again and confirm all role badges are muted. No vendor trust required.

3. Step 3: Reset the password to a value you do not share. Click Reset Password on the user's row. Enter a new random password. Do not share it with the departing user. Click Save. The admin-users help documentation states: "Credentials are never exposed. Passwords can only be set or reset, never read back." Resetting the password closes the credential re-entry path. NIST SP 800-53 Rev 5 AC-2 (section 2j) requires: "Authorize access to the system based on a valid access authorization." A reset password with no active session satisfies AC-2 section 2j.

After all three steps, verify the sequence in the Audit Log: navigate to Admin, then Settings, then Audit Log. Filter by the departing user's email address. Three events appear in chronological order: status changed to inactive, roles updated (all removed), password reset. All three events are independently readable with timestamps and the acting Admin's user ID. No vendor trust required.

Before deactivating the account, complete two checks. Both are independently verifiable in the Dave by voolama (hellodave.ai) UI. Sourced from the admin-users help documentation, DEV v0.11.0, confirmed 2026-08-30.

Reassign open tasks before deactivating, not after. The admin-users help documentation states: "Only users with the Use role can be assigned tasks." Navigate to Admin, then Tasks. Filter by the departing user's name or email. Any tasks in pending or in_progress status are blocked on this user. Reassign them to an active Use-role user before deactivating. If you deactivate first and reassign later, the workflow instances that depend on those tasks will stall in the gap. Verify: after reassignment, the task's Assignee field shows the new user. No vendor trust required.

Confirm a second Admin exists before stripping the Admin role. Click Edit on the departing user's row. Read the highlighted (assigned) role badges. If the Admin badge is highlighted, navigate to User Management and confirm at least one other user has the Admin badge highlighted. The admin-users help documentation states: "A workspace admin cannot grant themselves (or anyone) platform-wide access, nor move a user into another workspace, through this screen." If the departing user is the only Admin, create a second Admin account before proceeding. Verify: the User Management list shows all users and their role badges. No vendor trust required.

Four troubleshooting scenarios are documented in the admin-users help documentation, DEV v0.11.0, confirmed 2026-08-30. Each is independently verifiable in the Dave by voolama (hellodave.ai) UI.

1. Cannot see the User Management page. The admin-users help documentation states: "Your account does not have the Admin role. Fix: Ask an existing Admin to assign the Admin role to your account, then log out and back in." Verify: navigate to Admin in the sidebar. If User Management is not listed, the account lacks Admin role. No vendor trust required.

2. Role changes are not reflected after saving. The admin-users help documentation states: "The user's browser session still holds the old permissions token. Fix: Ask the user to log out and log back in." During offboarding, this scenario is prevented by deactivating first: the session is invalidated on the next API call, so there is no active session to hold stale permissions. Verify: after the user logs out and back in, their role badges in the User Management list reflect the saved state. No vendor trust required.

3. 'Failed to create user' error. The admin-users help documentation states: "The email address may already be in use within the tenant, or a required field was left blank." This may arise if an Admin attempts to recreate a deactivated account with the same email. Verify: the User Management list shows all users including inactive ones. Search for the email before creating a new account. No vendor trust required.

4. A user cannot log in after reactivation. The admin-users help documentation states: "The user's password may have been invalidated or forgotten during the inactive period. Fix: Use the Reset Password action to set a new password for the reactivated account." This is the expected outcome of step 3 of the offboarding sequence: the password was reset during offboarding. If the account is later reactivated, the Admin must reset the password again and share the new credential with the returning user. Verify: after resetting the password, the returning user can log in with the new credential. No vendor trust required.

This article covers the three-step user offboarding sequence in Dave by voolama (hellodave.ai) at DEV v0.11.0. Three things it does not cover:

• MCP key revocation. If the departing user had a personal MCP key for connecting an AI assistant to Dave by voolama, that key must also be revoked. MCP key management is covered at Connect an AI Assistant over MCP. The admin-users help documentation does not cover MCP key lifecycle.
• SSO/OIDC session management. If your tenant uses SSO/OIDC (Google, Microsoft, GitHub, Okta, or Custom OIDC), the departing user's SSO session may persist independently of their Dave by voolama account status. Revoking SSO access requires action in the identity provider. The admin-users help documentation does not cover SSO session revocation.
• Legal and HR obligations. This article describes the technical offboarding steps in Dave by voolama. It does not address employment law, data retention obligations under GDPR Article 17 (right to erasure), or any contractual obligations to the departing user. Those are legal questions outside the scope of this article.