Understanding Permissions & Groups

Control who can see and edit what in your department

Command Established uses a flexible permissions system based on roles, individual permissions, and groups. This guide explains how to control access to sensitive information and ensure the right people can see and edit the records they need.

Quick Start

Three ways to control access:

1. Roles — Assign users as Owner, Admin, or Member when they join your department.
2. Permissions — Grant specific permissions to individual members (e.g., "can edit incidents").
3. Groups — Create groups with shared permissions and add members (e.g., "Officers" group).

Understanding Roles: Owner, Admin, Member

Every member of your department has one of three roles. Roles determine baseline access levels before individual permissions or groups are considered.

Owner

Full access to everything. Owners can see, create, edit, and delete all records. They can manage department settings, billing, and other members' permissions. There must always be at least one owner.

Best for: Fire Chief, Department Administrator

Admin

Full access to all operational data. Admins can see, create, edit, and delete all incidents, personnel, apparatus, and other records. They cannot manage department settings or billing.

Best for: Assistant Chief, Training Officer, senior officers who need full operational access

Member

Access controlled by permissions and groups. Members have no access by default. They must be granted specific permissions (individually or through groups) to view or edit records.

Best for: Most department members, firefighters, EMTs, support staff

How Permissions Work

Permissions are specific actions a member can perform on different types of records. Every permission follows the format action:entity.

Available Actions

• read — View records (see list, view details)
• create — Create new records
• update — Edit existing records
• archive — Archive (soft delete) records

Record Types (Entities)

• incident
• personnel
• apparatus
• station
• training
• inventory
• fire-hydrant

Permission Examples

• read:incident — Can view the incident list and see basic details (address, nature of call, timeline, assigned personnel). Cannot see sensitive fields like narrative details.
• create:incident — Can create new incident reports. Bonus: Can also edit incidents they created (but cannot archive them).
• update:incident — Can edit any incident report (unless it's locked or assigned to someone else).
• archive:apparatus — Can archive (soft delete) apparatus records. Archived records are hidden from lists but preserved for audit history.

Special Permission Rules

Some permissions have special behavior to support common workflows:

Rule 1: "Create" Grants Edit on Your Own Records

If you have create:incident, you can also edit incidents you created (but you cannot archive them without explicit archive:incident permission).

Example: A firefighter with create:incident can write an incident report and make corrections to their own report, but they can't edit reports written by others.

Rule 2: Assignment Grants Edit Access

If you're assigned to an incident (in the "Assigned To" field), you can edit that incident even without update:incident permission.

Example: An officer assigns an incident report to a firefighter for completion. That firefighter can now edit the assigned incident, even if they only have read:incident.

Rule 3: Locked Incidents Are Owner/Admin Only

Once an incident is approved and submitted to NERIS, it becomes locked. Only Owners and Admins can edit locked incidents.

Why? Once submitted to NERIS, the federal system has a copy. Edits should be carefully controlled to maintain data integrity and audit trail.

Rule 4: You Can Always Edit Your Own Personnel Record

Every member can view and edit their own personnel record (certifications, contact info, etc.) regardless of permissions. Admins and Owners can edit all personnel records.

Using Groups to Simplify Permissions

Instead of assigning permissions to members one-by-one, create Groups with shared permissions and add members to the group. When you update the group's permissions, all members inherit the change.

How Groups Work

1. Create a group (e.g., "Officers") and assign it permissions
2. Add members to the group
3. Members inherit all permissions from the group (stacked on top of individual permissions)

Example Group Setups

Best Practices for Managing Access

1. Start restrictive, expand as needed — Begin with minimal permissions and add more based on role requirements. It's easier to grant access than to revoke it.
2. Use groups for common roles — Create groups for Officers, Training Staff, Incident Reporters, etc. This makes permission management scalable as your department grows.
3. Limit archive permissions — Archiving records is permanent (soft delete). Only grant archive:* permissions to trusted members.
4. Review permissions regularly — When members change roles or leave the department, review and update their permissions. Use deactivation for members who leave temporarily.
5. Use assignment for workflow — For incidents that need review or completion, assign them to specific members. Assigned members can edit without broad update:incident permission.
6. Document your permission structure — Keep a record of which groups have which permissions and why. This helps when onboarding new members or troubleshooting access issues.

Common Questions

Need Help?

If you're having trouble setting up permissions or need help designing a permission structure for your department, reach out to our support team. We're happy to help you configure access controls that work for your organization.

Contact Support