Ad Hoc Reports Settings

About Ad Hoc Reports Settings

Ad Hoc Reports Settings allows you to configure how users submit and manage ad hoc reports in your organisation. Ad hoc reports are used for incidents or observations that don't fit neatly into Safety, Security, or Dangerous Goods categories.

Note: Unlike other QSS modules, Ad Hoc Reports does not have audits, audit checklists, templates, or report configurations. It focuses purely on investigation of reported incidents.

What You'll Configure

In Ad Hoc Reports Settings, you can configure:

  • Report Categories: Types of ad hoc reports users can submit
  • Investigators: Team members who can investigate ad hoc reports
  • PIC Discretion Reasons: Reasons pilots can use their discretion (unique to Ad Hoc)
  • Duty Violation Reasons: Categories of duty violations (unique to Ad Hoc)
Who Can Access This Page

Access to Ad Hoc Reports Settings requires the Ad Hoc Reports Settings Full Access permission. Changes made here affect all users submitting or investigating ad hoc reports across your organisation.

Settings Tabs

The Ad Hoc Reports Settings page contains 4 tabs. Click any tab below to jump to its documentation:

Critical
Ad Hoc Report Categories

Define what types of ad hoc reports users can submit (e.g., general observation, other incident).

Important
Ad Hoc Investigators

Manage which team members can investigate ad hoc reports in your organisation.

Optional
PIC Discretion Reasons

Configure reasons pilots can use when exercising their discretion (unique to Ad Hoc).

Optional
Duty Violation Reasons

Configure categories for duty violations (unique to Ad Hoc).

Ad Hoc Report Categories

Ad Hoc Context: These report categories control what types of ad hoc reports users can submit and how those reports are processed.

Overview

The Report Categories tab allows administrators to define the types of reports that can be submitted in this section. Report categories determine what information users must provide, what investigation workflows are triggered, and how reports are classified and tracked.

What Report Categories Are

Key Concepts
  • Report category: A classification that defines a type of reportable event or issue
  • Hazard/Event/Area selection: Controls what additional details reporters must or can provide
  • Investigation requirement: Determines if reports in this category automatically require investigation
  • Workflow options: Define how reports are processed and routed
  • Entity selection: Controls organization entity assignment for multi-entity operations
Common Report Categories
  • Safety: Near miss, accident, injury, equipment failure
  • Security: Security breach, unauthorized access, theft, suspicious activity
  • Dangerous Goods: Spill, leak, packaging failure, transport incident
  • Ad Hoc: General concern, suggestion, compliance issue, environmental

What You See Here

Page Controls
  • Active/Deactivated views: Radio buttons to switch between active and deactivated categories
  • Search: Filter categories by name
  • Add button: Create new report categories
  • Categories table: View and manage all report categories with configuration details
  • Edit button: Modify existing category configuration
  • Copy button: Create a new category by duplicating an existing category's configuration
  • Pagination: When there are 16 or more categories, page controls appear

View Existing Report Categories

The Active table displays all available categories with the following columns:

Column Description
Edit Button to modify the category configuration
Copy Button to create a new category by copying this category's configuration. Disabled for system categories (PIC Discretion and Duty Violation).
Name The report category name (sortable by clicking the column header)
Hazards ✓ if reporters can select hazards; ✗ if not available for this category
Events ✓ if reporters can select events; ✗ if not available for this category
Areas ✓ if reporters can select areas; ✗ if not available for this category
Entity (if enabled) ✓ if reporters can select organization entity; ✗ if fixed entity
Default Entity (if enabled) The default organization entity for reports in this category
Deactivate Button to deactivate this category (not available for system categories)
Note: Some categories are system-defined and cannot be deactivated. These are core categories required for proper system operation.

Create a New Report Category

To add a new report category:

Step 1: Basic Information

  1. Click the Add new report category button
  2. Enter a category name (e.g., "Equipment Malfunction", "Security Alert", "Near Miss")
  3. Optionally, add a description to explain when this category should be used

Step 2: Configure Information Selection

Choose what information reporters can or must provide:

  • Hazards: Enable if reporters should identify hazards related to the report
    • Useful for risk assessment and hazard tracking
    • Links reports to hazard registers
  • Events: Enable if reporters should select specific event types
    • Provides standardized event classification
    • Helps with trend analysis and reporting
  • Areas: Enable if reporters should identify the location or operational area
    • Essential for location-based analysis
    • Routes reports to area-specific managers

Step 3: Entity Selection Settings (If Enabled)

If your organization uses multiple entities:

  • Allow entity selection: Enable to let reporters choose which organization entity the report belongs to
  • Default entity: Select the default entity for this category
    • Used when reporters don't select an entity
    • Determines which entity's investigation team is notified

Step 4: Investigation and Workflow Settings

Configure how reports are processed:

  • Investigation required: Set whether reports in this category automatically require investigation
  • Notification settings: Define who receives notifications when reports are submitted
  • Approval workflows: Configure any required review or approval steps
  • Auto-assignment rules: Set up automatic investigator assignment if applicable

Step 5: Save the Category

  1. Review all settings
  2. Click Submit or Save to create the category
  3. The category appears in the Active table
  4. Users can now select this category when submitting reports

Edit an Existing Category

To modify a report category:

  1. Locate the category in the Active table
  2. Click the Edit button (pencil icon)
  3. Update any settings:
    • Change the category name or description
    • Enable or disable hazard/event/area selection
    • Modify entity settings
    • Adjust investigation or workflow settings
  4. Click Submit to save your changes
Important: Changes to category settings apply to new reports only. Existing reports submitted under this category remain unchanged.

Copy an Existing Category

To create a new category based on an existing one:

  1. Locate the category you want to copy in the Active table
  2. Click the Copy button (copy icon) next to the Edit button
  3. A window opens pre-populated with the original category's configuration:
    • General settings (hazard, event, and area selection options)
    • Report fields and field headers (complete field structure)
    • Preview report fields
    • Default investigation team members
    • Entity settings (if enabled)
  4. Change the category name (required - you cannot keep the same name)
  5. Modify any other settings as needed
  6. Click Submit to create the new category

What gets copied: When you copy a category, the system duplicates all active report fields, field headers (including nested sections), default investigation team assignments, and configuration settings. The original category remains unchanged.

When to use copy: Copying is useful when you need a similar category with minor differences. For example, if you have a "Ground Safety Incident" category with detailed fields, you can copy it to create "Ramp Safety Incident" with the same structure but different naming or slight field adjustments.
System category restriction: PIC Discretion and Duty Violation report categories are system-defined and cannot be copied. The copy button is disabled for these categories with a tooltip explanation.

Deactivate a Category

When a category is no longer needed:

  1. Locate the category in the Active table
  2. Click the Deactivate button (ban icon)
  3. Confirm the deactivation if prompted
  4. The category moves to the Deactivated view

What happens when you deactivate: The category is removed from report submission forms. Users can no longer select it for new reports. Existing reports with this category remain unchanged and can still be viewed and processed.

Note: System-defined categories cannot be deactivated as they are essential for core system functionality.

Reactivate a Category

To restore a previously deactivated category:

  1. Switch to the Deactivated view using the radio buttons
  2. Locate the category in the table
  3. Click the Activate button (plus icon)
  4. The category returns to the Active table
  5. Users can now select it again for new reports

Usage in Report Submission

Report categories affect the reporting process:

For Report Submitters:

  • Category selection: Active categories appear in a dropdown when creating reports
  • Dynamic forms: Form fields change based on the selected category's settings
  • Required fields: Hazard/event/area fields appear only if enabled for the category
  • Guidance: Category descriptions help users choose the correct type

For Investigators and Managers:

  • Report classification: Reports are grouped and filtered by category
  • Investigation triggers: Categories with investigation requirements automatically create investigation tasks
  • Notifications: Category settings determine who is notified of new reports
  • Workflow routing: Category configuration controls approval and review routing
  • Trend analysis: Categories enable analysis of report types over time

Permissions

To view and manage report categories, you must have the Ad Hoc Settings - Full Access permission. Users without this permission see an access notification instead of the settings page.

Best Practices

Tips
  • Create specific categories rather than generic ones to enable better analysis and trending (e.g., "Slip/Trip/Fall" instead of just "Accident")
  • Enable hazard/event/area selection for categories where this information provides valuable context for investigation and analysis
  • Write clear category descriptions to help reporters choose the correct category for their reports
  • Review report categories periodically to ensure they reflect current operations and reporting needs
  • Don't create too many categories - aim for 5-15 well-defined categories per section to avoid confusion

Ad Hoc Investigators

Ad Hoc Context: Manage the team members authorized to conduct ad hoc audits or investigate ad hoc reports.

Overview

The Auditors/Investigators tab allows administrators to designate which users can conduct audits or investigate reports in this section. Only users added here will be able to be assigned as auditors or investigators, ensuring proper authorization and access control.

Understanding Auditors vs Investigators

Auditors
  • Purpose: Conduct planned audits and assessments
  • Access: Can create, conduct, and complete audits
  • Responsibilities: Follow audit templates, complete checklists, document findings
  • Assignment: Assigned to audits before or during the audit process
  • Reports: Generate audit reports based on their findings
Investigators
  • Purpose: Investigate events, incidents, or reported issues
  • Access: Can create, investigate, and close investigation reports
  • Responsibilities: Gather evidence, interview witnesses, determine root causes
  • Assignment: Assigned to reports/events requiring investigation
  • Reports: Generate investigation reports with findings and recommendations
Note: Some sections only use auditors (Quality), others only use investigators (Ad Hoc), and some use both (Safety, Security, DG). The page title and functionality adjust accordingly.

What You See Here

Page Controls
  • Search: Filter team members by name, ID number, or passport number
  • Add button: Add new auditors or investigators to the team
  • Team table: View all authorized team members with their details
  • Pagination: When there are 16 or more team members, page controls appear

View Team Members

The table displays all authorized auditors/investigators with the following columns:

Column Description
Name Team member's full name (sortable by clicking the column header)
ID Identity number (sortable)
Passport Passport number (sortable)
Auditor Entity (if enabled) The organization entity this auditor is associated with
Remove Button to remove this team member from auditor/investigator role

Add a Team Member

To authorize a user as an auditor or investigator:

  1. Click the Add new auditor/investigator button (button text varies by section)
  2. In the window that opens, search for and select the user you want to add:
    • Search by name, ID number, or passport number
    • Only active system users appear in the list
    • Users must already exist in the system
  3. If applicable, select the role:
    • Auditor: Can conduct audits only
    • Investigator: Can investigate reports only
    • Both: Can conduct audits and investigate reports
  4. If entity-specific settings are enabled, select the auditor entity (organization they represent)
  5. Click Add or Submit to save
  6. The user appears in the team table
Note: The user receives permissions automatically based on their role. They can now be assigned to audits or investigations in this section.

Remove a Team Member

To remove authorization from an auditor or investigator:

  1. Locate the team member in the table
  2. Click the Remove button (trash icon) in their row
  3. Confirm the removal if prompted
  4. The user is removed from the team table
Important: Removing a team member does not affect audits or reports they are already assigned to. It only prevents them from being assigned to new audits or investigations. Their past work remains unchanged.

Impact on Audit and Report Assignment

Being listed as an auditor or investigator affects several areas:

For Auditors:

  • Audit assignment: They appear in auditor selection lists when creating or editing audits
  • Audit access: They can view and work on audits they are assigned to
  • Findings: They can document findings and observations during audits
  • Reports: They can generate audit reports for their assigned audits
  • Notifications: They receive notifications about their assigned audits

For Investigators:

  • Investigation assignment: They appear in investigator selection lists for reports and events
  • Report access: They can view and work on investigations they are assigned to
  • Evidence collection: They can gather and document evidence
  • Root cause analysis: They can perform and document root cause investigations
  • Reports: They can generate investigation reports for their assigned cases
  • Notifications: They receive notifications about their assigned investigations

Entity-Specific Settings

If entity-specific checklists and templates are enabled in your organization, auditors are associated with specific entities (companies or subsidiaries). This controls which checklists and templates they can access and use. Auditors can only use checklists and templates that belong to:

  • Their assigned entity
  • Parent entities (ancestors) of their assigned entity
  • Subsidiary entities (descendants) of their assigned entity

Search and Filter

To quickly find a team member:

  • Use the Search box to filter by:
    • Name (first name, surname, initials)
    • ID number
    • Passport number
  • Click any column header to sort by that column
  • If there are many team members (16+), use the pagination controls at the bottom of the table

Permissions

To view and manage auditors and investigators, you must have the Ad Hoc Settings - Full Access permission. Users without this permission see an access notification instead of the settings page.

Best Practices

Tips
  • Only authorize users who are trained and qualified to conduct audits or investigations in this area
  • Review the auditor/investigator list regularly to ensure it reflects current team members and qualifications
  • Consider assigning experienced auditors/investigators as mentors for new team members
  • If using entity-specific settings, ensure auditors are assigned to the correct entities for proper access control

PIC Discretion Reasons

What are PIC Discretion Reasons?

PIC Discretion Reasons are predefined reasons that Pilots in Command (PICs) can select when exercising their discretionary authority. This setting is unique to Ad Hoc Reports and allows you to standardise and track the circumstances under which pilots use their discretion.

Add a New PIC Discretion Reason

  1. Navigate to the PIC Discretion Reasons tab in Ad Hoc Reports Settings
  2. Click "Add PIC Discretion Reason" or the equivalent button
  3. Enter a clear, descriptive name for the reason (e.g., "Weather Considerations", "Passenger Welfare", "Operational Efficiency")
  4. Add a description (optional) to provide additional context
  5. Set the status to Active to make it available for selection
  6. Click Save

Edit an Existing PIC Discretion Reason

  1. Find the reason you want to edit in the list
  2. Click the Edit icon next to the reason
  3. Make your changes to the name, description, or status
  4. Click Save

Deactivate a PIC Discretion Reason

  1. Edit the reason using the steps above
  2. Change the status to Inactive
  3. Click Save
Important
Deactivating a PIC Discretion Reason prevents users from selecting it for new reports, but it remains visible in historical reports where it was used.

Usage

When pilots submit ad hoc reports and indicate they exercised PIC discretion, they can select from the active PIC Discretion Reasons you've configured here. This provides consistent tracking and reporting on how and why discretion is being used across your flight operations.

Permissions

Managing PIC Discretion Reasons requires Ad Hoc Reports Settings Full Access permission.

Best Practices

  • Keep reasons specific but not overly restrictive - Provide enough options to cover common scenarios
  • Use clear, aviation-standard terminology - Ensure pilots understand what each reason represents
  • Review periodically - Update reasons based on operational trends and regulatory changes
  • Align with company SOPs - Ensure reasons reflect your organisation's policies on PIC authority

Duty Violation Reasons

What are Duty Violation Reasons?

Duty Violation Reasons are categories used to classify breaches of duty or regulatory violations reported through the ad hoc reporting system. This setting is unique to Ad Hoc Reports and helps your organisation track and analyse duty violations systematically.

Add a New Duty Violation Reason

  1. Navigate to the Duty Violation Reasons tab in Ad Hoc Reports Settings
  2. Click "Add Duty Violation Reason" or the equivalent button
  3. Enter a clear, descriptive name for the category (e.g., "Fatigue", "Procedural Non-Compliance", "Documentation Error")
  4. Add a description (optional) to clarify when this category should be used
  5. Set the status to Active to make it available for selection
  6. Click Save

Edit an Existing Duty Violation Reason

  1. Find the reason you want to edit in the list
  2. Click the Edit icon next to the reason
  3. Make your changes to the name, description, or status
  4. Click Save

Deactivate a Duty Violation Reason

  1. Edit the reason using the steps above
  2. Change the status to Inactive
  3. Click Save
Important
Deactivating a Duty Violation Reason prevents users from selecting it for new reports, but it remains visible in historical reports where it was used.

Usage

When duty violations are reported through the ad hoc reporting system, reporters or investigators can categorise them using the active Duty Violation Reasons you've configured here. This enables trend analysis and helps identify systemic issues requiring corrective action.

Permissions

Managing Duty Violation Reasons requires Ad Hoc Reports Settings Full Access permission.

Best Practices

  • Align with regulatory requirements - Include categories relevant to your aviation authority's requirements
  • Make categories mutually exclusive - Each violation should fit clearly into one category
  • Use neutral, non-punitive language - Focus on classification, not blame, to encourage reporting
  • Review with legal/compliance - Ensure categories support your safety and legal obligations
  • Track trends over time - Use categorisation to identify patterns requiring systemic intervention

Best Practices for Ad Hoc Reports Settings

Report Category Design
  • Keep categories broad but meaningful - Ad hoc reports cover diverse situations
  • Use "catch-all" categories wisely - Provide specific options where possible, but include general categories
  • Enable investigation workflows - Configure categories to trigger appropriate investigation processes
  • Review utilisation regularly - Adjust categories based on what users actually report
Team Management
  • Assign investigators based on expertise - Match investigation topics to investigator qualifications
  • Ensure adequate coverage - Have enough investigators to handle report volume
  • Consider entity assignment - For multi-entity operations, control which investigators see which reports
  • Provide investigation training - Ensure investigators understand ad hoc reporting objectives
PIC Discretion and Duty Violations
  • Standardise terminology - Use consistent, aviation-standard language across all categories
  • Balance detail and simplicity - Provide enough categories to be useful without overwhelming users
  • Foster a just culture - Use non-punitive language to encourage honest reporting
  • Link to SOPs and regulations - Ensure categories align with your operational procedures and regulatory requirements

Related Pages

Navigation
Settings

Theme

Other settings coming soon...

An unhandled error has occurred. Reload 🗙
Interactive features loading...