Scheduling integration
Availability stays current from the agency's own scheduling system, which supports auto-rostering of prepared resources.
Platform detail
What ERMS does, capability by capability.
Grouped by the questions a mutual aid order raises: who is available, whether they can do the job, whose turn it is, and who has answered. Ten fire agencies in the Orange County Operational Area have run ERMS as their system of record since December 2018.
Availability
Who is available right now
Daily check-in discipline
Daily checklists for leaders that update as tasks complete, with alerts and flags for incomplete tasks, missing resources and inactive IQS qualifications. Duty status declares Deployable and Recallable independently. Those are the two states availability is actually tracked against.
Geographic availability levels
Resources are tracked by address, city, county, Operational Area, region and state, with availability levels adjustable per agency without a release.
Schedule, roster and history kept apart
What a resource is scheduled to do, what it is doing now and what it did are separate records, rolled forward automatically at each operational period, with adapters for pulling from third-party scheduling and CAD systems.
Pre-filled from the schedule, confirmed by a person
Availability is pre-filled from schedule data, but a change close to a resource's shift needs a person to confirm it before ERMS treats it as real. Schedule-derived status is never reported as confirmed availability.
Qualifications
Whether they can do the job
Qualification-validated availability
Personnel availability is gated on current qualifications before a resource is offered, not after, so only properly qualified personnel are considered.
More than one qualification authority
Each qualification records the authority that defines it, and the link to a national capability type is optional. A local qualification with no national counterpart is a full record, not an exception. A position that satisfies another is modeled once instead of duplicated.
The California catalog, not just the national one
Carried alongside FEMA US&R and Swiftwater/Flood Search and Rescue positions, with certification progress tracked through task books, qualification requirements, and training and experience requirement sets.
One catalog, every entry sourced
Apparatus typing, overhead positions, crews, aircraft, equipment and radio frequencies consolidate into one catalog where every entry names where it came from: about 1,180 from national resource capability types, 167 from CICCS qualifications, and the rest defined by agencies themselves.
Rotations
Whose turn it is
A full Operational Area's team structure
OES teams and locally-owned teams share one rotation surface, filled position by position with approval state. The OES Master Mutual Aid Engine structure runs as its own strike team type with its own rotations, the way the state mutual aid system actually organizes it.
Every capability type the national catalog defines
Task forces, Incident Management Teams, US&R and swiftwater teams, crews and modules alongside single resources. Orange County exercises engine strike teams and overhead daily; the rest are modeled and available.
Every team type assembled the same way
Any team is an ordered set of positions, each filled from a rotation with its own requirements, and nothing in that structure assumes what kind of team it is. A Regional US&R Task Force, engine strike teams at Types 1 and 3, and OES single-resource rotations all assemble on the same logic with different data.
Crew matched to the apparatus
ERMS pairs qualified crew against each apparatus's specific staffing requirements, so a recommended resource is one that is actually crewed, not just listed.
Resource orders
Who has answered
Threaded multi-agency resource orders
IROC-originated resource requests are pushed to the right partner agencies, and their responses run in-thread. In daily use for overhead positions and full strike teams, in-state and out-of-state. Responding from the field, offering a named resource or reporting UTF, happens on the phone today.
Recommended responses against a live request
Agencies see upcoming and open IROC resource requests, and ERMS recommends the closest available resources against a specific request, grounded in current availability.
How it's built
Why most feature requests turn out to be configuration.
The capability list on this page is broader than a ten-agency deployment would predict. That comes out of the data model, not out of an accumulation of features. We did not build breadth. We avoided building special cases.
ERMS treats everything an order can ask for as a capability, whether it came from the national catalog, from CICCS, or from an agency describing its own resources. So a task force, an Incident Management Team, a local specialty certification, 600 feet of rope, a specific medical equipment configuration and the California OES designation are not six features. They are one mechanism holding different data.
OES is the worked example. It is a California-only designation with no national counterpart, expressed as a capability that combines with apparatus type, so an OES Type 1 engine is the intersection of two capabilities. It needed no new resource class and no special case in the code.
A capability is not only a qualification, which is where this stops being an architecture argument. Much of what decides whether a resource fits an order is equipment, not personnel certification. Rope length. A pump rating. A particular medical equipment configuration. On the resource order itself, that requirement travels as free text under special instructions, read by a person and verified by telephone. Nothing can search it, match against it, or confirm it was satisfied. As a capability, "must carry 600 feet of rope" takes part in availability and matching on the same footing as an engine type or a CICCS position.
And it composes. A rotation slot can require several capabilities at once, each with the qualification status it demands, and a resource has to meet every one of them to fill it. That is why most "does it support X" questions turn out to be configuration work, not development work.
Visibility, audit and security
Who can see what, and who changed it
Briefs
Live readiness, apparatus, team and on-duty contact views for dispatch and neighboring agencies, with no ability to alter another agency's data. Available at agency and Operational Area views.
Application-wide audit ledger
Every change across personnel, resources, deployments, resource orders, task books and incidents is recorded and surfaced to administrators for review.
Identity and access
Identity management, role-based access, audit logging of key actions, and data-protection practices appropriate to the sensitive operational data the platform holds.
Hosting
Vendor-hosted cloud. All production data and backups reside in US regions, and no processing is offshored.
Two-factor authentication and passkeys
Two-factor authentication and passkeys (WebAuthn) for every account.
ERMS holds no FedRAMP authorization today. We commit to FedRAMP-compatible architecture and controls aligned to NIST 800-53, and would pursue the level a data classification actually warrants, not the highest one available.
Mobile
From the phone and the apparatus tablet
Native iOS
Daily check-in, status updates, resource order responses, rostering and Briefs all run in the mobile application, from phones, apparatus tablets and desktops. Mobile ordering is a production workflow today, not a planned one.
Customizable dashboards
Widget-based dashboards that mark every panel current, updating or stale, so users know how fresh the information in front of them is.
See your own agency in it.
We stand up your agency's own resources, team types and qualification records. Not a sample dataset.
Phone
949-573-3027