Ad Hoc – Work Order Comments Data Source

• What - A new Work Order Comments data source is now available in Ad Hoc reporting, making individual comments logged against Work Orders fully reportable. Each comment is represented as its own row, allowing users to analyze comment activity in detail rather than being limited to viewing comments only within the Work Order interface. The data source functions as a child of Work Orders, preserving the relationship between each comment and its parent record. Available fields include key comment details such as the comment identifier, creation date, author, and comment text. The data source supports standard Ad Hoc functionality, including filtering, grouping, sorting, summary reporting, and calculated fields, while maintaining expected reporting behavior for one-to-many relationships.

• Why - Comments often contain important operational context, follow-up details, and audit history related to maintenance activity. Previously, because Work Order comments were only accessible within the Work Order screen, users could not easily review comment trends, filter comments by date or author, or include comment activity in dashboards and scheduled reports. Making Work Order Comments available as a reporting data source improves visibility into maintenance communication, supports auditing and oversight, and expands the analytical value of Work Order reporting without changing how Work Orders themselves function.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • In the Data Sources panel, add the Work Order Comments data source.

  • Optionally add the Work Orders data source to include parent work order details in the report.

  • Create or confirm the relationship between Work Orders and Work Order Comments using the appropriate Work Order identifier.

  • Select the desired comment fields, such as Comment Creation Date, Comment Author, and Comment Text.

  • Apply Criteria, grouping, sorting, or summaries to analyze comment activity.

  • Save or run the report.

  • Note: Because Work Order Comments is a child data source, reports that include both Work Orders and Comments will return multiple rows when a single Work Order has multiple comments.

  • Note: The data source supports standard Ad Hoc reporting features, including tabular reports, summaries, and calculated fields.

• Use Case - A maintenance supervisor wants to review all comments added to Work Orders over the past month to identify recurring issues, follow-up needs, or delays noted during repair activity. By building a report with Work Order Comments joined to Work Orders, the supervisor can group comments by author, filter by creation date, and review comment text alongside work order details. This makes it easier to audit communication history, monitor maintenance follow-up activity, and include comment trends in scheduled operational reporting.

Ad Hoc – ITM Reports Data Source

• What - A new ITM Reports parent data source has been introduced to Ad Hoc reporting, providing a high-level reporting view of Inspection, Testing, and Maintenance (ITM) reports submitted by partner businesses. Each ITM Report is represented as a single row, ensuring a one-to-one relationship with ITM report records and preventing row duplication when performing summary analysis. The data source serves as the primary reporting entry point for the ITM module, consolidating key report attributes such as business name, address, inspection district, inspection zone, property use, identifiers, and report timestamps into a unified dataset. The structure also supports child relationships, allowing related datasets—such as Occupancy—to be joined for expanded reporting context while preserving the integrity of the parent ITM report records. All columns are fully compatible with standard Ad Hoc reporting capabilities, including filtering, grouping, sorting, summary rows, and calculated fields.

• Why - Prior to this enhancement, users lacked a dedicated parent-level reporting dataset for ITM reports, making it difficult to perform high-level analysis on inspection activity, partner business participation, and geographic inspection trends. Without a structured parent data source, users could encounter challenges when attempting to aggregate ITM activity or combine ITM data with related operational context. Introducing the ITM Reports data source provides a stable foundation for ITM reporting, allowing organizations to analyze inspection activity efficiently while maintaining correct data relationships. This structure also prepares the reporting environment for future expansion of ITM-related datasets and reporting capabilities.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • In the Data Sources panel, add the ITM Reports data source.

  • Select desired report fields such as Business Name, Address, Inspection District, Inspection Zone, Property Use, or Report Timestamp.

  • Apply Criteria, grouping, sorting, or summary rows to analyze ITM report activity.

  • Optionally add the Occupancy data source as a child relationship to incorporate additional property context.

  • Save or run the report.

  • Note: Each ITM Report appears as a single row, ensuring accurate aggregation and summary reporting.

  • Note: Joining Occupancy or other related datasets expands report detail while maintaining the integrity of the parent ITM report record.

• Use Case - A fire prevention division wants to evaluate inspection activity performed by partner businesses across different districts. Using the ITM Reports data source, a reporting user builds a summary report grouping ITM reports by Inspection District and Business Name. The report summarizes the number of submitted ITM reports within a given timeframe, providing leadership with visibility into inspection coverage and participation levels across jurisdictions. By optionally joining Occupancy data, the organization can also analyze inspection trends by property type or location, supporting strategic planning and oversight of inspection programs.

Ad Hoc – Fire Investigation Compartment Fire Fields Data Source

• What - A new Fire Investigation Compartment Fire Fields data source has been introduced in Ad Hoc reporting, providing access to dynamic fields associated with the Compartment Fire investigation type within the Fire Investigation module. Certain investigation fields appear only when specific investigation types are selected during report creation, and this data source exposes those Compartment Fire–specific attributes for reporting. The dataset includes fields related to HVAC airflow, duct or diffuser characteristics, structural features, and interior conditions, such as HVAC Air Flows, HVAC Duct or Diffuser Size, HVAC Duct or Diffuser Type, HVAC Description, Doors, Windows, Inside Walls, and Exterior Walls. The data source maintains a strict one-to-one (1:1) relationship with Fire Investigation records, ensuring that including these fields in reports does not create duplicate rows or alter the underlying dataset. It is structured as a child data source of Fire Investigation, allowing users to incorporate Compartment Fire–specific details only when needed while maintaining full compatibility with standard Ad Hoc reporting capabilities.

• Why - The Fire Investigation module supports dynamic fields that appear based on the investigation type selected during the investigation workflow. While these fields provide valuable technical details for specific investigation scenarios, they were previously not available in reporting. This limited users’ ability to analyze structural conditions, ventilation characteristics, and compartment features across multiple investigations. By introducing the Fire Investigation Compartment Fire Fields data source, these specialized fields become accessible for reporting and analysis while preserving the correct relationship to the parent Fire Investigation record. This enhancement enables deeper investigative insights and establishes a scalable framework for exposing additional investigation-type datasets in the future.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Add the Fire Investigation data source to the report.

  • Add the Fire Investigation Compartment Fire Fields child data source.

  • Confirm the 1:1 relationship between Fire Investigation and Fire Investigation Compartment Fire Fields.

  • Select desired fields such as HVAC Air Flows, HVAC Duct or Diffuser Size, HVAC Duct or Diffuser Type, HVAC Description, Doors, Windows, Inside Walls, or Exterior Walls.

  • Apply Criteria, sorting, grouping, summary rows, or calculated fields as needed.

  • Save or run the report.

  • Note: This data source is designed specifically for Compartment Fire investigation records and may return empty values for investigations that do not include this investigation type.

  • Note: The 1:1 relationship ensures that including these fields does not duplicate Fire Investigation rows in reports.

• Use Case - A fire investigation unit wants to analyze structural and ventilation characteristics observed during compartment fire investigations over the past year. Using the Fire Investigation data source combined with Fire Investigation Compartment Fire Fields, the investigator builds a report that includes HVAC airflow descriptions, duct sizes, and wall construction details for each investigation. By grouping results by Investigation District or filtering by date range, the team can identify patterns in ventilation or compartment conditions that may influence fire behavior, supporting both investigative review and training analysis.

Ad Hoc – Fire Investigation Structure Fire Fields Data Source

• What - A new Fire Investigation Structure Fire Fields data source is now available in Ad Hoc reporting, exposing dynamic fields associated specifically with the Structure Fire investigation type in the Fire Investigation module. These fields become available when the Structure Fire investigation type is selected during an investigation and include detailed information about the building, fire protection systems, safety conditions, and investigative observations. The data source is configured as a child data source of Fire Investigation and maintains a strict 1:1 relationship with the parent investigation record, allowing users to include Structure Fire–specific details in reports without introducing duplicate rows. Available fields support reporting on items such as Structure Type, Year Built, Structure Height, Length, and Width, Floors Above Grade and Below Grade, Building Occupied at Time of Fire, Foundation Type, Material Type, Exterior Covering Type, Roof Type, Construction Type, Sprinklers, Standpipes, Security Cameras, Smoke Detectors, Hidden Keys, Security Bars, Door and Window Conditions, Fire Attack Method, Obstacles to Extinguishment, First On Scene details, and general interior, exterior, and investigator observations. The data source also supports aggregated reporting on Fire Protection Systems and is fully compatible with standard Ad Hoc functionality such as Criteria, Sorting, Grouping, Summary Rows, and Calculated Fields.

• Why - Structure fire investigations often require analysis of building features, protection systems, and scene observations that are specific to the Structure Fire investigation type. Previously, these dynamic fields were captured in the investigation workflow but were not easily available for broader reporting and analysis. By exposing these fields through a dedicated reporting data source, users can now evaluate structural characteristics, identify safety system trends, and review investigative conditions across multiple incidents without losing data integrity. This enhancement improves visibility into structure fire investigations and creates a scalable pattern for reporting on additional investigation-type-specific datasets in the future.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Add the Fire Investigation data source to the report.

  • Add the Fire Investigation Structure Fire Fields child data source.

  • Confirm the 1:1 relationship between Fire Investigation and Fire Investigation Structure Fire Fields.

  • Select the desired Structure Fire fields, such as Structure Type, Year Built, Smoke Detectors, Sprinklers, Fire Protection Systems, Door and Window Conditions, or Investigator Comments.

  • Apply Criteria, Sorting, Grouping, Summary Rows, or Calculated Fields as needed.

  • Save or run the report.

  • Note: This data source is intended for investigations that include the Structure Fire investigation type, so fields may be blank when that investigation type does not apply.

  • Note: The 1:1 relationship preserves report integrity and prevents row duplication when these fields are included.

  • Note: Fire Protection Systems values are consolidated into a single reportable field for easier analysis.

• Use Case - A fire investigation team wants to review structure fire incidents to better understand how building characteristics and protection systems may have influenced incident conditions. Using Fire Investigation with the Fire Investigation Structure Fire Fields child data source, the team can build a report showing attributes such as Structure Type, Year Built, Sprinklers, Smoke Detectors, and Obstacles to Extinguishment alongside the investigation record. This allows investigators and analysts to compare structure conditions across incidents, identify common patterns in building safety features, and support post-incident review, training, and trend analysis.

Ad Hoc – Fire Investigation Vehicle Fire Fields Data Source

• What - A new Fire Investigation Vehicle Fire Fields data source has been added to Ad Hoc reporting, exposing dynamic fields associated with the Vehicle Fire investigation type in the Fire Investigation module. These fields become available when the Vehicle Fire investigation type is selected during an investigation and capture details specific to vehicle-related incidents. The dataset is structured as a child data source of Fire Investigation and maintains a strict 1:1 relationship with the parent investigation record, ensuring that including these fields in a report does not create duplicate rows. Available attributes support reporting on vehicle characteristics, investigative details, and inspection findings, including Vehicle Make, Model, Year, VIN, Odometer Reading, License Plate and Country, Theft Status, Recovery Details, Job Number, File Number, Loss Location, Insurance Status, Occurrence Date, Assignment Date, Receipt Date, Inspection Time and Location, Fire and Police Report references, Alarm System presence and type, Hidden Keys, Key Location, Number of Keys, Personal Effects in the vehicle, and contents found in the trunk or cargo area. All fields are fully compatible with standard Ad Hoc reporting features, including Criteria, Sorting, Grouping, Summary Rows, and Calculated Fields.

• Why - Vehicle fire investigations involve specialized data points that are only captured when the Vehicle Fire investigation type is used. Previously, these dynamic fields were available in the investigation workflow but not easily accessible for broader reporting and analysis. This limited users’ ability to evaluate vehicle characteristics, security conditions, and investigation timelines across multiple incidents. By introducing the Fire Investigation Vehicle Fire Fields data source, these vehicle-specific attributes can now be incorporated into reports alongside standard Fire Investigation data, enabling deeper analysis of vehicle fire incidents and supporting investigative review, training, and trend analysis.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Add the Fire Investigation data source to the report.

  • Add the Fire Investigation Vehicle Fire Fields child data source.

  • Confirm the 1:1 relationship between Fire Investigation and Fire Investigation Vehicle Fire Fields.

  • Select the desired vehicle-related fields such as Vehicle Make, Vehicle Model, VIN, Theft Status, Inspection Date, or Alarm System Type.

  • Apply Criteria, Sorting, Grouping, Summary Rows, or Calculated Fields to analyze vehicle investigation data.

  • Save or run the report.

  • Note: This dataset applies specifically to investigations that include the Vehicle Fire investigation type, so some fields may be blank for investigations where that type does not apply.

  • Note: The 1:1 relationship ensures that including these fields does not change the total number of Fire Investigation records returned in the report.

• Use Case - A fire investigation unit wants to analyze trends in vehicle fire incidents over the past year. By combining Fire Investigation with Fire Investigation Vehicle Fire Fields, investigators can create a report displaying vehicle attributes such as Make, Model, Year, Theft Status, and Alarm System presence alongside investigation dates and locations. This allows the team to identify patterns related to vehicle type, security conditions, or investigation timelines, helping investigators better understand factors associated with vehicle fire incidents and support ongoing training and analysis.

Ad Hoc – Fire Investigation Wildfire Data Source

• What - A new Fire Investigation Wildfire data source has been introduced in Ad Hoc reporting, exposing fields that appear dynamically when Wildfire is selected as the Scene Type within the Fire Investigation module. These fields capture investigation details specific to wildfire incidents and are now available for reporting alongside standard Fire Investigation data. The dataset is configured as a child data source of Fire Investigation and maintains a strict 1:1 relationship with the parent investigation record, ensuring wildfire details can be included in reports without creating duplicate rows or altering record counts. Certain attributes—such as Security, Fire Type, and Fire Spread Factor—are presented as list-based columns that translate stored codes into readable values through dictionary lookups. All other wildfire-related fields mirror the column names and data types used in the underlying dataset, ensuring consistency between the investigation interface and reporting outputs while remaining fully compatible with standard Ad Hoc features.

• Why - Wildfire investigations often require the capture of scene-specific details that differ from other fire investigation types. Previously, these dynamic fields were available only within the investigation workflow, limiting the ability to analyze wildfire incidents across reports or combine wildfire-specific attributes with broader investigation data. By introducing the Fire Investigation Wildfire data source, organizations can now include wildfire-specific attributes in reporting and analysis. This enhancement enables investigators and analysts to examine wildfire incidents more effectively while maintaining accurate relationships between investigation records and their associated scene-type details.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Add the Fire Investigation data source to the report.

  • Add the Fire Investigation Wildfire child data source.

  • Confirm the 1:1 relationship between Fire Investigation and Fire Investigation Wildfire.

  • Select desired wildfire-related fields such as Security, Fire Type, Fire Spread Factor, or other wildfire investigation attributes.

  • Apply Criteria, Sorting, Grouping, Summary Rows, or Calculated Fields as needed.

  • Save or run the report.

  • Note: This data source returns values only for investigations where the Scene Type is Wildfire.

  • Note: List-based fields automatically translate stored codes into readable values for reporting.

  • Note: The 1:1 relationship ensures wildfire details can be included without duplicating investigation records.

• Use Case - A fire investigation team wants to analyze wildfire incidents reported over the past season to better understand factors influencing fire behavior and spread. Using Fire Investigation with the Fire Investigation Wildfire child data source, analysts create a report that includes attributes such as Fire Type, Fire Spread Factor, and Security conditions alongside the investigation record. By grouping results by district or date range, the team can identify patterns in wildfire conditions and contribute insights that support training, planning, and incident review.

Ad Hoc – Fire Investigation Marine Fire Data Source

• What - A new Fire Investigation Marine Fire data source is now available in Ad Hoc reporting, exposing dynamic fields associated with the Marine scene type in the Fire Investigation module. These fields capture marine-specific investigation details entered when a fire investigation is documented with a marine scene type. The data source is configured as a child data source of Fire Investigation and maintains a strict 1:1 relationship with the parent investigation record, allowing users to include marine-specific details in reports without creating duplicate rows or altering report counts. Fields such as Loss Location and Engine are presented as readable list-based values through code lookups, while all remaining marine investigation fields retain their underlying names and data types for consistency with the source data. All columns are fully compatible with standard Ad Hoc features, including Criteria, Sorting, Grouping, Summary Rows, and Calculated Fields.

• Why - Marine fire investigations often require scene-specific details that are not relevant to other investigation types. Previously, these fields were only available within the Fire Investigation workflow, which limited users’ ability to analyze marine incidents across reports or combine marine-specific information with broader investigation data. By introducing the Fire Investigation Marine Fire data source, users can now include those investigation details directly in Ad Hoc reporting, improving visibility into marine fire incidents and supporting more detailed review, analysis, and trend reporting.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Add the Fire Investigation data source to the report.

  • Add the Fire Investigation Marine Fire child data source.

  • Confirm the 1:1 relationship between Fire Investigation and Fire Investigation Marine Fire.

  • Select the desired marine-related fields, such as Loss Location, Engine, or other available marine investigation attributes.

  • Apply Criteria, Sorting, Grouping, Summary Rows, or Calculated Fields as needed.

  • Save or run the report.

  • Note: This data source returns values only for investigations where the Scene Type includes Marine.

  • Note: Loss Location and Engine display readable values using system lookups rather than stored internal codes.

  • Note: The 1:1 relationship ensures that adding this data source does not duplicate Fire Investigation records.

• Use Case - A fire investigation team needs to review marine fire incidents documented over the past year to identify patterns in vessel-related investigations. By combining Fire Investigation with the Fire Investigation Marine Fire child data source, the team can report on marine-specific attributes such as Loss Location and Engine alongside standard investigation details. This allows investigators to compare incident characteristics across marine scenes, support case review, and analyze trends that may inform future training or investigative planning.

Ad Hoc – Additional Fields to Incident Report (NERIS)

• What - The Incident Report (NERIS) data source in Ad Hoc reporting has been expanded to include several additional fields that already exist within the NERIS incident reporting form but were previously unavailable for reporting. These new fields provide deeper insight into incident impacts, evacuation activity, and exposure-related scenarios. Added fields include Number of People or Businesses Displaced and Cause for Displacements, which capture displacement impact and contributing factors. A new Hazsit Evacuated field records the number of individuals evacuated due to hazardous situations. Exposure-related reporting is also enhanced through new fields such as Is Exposure, Exposure Number, Exposure Type, Exposure Item, and Exposure Damage. Fields that store coded NERIS values automatically translate those codes into readable descriptions using the NERIS dictionary, ensuring reports display meaningful information. These additions maintain the existing one-row-per-Incident ID dataset structure, preserving performance and preventing duplicate records.

• Why - Certain operational details captured within the NERIS incident reporting workflow—such as displacement impacts, hazardous evacuations, and exposure classifications—were previously unavailable within the reporting environment. This created gaps for agencies seeking to analyze community impact, evaluate evacuation activity, or review exposure-related incidents across reports. By adding these fields to the Incident Report (NERIS) data source, users gain direct reporting access to important incident attributes while maintaining consistency with the data captured in the incident documentation process. This enhancement improves reporting completeness and supports deeper operational analysis without altering the structure or performance of existing reports.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • In the Data Sources panel, select Incident Report (NERIS).

  • In the Columns section, locate the newly available fields, including:

    • Number of People or Businesses Displaced

    • Cause for Displacements

    • Hazsit Evacuated

    • Is Exposure

    • Exposure Number

    • Exposure Type

    • Exposure Item

    • Exposure Damage

  • Add the desired fields to the report output.

  • Apply Criteria, Grouping, Sorting, or Summary Rows as needed to analyze incident data.

  • Save or run the report.

  • Note: Fields that store coded NERIS values automatically translate into readable descriptions within reports.

  • Note: The Is Exposure field is derived from the exposure value in the incident record and returns TRUE when the exposure value is greater than zero.

  • Note: The dataset continues to maintain a one-row-per-Incident ID structure, ensuring no duplication of incident records.

• Use Case - A fire department wants to analyze community impact and evacuation activity related to recent incidents. Using the Incident Report (NERIS) data source, a reporting user builds a report that includes Number of People or Businesses Displaced, Cause for Displacements, and Hazsit Evacuated. By grouping incidents by cause for displacement and summarizing the number of displaced individuals, leadership can better understand how incidents affect residents and businesses. The same report can also include exposure-related fields to identify trends in incidents involving exposure scenarios, helping agencies evaluate response patterns and operational impact.

Ad Hoc – Status Code Refactor for FD Permits

• What - The FD Permit status evaluation logic used in Ad Hoc reporting has been refactored to align with the status logic displayed in the Permits module. Previously, permits that appeared as Expired in the user interface were not always returned as expired in certain Ad Hoc reports—specifically FDR-PERM-001 and FDR-PERM-002—due to differences between how permit status was calculated in the application versus the reporting layer. This enhancement ensures that permit status in reports follows the same business rules used by the application, accurately reflecting expiration conditions. The update supports both automatic permit workflows, where status is derived from lifecycle state combined with expiration logic, and manual workflows, where status is explicitly assigned. As a result, permits that are functionally expired are now consistently returned as Expired in Ad Hoc reports even if the underlying lifecycle state remains approved or in another non-expired status.

• Why - Inconsistent status logic between the Permits module interface and Ad Hoc reporting could cause confusion when users attempted to validate permit expiration or compliance through reports. Permits that appeared expired in the operational interface might not be included in report results when filtering for expired records. Aligning the reporting logic with the application’s status evaluation ensures that reports accurately reflect operational data, improving data trust, compliance visibility, and reporting consistency.

• How

  • Navigate to Ad Hoc Reports → Run or Edit Report.

  • Open an existing permit report such as FDR-PERM-001 or FDR-PERM-002, or create a new report using FD Permit data.

  • Apply Criteria or Filters based on Permit Status (for example, Expired).

  • Run the report to view results.

  • Note: Permit status is now evaluated using the same logic as the Permits module, ensuring reports match the status displayed in the application.

  • Note: Both automatic workflow permits (status derived from lifecycle state and expiration date) and manual workflow permits (explicitly assigned statuses) are supported.

  • Note: No changes to report configuration or filters are required for this update to take effect.

• Use Case - A fire prevention office runs a report to identify expired fire department permits that may require follow-up or renewal. Previously, some permits displayed as Expired in the Permits module were not included in Ad Hoc report results due to differences in status evaluation. With this refactor, the report now returns all permits that the system considers expired according to the same business rules used in the application interface. This allows inspectors and administrators to confidently track compliance and identify permits that require attention without needing to manually reconcile discrepancies between operational views and reports.

Ad Hoc – Minor Updates

• What - Several minor updates have been implemented across Ad Hoc reporting data sources to improve data completeness and alignment with operational workflows. The Daily Log data source now includes an Activity Date field, enabling clearer date-based reporting on daily activity entries. The Personnel data source now exposes Accrual Start Date, allowing reports to reference the beginning date for personnel accrual tracking. Within the All Scheduling Data dataset, the Notes field has been expanded to include notes related to Time Off and Trades, ensuring that scheduling-related commentary is consistently available in reporting outputs. The Hypothesis field has been removed from the Fire Investigation dataset to reflect changes in the underlying data model. Additionally, the Occupancy data source now includes an Occupancy Notes field, allowing operational notes recorded within occupancy records to be included directly in reports.

• Why - These updates improve the completeness, clarity, and usability of reporting data by exposing additional fields that exist within operational workflows while removing fields that are no longer relevant. Adding fields such as Activity Date, Accrual Start Date, and Occupancy Notes allows users to analyze operational timelines and contextual information more effectively. Expanding Scheduling Notes to include Time Off and Trades ensures that scheduling-related details are fully represented in reports. Removing outdated fields helps maintain a clean and accurate reporting schema that reflects the current application structure.

• How

  • Navigate to Ad Hoc Reports → Create or Edit Report.

  • Select the relevant data source (such as Daily Log, Personnel, All Scheduling Data, or Occupancy).

  • Locate the newly available fields in the Columns selection list:

    • Activity Date in Daily Log

    • Accrual Start Date in Personnel

    • Notes in All Scheduling Data (now including Time Off and Trades)

    • Occupancy Notes in Occupancy

  • Add the desired fields to the report.

  • Apply Criteria, Grouping, Sorting, or Summary Rows as needed.

  • Run or save the report.

  • Note: The Hypothesis field has been removed from the Fire Investigation data source and will no longer appear in report column selections.

• Use Case - A scheduling coordinator builds a report using All Scheduling Data to review staffing adjustments and needs visibility into comments related to time-off requests and shift trades. With the updated Notes field now including this information, the coordinator can easily review scheduling context directly within the report. Similarly, a training or HR administrator can use the Personnel data source to track staff records using the newly available Accrual Start Date, while fire prevention staff can include Occupancy Notes in reports to review operational notes associated with inspected properties.