Incidents

Manage Incidents as a Church Administrator

Configure incident access, establish reporting standards, review sensitive reports, and manage the incident lifecycle across your church.

Incidents gives church security leaders one place to review, manage, and retain reports submitted by the security team. Administrators are responsible for deciding who can see reports, setting consistent reporting standards, and making sure each incident is followed through the appropriate review process.

If an incident involves an active threat, a medical emergency, or immediate danger, contact 911 or your local emergency services and follow your church emergency procedures first. Create the report only when it is safe to do so.

Open and review the Incidents workspace

Select Incidents in the main navigation. The overview is the administrative queue for reports from every campus the signed-in administrator is authorized to view.

Incidents overview with search, priority and status filters, an archived toggle, date filters, and the New Incident button.
Incidents overview with search, priority and status filters, an archived toggle, date filters, and the New Incident button.

Use the search field to find words in an incident title or description. If your church has more than one campus, use the campus selector to narrow the list. You can also filter by priority, status, date range, or select Show Archived to include archived records. Select Clear to remove all active filters.

Incident cards summarize the report type, priority, status, severity, creation time, and operational flags such as Sensitive, Archived, Injury, Trespassed, or Authorities Contacted. Open a card to review the full record.

Configure incident permissions

Open Church Admin, then Role Permissions, and review the Incidents permission group before inviting the wider team. A church can override the default access for a role, so verify the effective permissions for your own organization rather than relying only on a role title.

  • Create Incidents — allows a person to submit a new incident report.
  • Edit Incidents — allows changes to report details, status, people, tags, and photos.
  • Delete Incidents — allows permanent deletion of an incident and its associated records.
  • Archive Incidents — allows an incident to be archived or restored.
  • View All Incidents — allows access to the Incidents list and incident detail pages.
  • View Sensitive Incidents — allows access to reports marked Sensitive.

By default, Administrators and Directors of Safety & Security have all six incident permissions. Campus Security Leads can create, edit, view all, and view sensitive incidents. Security Shift Team Leads can create, edit, and view all incidents. Security Team Members can create and view all incidents, while Support Staff can view all incidents. Any role overrides configured by your church can change these defaults.

Reserve Delete Incidents, Archive Incidents, and View Sensitive Incidents for the smallest group that needs them. In the current incident form, only Administrators and Directors of Safety & Security can mark or unmark a report as Sensitive.

Set reporting standards for your church

Before rollout, tell the team how your church uses categories, priorities, statuses, tags, and campus locations. Consistent choices make filtering and trend review much more useful.

Categories

The incident form includes Custody Issue, Disruption, Injury, Medical, Parking Lot, Property Damage, Security, Service Disruption, Theft, Threat, Vandalism, Weather, and Other. Define when your team should use each category and when Other is appropriate.

Priorities

The available priorities are Critical, High, Medium, and Low. The platform does not replace your escalation policy, so document what each level means for your church. For example, your policy might reserve Critical for an immediate life-safety event and High for an urgent incident that needs leadership attention. Train team members to follow the policy, not guess from the label.

Statuses

The status choices are New, Acknowledged, In Progress, Resolved, and Closed. A practical workflow is to acknowledge a new report after a leader reviews it, move it to In Progress while follow-up is underway, use Resolved when the operational response is complete, and close it after documentation and leadership review are complete.

Locations and tags

Keep campus names and campus areas current so reports can be assigned to the correct location. Agree on a small, reusable set of tags for recurring needs such as parking, children’s ministry, first aid, or law-enforcement follow-up. Avoid creating several tags that mean the same thing.

Review a new incident

  1. Open the report from the Incidents overview and confirm the campus, date, time, location, category, and priority.
  2. Read the description for an objective sequence of events. Confirm that observations are separated from statements made by witnesses or involved people.
  3. Review the involved people, reporter details, photos, tags, and the Injury Sustained, Trespassed, and Authorities Contacted flags.
  4. Use the timeline to understand when the incident was created and what changes have been made.
  5. Add a note for follow-up information that should supplement the original report. Edit the original details only when a correction is needed and your role has Edit Incidents permission.
  6. Update the status as the response progresses. If a control is unavailable or a change is rejected, verify the signed-in user’s role permissions.
Incident detail page showing report actions, status, description, photos, timeline, details, and notes.
Incident detail page showing report actions, status, description, photos, timeline, details, and notes.

The detail page brings the original report, involved people, photos, timeline, location, reporter details, and notes together. Users with the appropriate permissions can edit the report, change its status, archive or restore it, or delete it. Viewers can generate a PDF record.

Handle sensitive incidents carefully

Use Sensitive only when a report requires restricted visibility. A sensitive incident is hidden from anyone who does not have View Sensitive Incidents, even if that person can view other incidents. Creating a sensitive incident also skips the organization-wide new-incident notification and push-notification process.

Because fewer people will see a sensitive report and automated incident notifications are not sent, follow your church’s separate escalation process to alert the specific leaders who need to respond. Record only information that is necessary for the safety and operational purpose of the report.

Export, archive, restore, or delete a report

Generate a PDF

Select PDF on the incident detail page to generate a portable record. The PDF includes the church and incident details, involved people, attached photos, and the incident timeline. Store or share the PDF according to your church’s privacy, legal, insurance, and records-retention requirements.

Archive and restore

Archive a report when it should no longer appear in the default active list but must remain available. Archived incidents are reversible: select Show Archived on the overview, open the report, and use Restore if it needs to return to the active list. Archive and Restore require Archive Incidents permission.

Delete permanently

Delete removes the incident permanently along with its notes, photos, tags, involved people, and timeline. This action cannot be undone. Use it only when your church’s policy requires permanent removal and the administrator has confirmed that no record must be retained.

Ongoing administrator practices

  • Review incident role permissions whenever a leader changes roles or leaves the security team.
  • Document escalation rules for Critical, High, sensitive, medical, and law-enforcement-related incidents.
  • Review New, Acknowledged, and In Progress reports regularly so follow-up does not stall.
  • Audit category, priority, location, tag, and status usage for consistency across campuses.
  • Apply your church’s approved retention, privacy, and disclosure policies before exporting, archiving, or deleting records.
  • Test the workflow with each security role so leaders understand what their team members can submit, view, and change.