Users & roles

Every person who logs into OpsMerge has a user record and one or more roles. Roles bundle permissions; permissions control what specific actions a user can take.

The default roles

When your tenant is provisioned, OpsMerge creates four default roles:

Role	Typical use	What they can do
Owner	The MSP director / founder	Everything, including billing and tenant deletion. Cannot be demoted by another user; only by themselves.
Admin	Senior techs, team leads	Everything except billing changes and adding/removing other admins.
Technician	Day-to-day MSP staff	Tickets, agents, scripts, policies, contracts. Read-only on billing and settings.
Read-only	Auditors, observers, junior staff in onboarding	Read access to most things, no write.

These defaults are deliberately conservative — the assumption is you'll customise them rather than rely on them as-is.

Inviting a user

1. Settings → Users → + Invite user.
2. Enter email, choose initial role(s), optional team assignment.
3. Click Send invitation.

The user gets an email with a magic-link signup. They set their own password (or use SSO if you've configured it). The invitation expires after 7 days; resend from the Users list if needed.

Invite, don't create

OpsMerge doesn't let you set a user's password for them. This is deliberate — passwords should be known only to the user, and invitation flows have a paper trail in the audit log.

Managing roles

Settings → Users → Roles tab.

You can:

• Create a new role. Useful for "billing-only" (e.g. your accountant), "L1 helpdesk" (tickets only), or anything else.
• Edit an existing role's permissions. Tick/untick the granular permissions you want.
• Delete a role that's no longer used (only if no user is currently assigned).

Permissions are grouped by area: Tickets, Agents, RMM, Billing, Settings, Reports, etc.

How permissions work

A user's effective permissions are the union of all permissions across all roles assigned to them. There's no "deny" or precedence ordering — if any role grants a permission, the user has it.

This is intentionally simple. We don't have allow/deny rules, "permission inheritance", or wildcard exceptions. If you find yourself wanting that, the answer is usually "create another role and assign it alongside the existing one".

Common patterns

• "Most people are Technicians, but Sam also needs to manage billing" — give Sam both Technician and a custom Billing role.
• "Lou is here for two weeks while we evaluate them" — give Lou the Read-only role for the first week, switch to Technician once they're up to speed.
• "This client's portal user shouldn't see other clients" — that's a portal user, not an MSP user. See Clients & contacts for portal-side access.

SSO and two-factor

Settings → SSO configures SAML/OIDC SSO if you've got an identity provider. We support Google Workspace, Microsoft Entra, Okta, and any SAML 2.0 IdP.

When SSO is configured, you can also choose whether to allow password login as a fallback or force SSO-only.

Two-factor authentication can be required at the tenant level (Settings → Security) or recommended-but-optional. We support TOTP (Authenticator apps) and WebAuthn (hardware keys, passkeys). SMS is not supported — it's a worse-than-nothing factor.

Service accounts and machine tokens

For automated integrations (e.g. a third-party tool calling OpsMerge's API), don't create a user — create an API key from a real user's profile, or a dedicated service account user with the minimal role needed. See API access.

Removing a user

Settings → Users → user → Remove.

The user's record stays in the database — they just can't log in any more. Their historical actions in the audit log remain attributed to their name. If they had open tickets assigned to them, those tickets are reassigned to "Unassigned" — you'll want to redistribute them.

If a user is leaving and you'll never re-instate them, you can also revoke all sessions to log them out immediately.

Common issues

Invitation email never arrives. Check spam. The invite comes from [email protected] via our Haraka MTA. If the user's email host has aggressive filtering, you may need to allow-list the sender.

User says "I don't have permission to do X" but they're a Technician. Check whether X has been moved into the Admin role recently. The default role definitions change occasionally (we add new permissions when we add new features). Use Settings → Users → Permission audit to see which roles currently grant which permissions.

Recently-added permission constant works for new tenants but not existing. When a new permission is added, existing roles in existing tenants don't automatically gain it — there's a backfill migration for each release. If a permission seems to silently 403 only for older tenants, this is likely the cause. Contact support.

Next

• Clients & contacts
• API access
• Audit log