Managing User Roles and Permissions

What I typically recommend is taking a moment to think through your organizational structure before you start clicking around in the admin panel. In my experience, companies that map out their roles first — really thinking about who needs to see what, and who shouldn't see what — end up with much cleaner permission schemes that don't require rework six months down the line.

FieldPulse uses a role-based access control (RBAC) model. This means permissions are grouped into roles, and users are assigned one or more roles. It's worth understanding this distinction because it affects how you'll structure your team, especially if you have people wearing multiple hats.

Default Roles Overview

Out of the box, FieldPulse provides several pre-configured roles. In my experience, most organizations can get started with these and customize as needed:

• Administrator — Full access to all features, settings, and account management. Can create and modify roles.
• Dispatcher — Can create, assign, and schedule work orders. Can view technician locations and manage the dispatch board. Cannot access billing or account settings.
• Technician — Can view assigned work orders, update status, complete checklists, and capture photos/signatures. Cannot see other technicians' schedules or unassigned jobs.
• Office Manager — Can manage customers, run reports, and handle billing. Cannot modify user roles or security settings.
• Read-Only — Can view work orders, customer records, and reports. Cannot create or modify anything.

What I typically recommend here is not to overthink it on day one. Start with the default roles and see where the friction points emerge. You'll quickly discover that your "Dispatcher" also needs to run reports, or that your "Office Manager" needs to help with scheduling. Those discoveries are valuable data for customizing your roles.

Creating a Custom Role

Sometimes the default roles don't quite match your workflow. Here's how to create something custom:

1. Navigate to Settings > User Management > Roles
2. Click Add New Role
3. Enter a descriptive name (e.g., "Senior Technician — Can Assign Jobs")
4. Select the appropriate permissions from the matrix below
5. Save the role

The permission matrix is organized by functional area: Work Orders, Customers, Scheduling, Inventory, Reports, and Administration. Each area has granular options — View, Create, Edit, Delete, Export. In my experience, the most common mistake is granting Edit without realizing it also enables certain actions you might not have intended.

Permission Inheritance and Conflicts

Here's something that trips people up: users can have multiple roles. When a user has multiple roles, they receive the union of all permissions — the most permissive setting wins. You cannot use one role to restrict permissions granted by another.

What I typically recommend is giving users a single primary role that covers 90% of their needs, then adding a secondary role only for specific edge cases. If you find yourself stacking three or four roles on one person, that's usually a sign that your role definitions need to be rethought.

Data Visibility Rules

Beyond feature permissions, roles control data visibility:

• Own Records Only — Technicians can see work orders assigned to them
• Team Records — Supervisors can see work orders for their direct reports
• All Records — Dispatchers and managers can see all work orders in the system
• Service Area Restricted — Users can only see customers and jobs within assigned geographic zones

The Service Area restriction is particularly useful for multi-region operations. In my experience, companies don't enable this early enough — they wait until there's a confidentiality incident. I'd recommend setting geographic boundaries as soon as you have clearly defined territories, even if there's only one person per territory right now.

Best Practices from Implementation

Over the course of many implementations, I've developed some patterns that seem to work well:

• Document your roles. Keep a simple spreadsheet listing what each role can do and why. When someone asks "why can't I see X?" you'll have an answer.
• Review quarterly. People change jobs, and roles accumulate cruft. A quick audit every few months prevents permission drift.
• Test with a dummy user. Create a test account for each role and actually try to use the system. You'll catch visibility issues before your technicians do.
• Be cautious with Delete permissions. Most operational roles don't need to permanently delete records — archive or status changes are usually sufficient.

Troubleshooting Common Issues

User can't see a work order they should have access to: Check their assigned service area and the job's location. Also verify that the work order status hasn't been set to a restricted visibility state.

Changes to role not taking effect: Users need to log out and back in for role changes to apply. There's also a brief propagation delay of up to five minutes in some cases.

Can't find the option to edit roles: Only Administrators can modify roles. If you're an Administrator and still don't see it, verify that your subscription tier includes advanced role management.

See Also

• Enabling Two-Factor Authentication
• Inviting Team Members and Setting Roles
• Audit Logs: Viewing Account Activity
• Single Sign-On (SSO) Configuration

If you're planning a larger rollout and want to discuss role architecture specific to your industry or organizational structure, that's something my team often helps with during implementation. Feel free to reach out through your account manager.