Description: The incident report provides all of the basic fields required to document an incident properly. The form also uses fields that ensure the incident is captured in the incident analytics.
Best Practice Use: This report should be completed for every incident on the property. To correctly use this form, create incident categories and set up site locations. This information will populate into the options of the report form. Employees can tag a location and incident type in the report, relaying the information to your incident analytics.
To do so at the Region level go to Settings > General > Email Settings and set the pdf is attach as a link to no
Report takes information about Names, Adresses and Phone numbers from the Region information. To change information like Adress, Name and Phone Number go to Settings -> Company Name / Adress
Import the package by pasting the entire string below:
eyJkZXNjcmlwdGlvbiI6IkluY2lkZW50IFJlcG9ydCIsImRldGFpbHMiOiJDb21wbGV0ZSB0aGlzIHJlcG9ydCBmb3IgYW55IGluY2lkZW50IG9yIG9mZmVuc2UgdGhhdCBvY2N1cnMgb24geW91ciBwb3N0LiIsInNldHRpbmdzIjoie1wiTEFOR1VBR0VcIjpcIkVOX1VTXCIsXCJFTUFJTF9BRE1JTlwiOlwiMVwifSIsImZpZWxkcyI6W3siZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJkYXRlIiwiZGVzY3JpcHRpb24iOiJEYXRlIiwidGFnIjpudWxsfSx7ImV4dHJhIjoiIiwiZmllbGR0eXBlIjoidGltZSIsImRlc2NyaXB0aW9uIjoiVGltZSIsInRhZyI6bnVsbH0seyJleHRyYSI6IiIsImZpZWxkdHlwZSI6Imxpc3RfZmxhZyIsImRlc2NyaXB0aW9uIjoiSW5jaWRlbnQgVHlwZSIsInRhZyI6IiJ9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJ0ZXh0IiwiZGVzY3JpcHRpb24iOiJPdGhlciBJbmNpZGVudCBUeXBlOiIsInRhZyI6bnVsbH0seyJleHRyYSI6IiIsImZpZWxkdHlwZSI6Imxpc3Rfc2l0ZV9sb2NhdGlvbiIsImRlc2NyaXB0aW9uIjoiSW5jaWRlbnQgTG9jYXRpb24gKGFyZWEsIGFwdCBudW1iZXIsIGV0IGNldGVyYSkiLCJ0YWciOm51bGx9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJsaXN0X2VtcGxveWVlIiwiZGVzY3JpcHRpb24iOiJXaGljaCBTdXBlcnZpc29yIHdhcyBOb3RpZmllZCIsInRhZyI6IiJ9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJ0ZXh0IiwiZGVzY3JpcHRpb24iOiJQcm9wZXJ0eSBNYW5hZ2VyIE5vdGlmaWVkIiwidGFnIjoiIn0seyJleHRyYSI6IiIsImZpZWxkdHlwZSI6ImNoZWNrYm94IiwiZGVzY3JpcHRpb24iOiJQb2xpY2UgSW52b2x2ZWQiLCJ0YWciOm51bGx9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJjaGVja2JveCIsImRlc2NyaXB0aW9uIjoiRU1TIEludm9sdmVkIiwidGFnIjpudWxsfSx7ImV4dHJhIjoiIiwiZmllbGR0eXBlIjoiY2hlY2tib3giLCJkZXNjcmlwdGlvbiI6IkZpcmUgSW52b2x2ZWQiLCJ0YWciOm51bGx9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJjaGVja2JveCIsImRlc2NyaXB0aW9uIjoiQXJyZXN0IE1hZGUiLCJ0YWciOm51bGx9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJ0ZXh0YXJlYSIsImRlc2NyaXB0aW9uIjoiTmFycmF0aXZlIiwidGFnIjpudWxsfSx7ImV4dHJhIjoiIiwiZmllbGR0eXBlIjoicGljdHVyZSIsImRlc2NyaXB0aW9uIjoiUGhvdG8gMSIsInRhZyI6bnVsbH0seyJleHRyYSI6IiIsImZpZWxkdHlwZSI6InBpY3R1cmUiLCJkZXNjcmlwdGlvbiI6IlBob3RvIDIiLCJ0YWciOm51bGx9LHsiZXh0cmEiOiIiLCJmaWVsZHR5cGUiOiJwaWN0dXJlIiwiZGVzY3JpcHRpb24iOiJQaG90byAzIiwidGFnIjpudWxsfSx7ImV4dHJhIjoiIiwiZmllbGR0eXBlIjoicGljdHVyZSIsImRlc2NyaXB0aW9uIjoiUGhvdG8gNCIsInRhZyI6bnVsbH0seyJleHRyYSI6IkkgaGVyZWJ5IGRlY2xhcmUgdGhhdCBhbGwgaW5mb3JtYXRpb24gcHJvdmlkZWQgaXMgYWNjdXJhdGUgYW5kIHRydWUgdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLiIsImZpZWxkdHlwZSI6InNpZ25hdHVyZSIsImRlc2NyaXB0aW9uIjoiT2ZmaWNlcidzIFNpZ25hdHVyZSIsInRhZyI6IiJ9XX0=Example Report

Troubleshooting Blank Historical Incident Reports
If previously submitted incident reports (including flagged ones) appear blank in the app or in downloaded PDFs/exports, this usually indicates that fields in the report template were archived, removed, or modified in a way that changed their identifiers. Historical reports store responses against the original field IDs; when those fields no longer exist or are archived, the system cannot map stored values to active fields, resulting in blank output.
Why this happens:
- Archiving or deleting fields from a report template that has already been used removes those fields from the active schema. The system can no longer match historical responses to a current, active field, so the UI and exports appear blank.
- Editing a template in place (for example, changing a field’s type or its underlying key/identifier, not just its display name) can break the link between historical data and the field, producing blank reports.
Immediate actions to restore visibility (if changes were recent):
- Identify the affected template: Go to Settings > Report Templates and open the incident report template used at the sites where reports appear blank.
- Check for archived or removed fields: Use the Field Set Up button to review the template’s field list and show archived items (use the “Show archived fields” toggle when available). Note any fields that were archived or deleted after the reports were submitted.
- Unarchive fields (if possible): Unarchive the previously archived fields and save the template. Reopen the historical incident reports in the app and try exporting them again. In most cases, previously stored data will display once the original fields exist again.
- If fields were deleted (not just archived): Deleted fields typically cannot be restored, and historical data may be unrecoverable in the UI. Contact Support with example report IDs, the template name, and the date/time of changes to explore recovery options if available.
Best practices to prevent blank historical reports:
- Do not modify an active, in‑use report template. Instead, duplicate the template to create a new version, then make changes in the new version.
- Never delete or archive fields in a template that has historical submissions you still need to view. You can unassign the old template from future use but keep its fields intact for historical viewing.
- Use versioning: name templates with a version suffix (for example, “Incident Report v2”) and schedule a cutover. Inform users when the switch will occur.
- Pilot changes: assign the new template to a test site, submit sample reports, and confirm exports render correctly before a full rollout.
- Keep a change log: record who changed the template, what changed, and when, so you can quickly reverse harmful edits.
Safe update procedure (recommended):
- Duplicate the current incident report template: Settings > Report Templates > Duplicate.
- Make your changes in the duplicate (add/remove fields, change types, and so on).
- Assign the new template to the target sites or roles and set the go‑live time.
- Ensure all in‑progress drafts are submitted before switching templates to avoid draft incompatibilities.
- Leave the original template intact (do not delete fields). Unassign it from future use but retain it for historical viewing.
FAQs:
- Are our historical incident responses deleted? Typically no. The data still exists but cannot be rendered if the matching fields are archived or removed. Unarchiving often restores visibility.
- Why are downloaded PDFs also blank? Exports use the same field mapping as in‑app views; if the fields are missing, the export has nothing to render.
- Can Support recover deleted fields? This depends on your environment and retention policies. Provide template names, change timestamps, and sample report IDs to Support for guidance.
Incident Category "N/A" in analytics
In the Incident Category chart/report, the category "N/A" appears when no site location has been selected on the incident report. This typically indicates incomplete or missing context for the incident.
How to avoid "N/A":
- Make the site/location field required in your incident form configuration, where possible.
- Train users to select the correct site or location before submitting incidents.
- Review existing incidents with "N/A" and edit them to add the correct site/location where policy allows.
- Re-run your charts after updating location data so categories reflect accurately.
Why this matters: "N/A" can skew analytics by lumping incidents without site context into a single catch-all category. Accurate site/location selection improves trend analysis, staffing decisions, and accountability. If your workflow intentionally allows incidents without a location, consider adding guidance or a placeholder location option that aligns with your reporting needs.