Users, Roles & Permissions

Equipt/PO and Landscapt/CRM access are controlled by two independent mechanisms, not one unified role model:

• The organization role — a single value on every user's profile (profiles.role): admin, manager, purchaser, technician, viewer, requestor, or crew. This is the role you pick when inviting someone from Settings → Users, and it's what gates Equipt (CMMS) and PO access.
• CRM custom roles — a completely separate, org-defined permission system for Landscapt, managed at CRM Settings → Roles. Each role is a named set of on/off switches (over a hundred of them — client access, scheduling, accounting, reports, and more) stored as JSONB, closer to Service Autopilot's permission model than to the seven fixed organization roles.

These are the only values profiles.role can hold. Every staff login has exactly one.

A snapshot of what each organization role can do, drawn from the role descriptions shown in Settings → Users → Roles.

"None by default" for CRM access means the organization role alone doesn't grant it — an admin has to separately link the user to a CRM role via CRM Settings → Employees. Client portal accounts are a different login entirely — see the Client Portal guide.

CRM access is governed by crm_roles — organization-defined roles you build yourself at CRM Settings → Roles, not the seven fixed organization roles above. Each role is a flat set of permission keys (client_add, acct_add_modify_invoices, sched_dispatch_board, and well over a hundred others across Home, CRM, Scheduling, Accounting, and Mobile) that you toggle on or off per role.

To give someone CRM access, two things have to both be true:

1. They have a crm_employees record linked to their login.
2. That employee record points at an active (non-deleted) crm_roles row — the specific CRM role that defines what they can see and do inside Landscapt.

Without both, a user with a perfectly valid organization role (say, Manager) is blocked from the CRM module entirely — the CRM access gate checks for a crm_role_id, not for anything on profiles.role. The Landscapt tile on their Home screen reflects this too: it only appears once both conditions above are met, so an unlinked user simply doesn't see a tile that would otherwise dead-end in a "not linked" screen.

Report permissions live on the role editor's Reports tab and work in two layers, both enforced server-side:

• View Report Center (Home > Report Access) is the front door. It is required to open the Report Center, and — as of the latest reporting changes — to run or save a custom analysis, open a saved report, view a Custom Dashboard, or use the Graphics Library. Manage Report Center additionally allows building those and editing the KPI Scorecard.
• Individual report keys under CRM Reports, Scheduling Reports, and Accounting Reports each unlock one pre-built report by name (Client Balance, Job Cost Summary, A/R Aging Report, …). The same keys also gate the raw datasets behind custom analyses and dashboard panels, so a role that can't see a payroll or accounting report can't rebuild it ad hoc either: Employees needs Employee Directory; Timesheets needs Job Hours Summary or Employee Directory; Invoices and Invoice Line Items need Invoiced Income by Client, Invoices with Balances, or A/R Aging Report; Payments needs Payment Audit Summary or one of those three; Estimates and Estimate Line Items need View Estimates, Estimates by Stage, or Won Estimates by Service. A dashboard panel the user can't query shows "You don't have permission to view this panel" rather than failing the whole dashboard.

1. Go to Settings → Users. Only Admins see the Invite User and Create Crew Account buttons.
2. Click Invite User, enter their name, email, and pick one of the organization roles.
3. They receive an email invitation and set their own password on first login. If the email is already registered elsewhere in the system, a password-reset link is sent instead so they land on the same set-password screen.
4. An Admin can resend a pending invite, change a user's role, or deactivate them at any time from the same table. Deactivating revokes their login outright — it's not just a status label, it bans their account the same moment, so they're signed out within the hour even if already logged in. A deactivated user shows an Inactive badge and a reactivate icon in place of the trash icon; clicking it restores their login immediately, with their role and any CRM employee link untouched.

A separate Create Crew Account flow (also Admin-only, same page) creates a shared login for a field crew team rather than an individual — you set a team name and a password directly, and the credentials are shown once, at creation time. If that password is lost or needs changing later, an Admin can set a new one for the account directly from the Users table — crew accounts use auto-generated addresses and can't receive a normal password-reset email.

An Admin invites maria@greenlawn.com as a Technician. What happens immediately, and what doesn't:

• Maria gets an invite email and sets her own password.
• On first login she has full Equipt access: she can create and manage work orders (not just ones assigned to her), log labor and meter readings, submit maintenance requests, and create purchase requisitions and POs for maintenance parts.
• She cannot approve any requisition or PO — Technician isn't an eligible approver role.
• She cannot open Settings, invite other users, or change anyone's role.
• She cannot open Landscapt/CRM at all yet — inviting her as Technician only set her organization role. If she also needs CRM access (say, to see client jobs tied to a work order), an admin has to separately create a crm_employees record for her at CRM Settings → Employees and assign one of the org's CRM roles. Until that happens, she's blocked from every CRM route.

Two more access modes exist outside the organization-role / CRM-role pair above:

• Crew accounts — a shared login (organization role crew) for a field team rather than a person. A crew login is confined to the crew field surface only: viewing and completing assigned jobs, submitting maintenance requests, viewing the Labor Efficiency and Driver Safety Scores dashboards, and uploading photos to job sites. It has no access to purchasing, assets, inventory, settings, or the rest of the CRM module — even attempting to load a CRM route outside the crew surface is blocked, regardless of what a crm_role_id might otherwise allow.

  What a crew login can change is deliberately narrow: it may update only the visits belonging to its own crew, and cannot move a visit to a different crew. Jobs and job service lines are read-only to a crew account, so a crew can never alter a service's price — pricing is only editable by staff roles with the relevant permission. Invoices and payments are not readable by a crew login at all.

• Hiding prices from crews. Settings → Landscapt → Hide pricing from crew accounts stops service prices from being sent to crew devices at all — not merely hidden on screen. With it on, no rate is included in the data the crew app requests, so prices can't be recovered from a shared tablet. Leave it off if you want crews to see what a job is worth.
• Client portal accounts — an entirely different login system for Landscapt's customers (not staff), separate from everything on this page. A client portal login can only ever see that client's own account — billing, services, estimates, tickets, and documents — never any staff surface. See the Client Portal guide for how portal access is granted and what a client can do with it.

• Role dropdown looks editable, isn't always effective. Non-admins see the role selector as disabled in the UI, but the real enforcement is server-side (RLS plus a database trigger) — the disabled control is just there to avoid misleading anyone.
• Changing someone's organization role never touches their CRM role. Moving a user from Technician to Manager doesn't grant or revoke any CRM permissions — those two systems are independent, so check both when adjusting access.
• Photo Module access is a separate per-user toggle, not tied to organization role — except Admins, who always have it on, and Requestors, for whom it doesn't apply.
• A deleted (soft-deleted) CRM role silently revokes access. If a crm_roles row an employee is assigned to gets deleted, that employee loses CRM access the same as if no role were assigned at all — nothing on the user record itself changes to indicate why.
• The employee record has a third, unrelated "User Role" field — it grants nothing. CRM Settings → Employees → an employee's User Settings tab shows a User Role field with options like Admin, Manager, Technician, Purchaser, and Viewer — the same familiar names as the organization role. It is purely a display label on crm_employees.user_role and has no effect on access anywhere in the app. Once the employee is linked to a login, it's auto-populated from that login's real organization role and shown read-only, so it can't drift out of sync — before a login is linked, it's just a manually-set label. Don't confuse it with either the organization role or the Landscapt Role (crm_role_id) on the same tab.