Method CRM Security Model Explained: 4 Layers Every Admin Must Know

After over 11 years building Method CRM solutions for 480+ businesses, I've seen a lot of confusion around how the security model actually works. People set up users, something goes wrong — a rep can see records they shouldn't, or an employee can delete invoices that should be protected — and nobody can figure out why.

This post covers all four layers of Method CRM security. Once you understand how the pyramid works, you will be able to set up users with confidence and troubleshoot access issues without guessing.

Layer 1: Platform Level Security — User Roles

The foundation of everything is the user role.

When you invite someone to Method CRM, the first decision you make is what type of user they will be. There are three options:

Regular user — By far the most common type across all the builds I have done. A regular user has no customizing privileges. They simply have access to the apps assigned to them, and within those apps they get whatever CRUD permissions you configure — create, read, update, and delete.

Customizer — The least popular option. A customizer is one level above a regular user and can customize the apps they have access to, publish screens, and work in a dev environment. In practice, most businesses skip this type entirely and go straight between regular user and admin.

Admin — The first person who signs up to a Method CRM account automatically receives admin access. Admins get everything a customizer gets, plus access to platform-level settings pages that nobody else can see. That includes:

• Account settings and subscription management
• User management and adding new users
• Communication settings (Outlook, Gmail, email deliverability)
• Integrations page — where your QuickBooks sync lives, including sync conflicts, the sync log, and engine settings
• API access for connecting third-party platforms
• Import and export tools
• Payment gateway setup such as QuickBooks Payments

These platform-level pages are admin-only. A regular user or customizer will never see them.

Deciding the right role for each person is the first layer of control in your security setup.

Layer 2: App Level Security — Which Apps and What Rights

Once the role is set, you narrow the scope further with app-level permissions.

As an admin, go into a user profile, open the access permissions tab, and click manage permissions. You will see all of Method CRM's packs. Packs are part of Method's billing model, and each pack contains specific apps.

From this screen you can:

• Grant or remove access to entire packs — If a user should never work with bills or purchase orders, uncheck that pack.
• Grant or remove access to individual apps within a pack — Maybe they need purchase orders but not bills. You can control that at the app level.
• Set CRUD rights per app — Within each enabled app you can check or uncheck edit and delete. No edit checkbox means the user can view the app but cannot save changes. No delete checkbox means they can edit but cannot delete records. This is how you create clean read-only or edit-without-delete setups.
• Control the manage permission — Manage gives a user access to administrative screens within an app: setting up permissions for other users, accessing app routines, redirecting screens, and copying screens. Regular users should almost never have manage access.

One nuance worth knowing: if you see permissions greyed out in the manage area for a stock app, it is because Method does not allow modification of those locked areas by design. For custom apps you build yourself, everything opens up.

If you are building custom apps and want to understand the underlying structure, how to build a custom app in Method CRM walks through the full screen and table setup from the beginning.

Layer 3: Screen Level Security — Wiring Permissions Into Custom App Screens

This layer applies specifically to custom apps.

Stock Method CRM apps handle this automatically. If a user doesn't have edit permission on the Estimates app, the buttons and fields on estimate screens already reflect that — Method builds it in for you. For custom apps you build yourself, you have to wire this behavior in manually.

Here is how it works.

When the user loads a custom app screen, you use the Check Permission action inside the Method CRM Action Editor. This fires on page load through the page actions. The Check Permission action checks whether the signed-in user has a specific right — edit, delete, or manage — for the current app. You store the result as an action result variable.

Then you add a conditional: if that variable returns false, disable the relevant sections on screen. If it returns true, enable them.

That means for every right you expose in your custom app, you need to:

1. Define that right in the app's rights configuration under manage app
2. Check that right in the Action Editor on page load
3. Conditionally enable or disable the appropriate screen sections based on the result

The Method CRM Action Editor is where most of the logic for this lives. Without this wiring, the permissions you set at the app level have no visible effect on your custom screens. A user whose edit permission is unchecked can still walk up to a screen and hit save.

Stock apps protect themselves. Custom apps only protect themselves if you build it in.

Layer 4: Record Level Security — Which Records Each User Can See

The fourth layer is the most targeted. It does not control whether a user can access an app — it controls which specific records inside that app they can see.

This is configured in the same access permissions area of the user profile, right below the app-level permissions. It is called record access.

Two settings control visibility:

Peer-to-peer access — By default a user sees records assigned to themselves. When you add specific colleagues to this list, they also see records assigned to those people. If you want a rep to only see their own customers and jobs, remove everyone else from the peer list.

Allow access to empty records — Records with no assigned-to user are invisible to restricted users unless you check this option. Leaving it unchecked means unassigned records simply do not show up.

Here is the most critical thing to understand about record-level security: this will not work if even one user still has full visibility enabled. That includes admin accounts. If you want record-level security to apply across the board, you have to configure every single user — admins included — with the correct record access settings.

I see this trip up businesses regularly. They restrict access for regular users, forget to configure the admin accounts, and the entire record-level system does not function as expected. All users must have this set up, or the feature effectively does not work.

For field service businesses, sales teams organized by territory, or any company where reps should only see their own accounts and jobs, this is the layer that makes it actually happen.

How the Four Layers Work Together

The pyramid model matters because each layer builds on the one below it.

If a user doesn't have edit permission at the app level, screen-level security reinforces that by disabling the screen. If a user can only see their own records at the record level, that restriction applies everywhere across all apps — not just one. Each layer narrows the scope further.

No single layer is sufficient on its own. App-level permissions without screen-level wiring in custom apps leaves gaps. Record-level restrictions without proper peer configuration can create unexpected visibility. And none of it lands correctly if you haven't thought through the user role at the platform level first.

When I set up users for a new Method CRM build, I work through all four layers deliberately:

1. What role type should this user have — regular, customizer, or admin?
2. Which apps should they access, and what CRUD rights do they need?
3. For any custom apps, are the Check Permission actions wired into page load?
4. Should this user see all records, only their own, or a specific group?

If you are doing Method CRM customization and building custom apps, the screen-level security layer is the one most commonly missed. It is also the one that causes the most operational headaches down the line when a user edits something they should never have been able to touch.

Book a free strategy call and let's get your Method CRM working for you.