SuiteCRM Security Groups & Roles: Complete Guide to User Permissions

Controlling who can see, edit, and delete data in your CRM is critical — especially as your team grows. A sales rep shouldn’t see HR records. A support agent doesn’t need access to financial forecasts. A regional manager should see their team’s data but not another region’s pipeline.

SuiteCRM handles this through two complementary systems: Roles (what users can do) and Security Groups (which records users can see). Together, they create a powerful role-based access control (RBAC) framework that protects sensitive data while ensuring every team member has access to the information they need.

This guide walks through both systems with practical setup examples — from simple team structures to complex multi-region hierarchies.

Understanding the Two Systems

Roles: What Can Users Do?

Roles define the actions a user can perform across SuiteCRM modules. For each module, you control whether the user can access it at all, and if so, what they can do — view records, edit them, delete them, import data, export data, or perform mass updates.

Roles operate at the module level. A “Sales Rep” role might have full access to Leads, Contacts, and Opportunities, but no access to Cases, Campaigns, or admin functions.

Security Groups: Which Records Can Users See?

Security Groups define which specific records a user can access within modules they have permission to use. Even if a user’s role grants access to the Accounts module, Security Groups determine whether they see all accounts, only their team’s accounts, or only accounts they personally own.

Security Groups are SuiteCRM’s team-based security layer. They’re essential for organizations with multiple departments, regions, or business units that share a CRM instance but shouldn’t see each other’s data.

How They Work Together

Roles and Security Groups operate in tandem: a role says “you can view and edit Accounts” while the security group says “but only Accounts assigned to the East Sales team.” The combination creates granular, real-world access control.

Setting Up Roles

Creating a Role

Navigate to Admin → Role Management → Create Role. Enter a name (e.g., “Sales Representative”) and optional description. Save the role to open the access matrix.

The Access Matrix

The role configuration displays a grid with modules listed vertically and permission types listed horizontally. For each module, you set access levels across these columns:

Access: Controls whether the module appears in the user’s navigation. Set to “Enabled” or “Disabled.”

Delete: Controls whether the user can delete records. Options include “All” (delete any record), “Owner” (only records assigned to them), “Group” (records in their security group), or “None.”

Edit: Controls record editing with the same options — All, Owner, Group, or None.

Export: Controls whether the user can export data from the module.

Import: Controls whether the user can import data into the module.

List: Controls which records appear in list views — All, Owner, Group, or None.

Mass Update: Controls whether the user can perform bulk updates.

View: Controls which records the user can open and read — All, Owner, Group, or None.

Access Level Options Explained

All: The user can perform the action on every record in the module, regardless of ownership or group membership.

Owner: The user can only perform the action on records where they are set as the “Assigned To” user. This is the most restrictive meaningful setting.

Group: The user can perform the action on records that belong to a security group they’re a member of. This is the team-based access level — essential for multi-team organizations.

None: The user cannot perform this action at all.

Not Set: The default — no specific restriction is applied by this role.

Important: Most-Restrictive Wins

When a user has multiple roles (directly assigned and through group membership), SuiteCRM applies the most restrictive setting. If Role A allows deleting Accounts but Role B prohibits it, the user cannot delete Accounts. Plan your roles carefully to avoid unintended restrictions.

Note: Administrators are exempt from all role restrictions. Their permissions override any role limitations.

Pre-Built Roles

SuiteCRM includes several pre-defined roles as starting points: Customer Support Administrator (full access to Cases, Contacts, Accounts, Knowledge Base), Marketing Administrator (full access to Campaigns, Targets, Target Lists, Leads), Sales Administrator (full access to Opportunities, Quotes, Forecasts, Leads, Contacts), and Tracker (access to tracker reports and the Tracker module).

Customize these or create new roles from scratch based on your organization’s structure.

Setting Up Security Groups

Creating a Security Group

Navigate to Admin → Security Suite Management → Create a Security Group. Enter a name (e.g., “East Sales Team”) and description. The “Not Inheritable” checkbox controls whether this group automatically gets added to related records — leave it unchecked for standard team groups.

Adding Users to Groups

Open the security group and use the Users subpanel to add team members. Each user can belong to multiple groups — for example, a manager might be in both “East Sales” and “West Sales” groups to see data from both teams.

Assigning Roles to Groups

Use the Roles subpanel within the security group to attach a role. Every user in this group inherits the permissions defined by the attached role. This is more efficient than assigning roles to individual users — manage permissions at the group level and user access changes simply by adding/removing them from groups.

Assigning Groups to Records

Records need to be associated with security groups for group-based access to work. There are several ways to do this:

Manual assignment: Use the Security Groups subpanel on individual records or Mass Assign from list views to assign groups to existing records in bulk.

Automatic inheritance: Configure Security Suite Settings (Admin → Security Suite Settings) so that new records automatically inherit the group of the user who creates them, or inherit groups from parent records (e.g., a Contact inherits the group from its related Account).

Via workflows: Create workflow rules that assign security groups based on record criteria — for example, assign leads from specific regions to the appropriate regional group.

Via Logic Hooks: Programmatically assign groups using custom PHP code for complex assignment logic.

Real-World Setup Example: Two Sales Teams

Here’s a complete walkthrough for the most common scenario — an organization with multiple sales teams where team members see only their own team’s data, managers see their team’s data, and the owner/admin sees everything.

The scenario: Two sales teams (East and West). Jill is the owner (sees everything). Will manages East Sales. Sarah manages West Sales. Each team has 5 sales reps.

Step 1: Create Roles

Create a role called “Sales Rep — Owner Only.” Set List, View, Edit, and Delete to “Owner” for Leads, Contacts, Accounts, and Opportunities. This means sales reps see only records assigned to them personally.

Create a role called “Sales Manager — Group Access.” Set List, View to “Group” and Edit, Delete to “Group” for the same modules. This means managers see all records within their security group.

Jill (the owner) stays as Administrator — no role restrictions needed.

Step 2: Create Security Groups

Create “East Sales Team” security group. Attach the “Sales Rep — Owner Only” role. Add Will (manager) and the 5 East sales reps as members.

Create “West Sales Team” security group. Attach the “Sales Rep — Owner Only” role. Add Sarah (manager) and the 5 West sales reps as members.

Step 3: Assign Manager Role Directly

Assign the “Sales Manager — Group Access” role directly to Will and Sarah’s user profiles. Since directly assigned roles take precedence over group roles (when configured in Security Suite Settings), Will and Sarah get group-level visibility while their team members retain owner-only visibility.

Step 4: Assign Groups to Existing Records

Use Mass Assign on the Leads list view to assign East region leads to the “East Sales Team” group and West region leads to the “West Sales Team” group.

Step 5: Configure Inheritance

Go to Admin → Security Suite Settings. Enable automatic group inheritance so new records created by team members automatically get the creator’s group assigned. Configure related record inheritance so that Contacts, Calls, Notes, and other related records inherit the group from the parent Account or Lead.

Result

East sales reps see only their own leads and contacts. Will sees all East team records. West sales reps see only their own records. Sarah sees all West team records. Jill sees everything across both teams.

Security Suite Settings: Advanced Configuration

Admin → Security Suite Settings provides several powerful options:

Additive Rights: When enabled, the user gets the greatest rights of all roles assigned to them or their groups. When disabled, only the group assigned to the current record is considered. Default is additive — most organizations keep this.

Strict Rights: When enabled, only the permissions from the group specifically assigned to a record apply — even if the user belongs to another group with broader permissions. Useful for highly segmented organizations.

User Role Precedence: When enabled, roles assigned directly to a user take precedence over roles inherited from groups. Essential for the manager scenario described above.

Inherit from Created By: New records automatically get the security group of the user who created them.

Inherit from Parent Record: Related records inherit groups from parent records (e.g., a Contact created under an Account inherits the Account’s group).

Popup Group Selection: When a user belongs to multiple groups, a popup appears during record creation asking which group to assign. Useful for users who work across teams.

Filter Inbound Email: Restricts inbound email accounts so users only see mailboxes belonging to their security group.

Default Groups: Set groups that should always be assigned when records are created in specific modules.

Common Patterns and Best Practices

Regional Access Control

Create a security group per region (North America, EMEA, APAC). Assign regional managers with Group-level roles. Assign reps with Owner-only roles. Global leadership gets Administrator access or All-level roles.

Department Isolation

Sales, Marketing, and Support teams each get their own security group. Roles define which modules each department accesses (Sales sees Opportunities but not Cases; Support sees Cases but not Opportunities). Group access ensures each department only sees their own records within shared modules like Accounts and Contacts.

Field-Level Security

For even finer control, SuiteCRM’s Studio allows field-level permissions — making specific fields read-only or invisible for certain roles. For example, the “Annual Revenue” field on Accounts might be visible to managers but hidden from junior reps. This complements module-level roles and record-level security groups.

Compliance-Driven Access

For healthcare (HIPAA), finance (SOX), or GDPR-regulated organizations, Security Groups enforce the “minimum necessary” access principle — users only see the data required for their specific role. Combined with audit logging, this creates a compliance-ready access framework. SuiteAssured adds enterprise-grade security certification.

Troubleshooting Common Issues

Users can’t see any records: Their role likely has “None” or “Owner” set for List/View, and they either own no records or aren’t in any security group. Verify group membership and role settings.

Users see records they shouldn’t: Check if additive rights are combining permissions from multiple groups. Review Security Suite Settings for strict vs. additive mode. Verify that records have the correct group assignment.

New records aren’t inheriting groups: Verify Security Suite Settings — “Inherit from Created By” must be enabled. If the user belongs to multiple groups, ensure popup selection or default group settings are configured.

Role changes not taking effect: Run Admin → Repair → Repair Roles after any role or security group changes. Clear the SuiteCRM cache.

Managers can’t see their team’s records: Ensure the manager has a role with “Group” level access (not “Owner”). Verify the manager is in the correct security group. Check that the role is assigned directly to the manager’s user profile if User Role Precedence is enabled.

When to Get Professional Help

Security configuration directly impacts data protection, compliance, and user productivity. Getting it wrong means either exposing sensitive data or frustrating users who can’t access what they need. Professional SuiteCRM consulting is recommended when your organization has complex hierarchies (multiple regions, departments, and management levels), compliance requirements (HIPAA, GDPR, SOX) demand validated access controls, you’re migrating from another CRM and need to replicate existing permission structures, or you need field-level security combined with module and record-level controls.