Users & Roles
Users & Roles controls who can access Owner, which modules they can see, which actions they can perform, and whether they can view personal customer data. The current permissions system supports standard roles, custom roles, and role groups so companies can combine best-practice access templates with company-specific governance.
Go to Configuration → Users in Owner.
User management
| Action | Description |
|---|---|
| Invite user | Send an invitation email to a new team member. The user receives a link to set their password and access Owner. |
| Assign roles | Give the user one or more direct roles. |
| Assign role groups | Add the user to one or more groups so they inherit all roles attached to those groups. |
| Edit access | Change direct roles, role groups, countries, locations, language, or other user settings. |
| Deactivate | Revoke access without deleting the user record. Deactivated users cannot log in. |
| Delete | Permanently remove a user. |
When the new roles system is enabled, the user form requires at least one direct role or one role group. This avoids creating an active Owner user with no access profile.
Roles
Roles define access at permission level. A permission combines a resource and an action, for example list access, detail view, create, update, delete, or a special action such as send, test, export, transfer, upload, download, execute, or password recovery.
Role dashboard
The Roles dashboard is split into two areas:
| Area | Behavior |
|---|---|
| Standard Roles | Loyal Guru predefined roles. Users with permission can view their details and clone them, but standard roles are not edited directly. |
| Custom Roles | Company-specific roles. Users with the right permissions can create, view, edit, clone, delete, and export them. |
The standard role list is maintained by Loyal Guru. If a company needs a variation, clone the closest standard role and save it as a custom role.
Standard roles overview
Standard roles are Loyal Guru predefined templates. They cover the most common operator profiles. Exact permission sets can change when Loyal Guru updates a standard role; always confirm the current checklist in Owner by opening the role (view) or cloning it.
| Standard role | Intended for | Access pattern |
|---|---|---|
| Owner (role) | Ultimate business authority for the company | Full access to all modules |
| User Admin | Platform gatekeeper focused on access and privacy | Configuration for users, roles, and related admin settings; no marketing or Loyalty Insights access |
| Marketing Specialist | Day-to-day campaign operators | Full access to Promotional, Gamified, and Campaign Personalization; partial Configuration for marketing settings |
| Marketing Viewer | Strategic read-only stakeholders | View access to campaign modules; cannot edit |
| Content Creator | Channel and content production | Full access to Channels and Blueprint Campaigns; no promotion logic or Loyalty Insights |
| Tech Integration | Technical architects and integrators | Full access to Configuration (APIs, syncs, webhooks) and Company Data; no marketing or insights modules |
| Analytics | Data and performance specialists | Full access to Loyalty Insights |
| Support Lead | Advanced customer support | Full customer-profile actions; view-only on catalogs; no campaigns |
| Support Agent | Front-line support | View access to customers and catalogs; no campaigns |
For the module-by-module and permission-level comparison of these standard roles, see Standard Roles Matrix.
Custom role configuration
Custom roles are configured from Configuration → Users → Roles → Custom Roles → New Custom Role.
| Field | Required | Description |
|---|---|---|
| Name | ✓ | Functional name for the role, such as "Junior Campaign Analyst" or "Store Support". |
| Description | Internal explanation of what the role is for. Recommended for governance, but not required by the current form. | |
| Permissions | ✓ | One or more permission IDs selected from the grouped permission editor. |
| View personal data | Dedicated toggle that grants Customer@view_sensitive_data, when company-wide masking does not override it. |
Permissions are grouped by module. Each group can be expanded and selected permission by permission, or selected as a whole from the group checkbox.
| Permission type | Meaning |
|---|---|
| Index | View a list of resources in that module. |
| Show | View details for one resource. |
| Create | Create a new resource. |
| Update | Edit an existing resource. |
| Delete | Delete a resource. |
| Special actions | Module-specific actions such as send, test, export, transfer, reprint, upload, download, execute, or password recovery. |
Clone and modify workflow
Cloning is the recommended way to create a custom role:
- Find the standard or custom role closest to the access profile you need.
- Click the clone action.
- The new custom role form opens with the source permissions preselected.
- Rename the role, adjust the permission checkboxes, and save.
This reduces setup time and avoids missing basic permissions that are required for normal navigation.
View personal data and masking
The View personal data toggle is shown separately in the role form because it controls access to sensitive customer fields. In the code, it maps to the Customer@view_sensitive_data permission and is removed from the generic permission group before rendering the grouped checklist.
| Situation | Result |
|---|---|
| Role has View personal data and company-wide masking is off | User can see personal customer fields in plain text when they also have the required customer view permissions. |
| Role does not have View personal data | Personal values are masked, but operational metadata and non-personal fields can still be used where the user has access. |
| Company-wide masking is on | Personal data is masked for all users, regardless of role permission. |
Users without personal-data access can still search for customers using real values, work with non-personal profile fields when allowed, review change metadata, and export masked values. Only grant this permission to roles that genuinely need full personal data for support or operations.
Role groups
Role groups let admins assign roles to many users at once. They are useful when a department, store network, or operations team should share the same access profile.
Go to Configuration → Users → Role Groups.
| Field | Required | Description |
|---|---|---|
| Name | ✓ | Name of the group, such as "Store Managers" or "Support Team". |
| Description | Internal explanation of the group purpose. | |
| Roles | ✓ | Roles attached to the group. Users in the group inherit these permissions. |
| Users | ✓ | Users assigned to the group. |
Role groups support list, show, create, update, and delete operations, depending on the current user's UserGroup permissions.
How access is resolved
Access changes affect what users can see and do immediately after their profile refreshes. Review role and group assignments carefully before saving changes for production users.
Best practices
- Assign the least privileged role that covers the user's day-to-day tasks.
- Reserve the Owner standard role for technical leads and platform owners only.
- Prefer cloning a standard role before creating a custom role from scratch.
- Use role groups for teams with shared responsibilities instead of maintaining identical access user by user.
- Keep View personal data limited to teams that truly need unmasked customer fields.
- Use company-wide masking when the company policy requires personal data to be hidden globally.
- Deactivate users promptly when they leave the team — do not delete, as their activity history is preserved for audit purposes.
- Review active users periodically and remove unused accounts.