Removing users

Remove access safely when a teammate leaves or changes roles—without breaking records.

Roles: OwnersAdmins
Surfaces: Web app
1 min read Updated February 12, 2026

Context screenshot

At a glance

  • Prefer deactivate over deleting users (keeps history intact).
  • Remove access immediately when someone leaves.
  • Check ownership of critical settings (billing rules, templates, integrations). [Confirm in product]

Overview

Offboarding is a security moment. Fluent should preserve records of who created/edited appointments and invoices while preventing future access.

Before you start

  • Decide whether you are:
    • Removing someone entirely from the workspace, or
    • Changing their role to restrict access
  • Identify any admin-only responsibilities they owned (billing rules, integrations). [Confirm in product]

Option A: Deactivate user (preferred)

Use if you want to preserve history and prevent sign-in.

Option B: Remove from workspace

Use when the user should no longer appear in workspace user lists at all. [Confirm in product]

Option C: Change role (access reduction)

Use when the person stays, but should lose access (e.g., Scheduler → Viewer).

How to remove or deactivate a user

  1. Go to Workspace settings → Team / Users. [Confirm in product]
  2. Find the user.
  3. Select the user’s row/menu.
  4. Choose one:
    • Deactivate (recommended)
    • Remove from workspace
    • Change role
  5. Confirm the action.

What happens to their records?

  • Their historical actions should remain in activity logs and audit records. [Confirm in product]
  • Their name may continue to appear on appointments/invoices as the acting user.

Best practices

  • Deactivate first; delete rarely (and only if required by policy).
  • After removing an Admin, review:
    • Billing + template settings
    • Integrations
    • Notification rules
  • Use audit logs to confirm no unexpected changes occurred before offboarding.

Troubleshooting

I removed a user but still see their name on records

That’s expected for auditability. Records should keep the original actor.

We need to transfer ownership

If your system supports “reassign ownership” for created templates or saved views, do that before removal. [Confirm in product]

  • Roles overview
  • Permission matrix
  • Audit/access logs overview