Managing client access

This page is for staff managing client-facing access. See For clients for what the client themselves sees.

Client companies

/clients/ needs the clients.manage permission. A Client groups engagements under one customer organization.

The list page supports a free text search over the company name (case-insensitive substring match) and paginates at ten companies per page.

Creating one asks for a single field: name, which must be unique across every client company on the instance. Editing adds a second field, active.

Note

An engagement must be linked to an existing client company at creation. You cannot create one against a free-typed client name and attach it to a proper Client later. Create the client company first.

What deactivating a client company actually does

Turning active off does not touch any individual client user account, and it does not touch the company’s engagements either. What it does is remove every one of that company’s engagements from the portal’s visibility query in one step, since the portal only ever lists engagements whose client is both linked and currently active. Every client user tied to that company effectively loses access to everything at once, without you having to deactivate each of their accounts individually. Reactivating the company restores that visibility immediately, with no other side effects.

A company’s detail page lists its engagements and every client portal account tied to it, so you can see both sides before deciding whether to deactivate it.

Client accounts

From a client company’s detail page:

• New client user creates a login scoped to that one company. The form asks for username, email, first name, last name, and which client company the account belongs to (defaulted to the company you started from, but changeable). The account is created with an unusable password and the built in client role, and the same single-use twenty four hour emailed setup link used for staff accounts is sent immediately, the same mechanism described in User management.
• Deactivate does two things at once: it flags the account inactive, and it immediately invalidates every one of that account’s active sessions, signing them out everywhere right away rather than waiting for their session to expire naturally. Reactivate only flips the flag back. It does not need to touch sessions, since a deactivated account could not have created a new one in the meantime.
• Send password reset sends the same emailed reset link a self-service “Forgot password” would, on the admin’s behalf. This only works for local accounts. An account provisioned through an OAuth provider has no RedScribe-managed password to reset.
• Clear MFA deletes the account’s confirmed TOTP device, if it has one, forcing re-enrollment at next login. If the account has no device enrolled yet, you’ll see a message saying there was nothing to clear rather than a silent no-op. Like the password reset action, this only applies to local accounts. See the equivalent staff-side action in User management for the same idea applied to a lost password or lost device on a staff account.

Turning portal access on or off instance-wide

client_portal_enabled (Feature Flags, Superadmin only) is a single instance-wide switch. When it is off, client-role accounts cannot log in at all, regardless of individual account status, company status, or anything else. Managing client companies and accounts stays available to Superadmin and Team Lead either way, so you can fully prepare a client’s access before ever flipping this on. See Feature flags.