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.

User profiles

Each user record carries a profile: full name, job title, phone and mobile. The full name is what clients see on ticket replies and what the app shows in menus, activity feeds and mentions, so fill it in.

Two places to edit it:

• Settings → Users → edit: admins can fill in any user's details.
• My profile (user menu, top right): every user can edit their own details, plus their personal ticket reply signature.

The reply signature is optional rich text, included in emailed ticket replies wherever the notification template places the {{.comment_author_signature}} variable. See Notifications for how it interacts with templates. Signatures are personal: admins manage the profile fields, but each user owns their own signature.

Connected devices

My profile also lists your connected devices: desktop-app sign-ins linked to your account. Signing in from the OpsMerge desktop app registers the device once; from then on the app stays signed in on that machine (unlocked with a PIN rather than a full login) until the device is revoked or goes unused for 60 days.

Each entry shows the device name, platform, app version, when it was added and when it was last seen. Revoke signs that device out immediately, everywhere: its stored credential stops working and any live sessions it opened are terminated. Revoke anything you don't recognise, and any machine you've stopped using.

Two things also revoke every connected device automatically: changing the account password (including an admin-initiated reset) and deactivating the user.

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]. 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