How RespondGrid works
The panel and the app do different jobs
RespondGrid is a public map of fire brigades and, for a brigade itself, its records and its dispatching. The browser panel and the phone app do different things, and neither replaces the other.
The browser panel — the brigade's desk
This is where the paperwork lives: roster, qualifications and medical checks, equipment inventory, vehicles, writing up callouts and filing reports. Unhurried work, on a big screen, usually not during an incident. The panel is free.
The phone app — the alert and the drive
This is where the alert arrives, where you declare you are going, where you see who else is on the way and by which road, live and without refreshing: everybody's answer shows on the others' screens within a fraction of a second. Everything that happens in the fifteen minutes after the siren, plus read access to the same records when you need to check something on scene.
What costs money
The brigade panel, its records and the equipment inventory are free, indefinitely. Dispatching is paid: push alerts, positions of responders, and the truck and station-screen modes. When a subscription lapses nothing is deleted — those features simply stop until it is renewed.
Look around before creating an account
There is a demo account that opens a complete brigade panel on invented data: [email protected], password demo. You will see the roster, the equipment inventory with inspection dates, the callout history and device accounts — everything a real brigade's administrator sees. The account saves nothing, so click around freely; you cannot break anything and nothing will disappear.
What has changed since last time
Next to this guide sits "What's new" — the list of changes, newest first. The guide tells you how the system works today; the change list tells you what was added or started working differently, so you do not have to read the whole guide again. Signed-in people see it in the panel; what arrived in the app itself is described by the release notes on Google Play, assembled from the same list. Device screens — the truck, the station screen, the trigger — never get it: they are there to show the alert and nothing else.
Who can do what
Only a confirmed member of a brigade can open its panel. The brigade administrator confirms membership — creating an account and naming a brigade opens nothing by itself.
Brigade administrator
Confirms memberships and assigns roles, raises alerts manually, creates device accounts, connects the dispatch-system integration and deletes callout records. In Management → Subscription enters the invoice data (the buyer and, when somebody else is involved, a payer and a recipient), requests the next period (a package from the price list, the number of years, the start by default the day after the current one ends) or a higher package mid-period (only the difference for the remaining days is paid) and sees the invoices issued to the brigade. A brigade with no administrator has its panel closed to everyone — the first administrator has to be appointed by the portal editors.
Brigade editor
Keeps the records: brigade details, vehicles, equipment inventory, members' qualifications and medical checks, writing up callouts. Cannot raise alerts or create device accounts.
Member
Reads all of the brigade's records, receives alerts, declares availability for a callout and reports periods of absence. Maintains their own details and dates.
Candidate
Sees the same as a member — all of the brigade's records — but formally does not take part in callouts, so has no engagement level. Whether candidates get alarm notifications is up to the brigade administrator (under Management; off by default). A candidate the administrator has allowed still agrees to alarms themselves in their consents. The Members list has a "Candidates" button that shows only them.
A person outside the roster, and the KRS board
The role "Person outside the roster" is for a former responder or somebody from outside the unit, for example a board member: they are in the unit and use the board, but never get alarms, have no engagement level and do not count in the firefighting roster. The management board and audit committee come from the KRS (they are on the unit's public page) and are NOT the same as administrators and editors. Under Manage the administrator links each KRS place to a person of the unit, or adds them as a person outside the roster; board items can then be addressed to the "Board" group. Beside the role choice there is a folded description of what each role can do.
A responder on the roster who is only now creating an account
Anyone listed in the brigade's roster without an account, but with an e-mail address on file, can be invited with a single button on their own card in the roster. Entering the address CREATES NO ACCOUNT and cannot create one — it grants exactly one thing: the ability to send an invitation. The responder sets their own password and nobody else knows it. The invitation carries the role the administrator assigned beforehand. The operational functions (commander, driver, first-aid) follow from the qualifications on the responder's card, so nobody ticks them by hand: they appear when the qualification is added and go when it expires. The roster entry turns into their account rather than a second row beside it, so their whole existing history — qualifications, medical dates, callouts attended — stays with them and nobody shows up twice in the roster. Membership does not have to be confirmed again: an invitation sent by the brigade IS the confirmation.
Registering with an address the brigade already holds
An invitation is not the only way in. Anyone who registers on their own using the address already attached to their roster entry takes that entry over: brigade membership and callout history stay put, and no second row appears in the roster. The account only starts working once the confirmation link in the e-mail is clicked — until then it cannot be signed in to. That is what makes this route safe: entering somebody else's address achieves nothing, because without access to that mailbox the account never comes to life, and the real owner of the address can register again and overwrite the attempt.
An invitation can be sent again
Mail goes missing — spam filters, full mailboxes, providers that simply do not deliver. So an invitation can be resent, no more than once every fifteen minutes per address. Resending invalidates the previous link, so that several live keys to the brigade are not left in circulation after a few attempts. Once the address is corrected the next one goes out immediately — that is a different recipient.
When access to an account is lost
Someone created their account with a mailbox they no longer have, so they can neither log in nor reset the password. The brigade administrator then deletes the ACCOUNT alone: password, Google and Apple sign-in, active sessions, registered phones and any live password-reset or address-confirmation links all go — none of them can quietly restore access. The responder stays on the roster with their role, qualifications, medical dates and their entire callout history; they do not vanish from the roster and nothing is taken off it. The old address stays on the entry so you can see what the account stood on — swap it for a new one and send the invitation again. Accounts that also belong to another brigade, portal editors' accounts and a brigade's last administrator cannot be deleted this way.
Find a unit: asking to join or setting up the panel
In the Profile, under "My units", the "Find a unit" button searches by name or place (the same in the app and in the browser); the unit's public card in the app has the same two buttons. A unit with a panel — one that has an administrator — offers "Request to join": its command confirms the request and only then does the panel open. A unit without a panel has nobody to confirm a request, so instead it offers "Set up the unit panel": a request with your role in the unit and a phone number, which we check by hand, usually by phone. A sent request shows on the unit's card as waiting; a rejected one shows the reason and lets you send a new one. In the app a signed-out visitor sees these buttons too — a tap first leads to signing in and then returns to the same unit.
Detaching an account from a brigade
The brigade's record of a responder — roster entry, qualifications, medical dates, callout history — is a different thing from the person's account. Detaching breaks the link for ONE brigade: the responder stays on its roster as an inactive entry with no account and the full history, while the account remains and can join another brigade or simply browse the portal. An administrator detaches (from the responder's card or in "Manage" mode on the Members tab), and the responder can do it themselves under "My brigades". A brigade's only administrator cannot be detached. Coming back is an ordinary invitation, or a join request with the decision "same person" — the history then moves back onto the account. This is not the same as "Delete account", which removes access alone and keeps the membership.
Why this is not one role for everyone
Raising an alert wakes the whole brigade at night, and deleting a callout removes it from the brigade's history. Those are not things a button can undo, so they stay with one person. Entering equipment and dates carries no such weight, which is why it sits one level up, with the editor.
Where alerts come from
An alert can enter the system by four routes. A brigade picks one, but nothing stops it having two — the same alert will not be raised twice, because duplicates are recognised.
Integration with a dispatch system
The portal polls the system the brigade already uses (currently e-Remiza) and picks up new calls. Nothing has to be done by hand. Requires a separate service account in that system.
Trigger — a phone listening to notifications
Where an integration is not possible, the alert is detected by a phone kept in the station: it reads notifications from the dispatch system's own app and raises the alert in RespondGrid. It costs nothing on the other system's side and works with any of them that sends Android notifications. The tablet in a truck and the board in the garage can do the same if the dispatch system's app runs on them — they only need permission to read notifications.
Trigger — a phone fired by an incoming call
For brigades that have neither an integration nor any dispatch app — but do have a phone number on file with the dispatcher, which rings when a call comes in. The same phone in the station then raises the alert on the ring alone. NOTE: EVERY incoming call does this, wrong numbers and cold callers included — the app does not check who is calling, because reading the number would require access to the call log, which we deliberately do not ask for. That is why the number of that SIM is given to the dispatch system ONLY, and why a personal phone must not be used for this. The feature is off by default and is switched on on that phone, once signed in with the trigger account. IT ALSO WORKS ON iPHONE, but less reliably: iOS does not wake an app on an incoming call, so the trigger screen has to stay in front and the phone on a charger — ideally locked into Guided Access. On Android the screen may be off, and that is a real difference rather than a detail: an iPhone taken off the charger and put in a pocket stops being a trigger.
By hand, by the administrator
The "Raise alert" button in the Alerts tab. For calls that came by phone or radio and will never appear in any system. Works whether or not the brigade has an integration.
Readiness check — a test, not an alarm
An administrator or dispatcher can, in the Alarms tab, in the "Readiness check" segment, send the unit a test notification: to everybody or to chosen groups (drivers, commanders, medics…). Before sending, the portal shows how many people the test will go to and asks for that number to be confirmed. Everybody answers "I could be there in…" or "I couldn't come now"; an answer after the time is saved too (for up to 24 hours), marked "late". It is not an alarm and looks different: a dark green screen, a large TEST label, a sound of its own. It does not go to the register of callouts, the vehicle tablets or the dispatcher, and a real alarm during a check ends it at once. The report shows who answered and how fast, whether a crew for the vehicle would assemble, and - with the reason - whom the notification could not reach (alarms or the notifications permission switched off, no phone, unavailability). The check rides the same consent as alarms, so there is no separate switch for it; names are visible to the command and to the person who started the check, and the administrator can show them to everybody in Management. The feature is paid, like alarming.
The attempt journal — is the station phone working at all
A trigger has no screen to look at, so until now the only test was a real callout. Management, next to the integration, now holds a journal: every nudge sent to the portal, with its time, the account that sent it and what came of it. REJECTED attempts are in there alongside the successful ones, and that is the point of it — silence in the journal means "nobody tried" and tells you to ring the station, while a rejected row means something else entirely and points elsewhere: no new calls in the dispatch system, a lapsed subscription, or an account belonging to another brigade. The brigade administrator reads it, a year back.
Connecting a dispatch system
The brigade administrator sets this up in Management. It takes a few minutes, but one thing has to be prepared beforehand.
Create a SEPARATE service account
Do not use the credentials of an account somebody uses day to day. e-Remiza ties a session to an account: when two programs log in with the same credentials they invalidate each other's session and one of them stops working. A separate account for RespondGrid settles this permanently.
Enter the credentials in the brigade's Management
Management → Integrations & devices → Integration: pick the provider and enter the service account's credentials. Once saved, the portal starts polling every few dozen seconds and shows a marker with the last successful connection.
Account permissions: reads only, nothing else
RespondGrid never writes anything back to the dispatch system — and the brigade should be able to prove that rather than take our word for it. On the Permissions tab leave "Administration" UNCHECKED, along with Add, Modify, Withdraw and Delete in every section. An account that physically cannot change anything is something you can verify on your own system's screen.
One entry is the minimum — the rest adds features
Alerting itself only needs "Alerts → View", and e-Remiza forces that one anyway: a fresh service account already works. Everything else is optional. "Responders → Export" enables the roster import — without it the roster, phone numbers, medical dates and courses have to be typed in by hand. "Map → Vehicle positions" puts the trucks on the map. "Alerts → Alert description" adds the caller's description to the notification. "Callouts → View" prepares the brigade for importing callout history.
Roster import — preview first, save second
A brigade that keeps its people in e-Remiza does not have to retype dozens of them by hand. The brigade administrator starts the import in Management and ALWAYS gets a preview first: how many people will be added, whom the portal already knows, how many medical dates and courses it will fill in, which e-mail addresses clash with somebody else's account. Only the second button writes anything. Our data wins: the import will not overwrite a phone number, an address or a name already entered here — it flags the discrepancy so a human can decide which side is wrong. It also deletes nobody and strips nobody of their role. The import may be repeated after an intake or a course: dates previously fetched by import are refreshed, while entries typed by hand in the panel are left untouched. National ID, date of birth and home address are never fetched at all. The import runs through the integration, so it falls under the same subscription as dispatching.
Do NOT tick responder positions
We show a responder's location only with their own, separate consent given in our app — never on the strength of a permission granted by the brigade. Ticking that box turns nothing on at our end.
The administrator types the password in themselves
The service account's password is not sent to us or to anybody else. The brigade administrator enters it personally under Management → Integrations & devices → Integration. It is stored encrypted and never travels back from the server — the panel only shows "saved" next to it.
Verify before you rely on it
The "Fetch an alarm from e-Remiza" button pulls current calls on demand — use it to confirm the credentials work without waiting for a real callout. Alerts older than a day go into the history without waking anybody.
The full step-by-step instructions
The exact list of boxes to tick — split into required and optional, each with what stops working without it — lives in the document "Konto serwisowe e-Remizy dla RespondGrid". Ask your officers or us for it; it also spells out which personal fields (national ID, home address, date of birth) we never fetch at all.
Three device modes
Besides members' phones, a brigade can run devices that work on their own: nobody logs into them day to day and nobody operates them. The administrator creates them in Management → Integrations & devices, giving a login and a password instead of an email address. Once signed in, the device enters the right mode by itself — there is nothing to choose, the mode follows from the kind of account.
Truck — a tablet in the cab
Shows the incident address, the map and the route, and who is responding. Reports the truck's position so the rest of the brigade and the officer in charge can see where it is. A truck account must be tied to a specific vehicle — otherwise the position would belong to nobody.
Station screen — a display in the garage
A large view readable from across the room: the running alert, who has declared they are coming, and the medical and inspection dates about to lapse. It hangs on the wall and stays lit. It reports no position and is tied to no vehicle.
Trigger — an old phone on a charger
Its only job is to notice the dispatcher's signal and raise the alert in RespondGrid. There is no screen to look at and nobody touches it. The signal is either a notification from the dispatch system's app (needs a one-off permission to read notifications and a list of which apps to listen to) or — for brigades without such an app — an INCOMING CALL to that phone. Call triggering is off by default, because every call to that number then raises the alert, wrong numbers included: the app does not check who is calling. So the number of that SIM is given to the dispatch system only.
Why separate accounts and not somebody's own
A tablet in a truck has no mailbox, no owner and nobody answerable for what is done from it. A device account can do exactly one thing — read the screen prepared for it (a truck additionally reports its position) — and is refused everything else. On somebody's personal account, a stolen tablet would mean access to all the brigade's records.
A device password is typed twice
A device account has no e-mail address, so there is nowhere to send a reset link — a typo in the password does not surface while you are creating the account, but in the evening, at the tablet in the cab. So both when the account is created and when the password is changed the field is doubled, and the save button waits until the two match. The repeat never leaves the browser. A forgotten device password is no disaster: the administrator issues a new one from the panel and signs the device in again.
Phone permissions and consents
The app asks only for what a given feature cannot work without, and asks for each thing separately. Refusing blocks nothing but that one feature.
Notifications — without these there is no alert
The one permission the app makes no sense without: the alert arrives as a notification. It is worth allowing them through Do Not Disturb in the phone's settings too — otherwise the system itself will silence a night callout.
The bell on the map — your notifications
In the app, in the top right corner of the map, the bell opens a list of what the app has sent you: the alarms of the last 30 days that went to your phones, notices (for example a request for access to a unit, for an administrator) and a note that a new version of the app is out. A red badge says how many things are new. A notification that vanished from the lock screen can be found here. The list reads alarms from the delivery log the server keeps anyway; the content of informational notices (a title, a sentence and the unit) is kept on your account until it is deleted. Beside the bell is your avatar with a menu: Profile, Unit with its tabs (Alarms, Responders, Equipment, Board, Statistics, Management), Add a unit, Help and requests, Notifications (the full list of everything the bell ever showed, including what was dismissed from it), Facebook, What's new and Log out.
Android: reading notifications — exactly what leaves the phone
Only the TRIGGER PHONE, the tablet in a truck and the station board ask for this permission, and only when a brigade switches that route on. For a long time we wrote that nothing from notifications reaches the server. Since release 34 something does, and we say so plainly — a description that has stopped being true is worse than none. What reaches the portal is the package name of the app the phone listens to, and the notification's technical characteristics only: whether it is ongoing (one you cannot swipe away) or clearable, its category from the Android constants, the flags mask, the number that app gave it, and its age in seconds. THE CONTENT NEVER LEAVES THE PHONE — not the title, not the text, not the sender, the channel or the attached extras. Why we need it: the dispatch app keeps a "service running" notification in the status bar and refreshes it every minute, and every refresh looks to us exactly like a callout — one phone produced 474 signals in a week that way. Without those few numbers there is no telling refreshes from real alerts, and the brigade is left staring at a wall of contentless knocking in its log.
Android: the alert and a silenced phone
The consent to alarm notifications gives you the notification and the full screen when a call-out comes in, and nothing beyond that. The sound is a separate decision, in the account settings: "Sound that gets past silent mode". It is OFF by default and silence is absolute: a phone on vibrate or silenced only vibrates, because there are moments (an exam, an important meeting) when a loud phone is worse than a late alert. Once you turn it on, a call-out rings out loud despite vibrate and silent mode. To get past Do Not Disturb as well you have to grant the app access to its settings separately — the switch leads you to the right screen. The setting applies to this phone.
iPhone: an exception in Focus
Focus and Do Not Disturb silence the alert along with every other notification, so RespondGrid has to be added to the exceptions: Settings → Focus → your mode → Apps. iOS never tells the app whether you did it and there is no way to check it for you — which is why the readiness list on the account screen asks you to confirm instead of guessing and leaving that step amber forever.
iPhone: the alert and a silenced phone
The only thing on an iPhone that cuts through silence and Focus is a critical alert — and that permission is granted by Apple to the WHOLE app; it cannot be switched on in the phone and it is not a responder's job. Until we have it, the Focus exception above is the only route. The alert sound is not a choice either: iOS has no notification channels, so the app sends the sound with the alert and the phone can only mute it in Settings → Notifications.
Location — travel time and the route
Your position is used to work out how far you are from the station and from the incident, and to guide you there. These are two separate consents: navigation works without sharing your position with the rest of the brigade. Both can be switched off at any time, including mid-callout. While guiding, the buttons on the map are large so they are easy to hit in a moving vehicle; after dusk the map turns dark by itself (the phone works out the sun, no internet needed), and the moon / sun button changes it by hand until the guidance ends.
Sharing your position with the brigade
A separate switch. With it on, the unit sees on the map who is already on the way and from where. Position is collected ONLY during a running alert you have declared for, and only while you are driving: once you are in the station, in the engine or at the scene (near the address, or beside a vehicle that is there) it is deleted and only a status is shown — "in the station", "in the engine", "taking part in the incident". The time you reached the scene stays in the alarm log. If you drive your own car, the dot goes with you all the way to the scene.
Availability by area — you turn it on yourself
OFF by default. If you turn it on, the edges of the two circles the unit has set around the station (a near area, 3 km by default, and a wider one, 7 km by default) are watched by your phone's own system (on Android through Google Play services, on iPhone through iOS region monitoring). When you cross one, the system notices and the app passes the portal one of three results: within the unit's area, in the wider area (more than 7 minutes away) or outside the area — usually within a few minutes, not instantly, depending on the phone and the network. The app does not read your position for this, and now and then only confirms the current result. On an iPhone with only the "While Using" permission the check works only while the app is open. The server NEVER receives your position, your route or any history of places, so there is nothing to store and nobody to show it to. It keeps only the TIMES of the reports (no result, no position) for 30 days, so that the command and the portal administrator can see how often the check is reported. The result (within the area / in the wider area / outside the area) is seen by the unit's command, along with who has the feature turned on; the other responders do not see where anybody is. When you are outside the area, the command sees you in the roster as unavailable, but that is only a picture of availability: you receive alarms always, like everybody else. A manually reported unavailability always takes precedence over this result, and no result (phone off, no signal) never means "outside the area". You can turn it off at any time, in the app's settings or in the panel — it takes effect at once and the stored result and report times are deleted. A unit administrator can switch the feature off for the whole unit and set the radius.
Engagement level — what is counted and who sees it
It is a number from 0 to 10 with one decimal (for example 6.3), shown as a bar of five dashes. Colours: 0–3 red, 4–6 amber, 7–10 green. It shows how well you cooperate through the app. First the gate: without a current medical and the basic training on record (1 pt) the level is 0, whatever the rest says. Then three parts: the consents of "My consents" — alarm notifications, travel time and position — together with the newest version of the app (3 pts, four equal conditions), the speed of your answers to the unit's last five events - alarms and readiness checks, at most two of the latter (2 pts) and — together, as one condition (4 pts) — the consent to availability by area (where the unit uses it) and opening the app at least once every 2 weeks. "Going" and "Not going" score exactly the same — what counts is the speed and honesty of the answer, not a promise to come; the first seconds are worth the most (10, 20 and 30 seconds), slower answers only a little. With fewer than three alarms to judge by, that part is full. If the unit uses mandatory Board items, a fifth part is added (2 pts): an answer on time — declining counts too — and being present at the designated time when the command recorded it (an answer on time with no absence recorded is full points, a recorded absence half, a late answer 0.3, no answer nothing); the other parts are then proportionally lower, still 10 pts in all, and without such items nothing changes. It is NOT an assessment of your qualifications: the other qualifications (first aid, commander, driver and the rest) are not counted at all. Everybody in the unit sees the level; the breakdown and the tips on what to improve only you and the command. Your own level and the way up are in your Profile, above "My consents".
App update reminders
In the Profile, in the "Phone app" card, the "App update reminders" switch is on by default. When the app on your phone is at least three releases behind (only releases published in the store count), the server sends one quiet notification - at most once every 14 days. The setting belongs to the account, not to a unit; you can turn it off here at any time, in the browser, and it takes effect at once.
Why membership has to be confirmed
A brigade's records are its responders' personal data — phone numbers, medical dates, qualifications. Naming a brigade at sign-up is a claim, not proof, so the panel stays shut until an administrator confirms it.
What a brigade keeps in the portal
Everything below is free and available as soon as membership is confirmed.
Members, qualifications and medical checks
A record for each member with the dates that matter: medical checks, courses, driving entitlements. Dates about to lapse are pushed to the top and shown on the station screen. The Members list is ordered by surname, then first name (Polish letters included) and has filters: active (the default), available, unavailable, offline, inactive and everybody; a legend under the list explains the statuses. The dot beside a name is green for available, red for unavailable (a reported absence or away from the station), grey for inactive, and a grey ring means "offline": the brigade checks presence by area and this member has not agreed to it — only the command sees that, and the alert reaches them anyway. An administrator has a "Manage" button here: invitations, approving join requests, "Detach" and "Delete account", and the "Required qualifications", "Terms of service" and "Data processing agreement" sections in the unit settings: the organisation is the controller of its members' data and RespondGrid processes it on its behalf, so the unit's administrator accepts the processing agreement and the terms electronically with one click (the full texts are public at /dpa and /terms). The form of the organisation decides what a unit requires of a member: a volunteer fire brigade by default the basic training and a valid medical examination (the minimum for taking part in a callout), while a rescue group starts with nothing required and chooses from a catalogue of dozens of qualifications (paramedic, qualified first aid, search, water, height rescue, drones and many more). The requirements drive the engagement level and the "trained" group on the Board.
The app version beside every responder
In the Roster list the "App" column shows, for each person, the installed app version (for example "version 1.4.0"), a small platform label (Android or iOS) and - when the app is behind - by how many releases ("3 releases behind", in amber). Only releases published in the store count, not test builds. An empty cell means the person has no registered app. Everybody who may read the unit's roster sees this, so it is clear whom to nudge to update before an alarm is missed. The phone model, the system and the last sign-in remain visible to the command alone.
Function marks beside avatars
The small round marks beside a photo say who is what in the unit. Three are built in - commander, driver and medic - and the unit may add its own (up to twelve), for example a liaison, a water rescuer or a senior medic. In Management, on the "Appearance" tab, the administrator picks an icon and a colour for each mark, can hide it, and sets the CONDITION: who gets it. A condition is built from rows - "has a valid qualification", "has a valid qualification from the group" (for example the whole medical rescue group), "role in the unit" or "assigned by hand" - joined into groups of "all of the following" (and) or "any of the following" (or), also one inside another. Example: a senior medic is a medical examination AND (a paramedic OR a physician). Under the condition a preview says how many members would get the mark before you save. A qualification's validity is counted by itself: when it lapses the mark goes. Marks "assigned by hand" are given by the command on the member's card. The built-in marks can be restored to the defaults with one button. The editor is in the apps too (Manage -> Function marks).
Equipment
An inventory split by vehicle and by location in the station, with inspection dates and type-approval certificate numbers. The list is ordered by urgency, not alphabetically — overdue items first. The whole inventory exports to XLS or PDF.
Vehicles and their deadlines
A vehicle's card has private details visible only inside the brigade: VIN, inventory number, fuel, power, weight, cab seats, tanks, odometer and the deadlines for the technical inspection, third-party (OC) insurance and service. Deadlines that are approaching or overdue are pushed to the top. The brigade's public page does not show any of it.
Statistics: the brigade's and your own
The Statistics tab shows the brigade's year: callouts, hours in action, categories, months and responder participation. Your row in the table is highlighted, and above it stands a separate "My statistics" card: your callouts, how often you commanded or drove, your hours, your place in the brigade and your share of its callouts.
Callouts and reports
Every alert becomes a callout to write up: resources deployed, what happened, who took part. From a completed callout the command (the administrator or an editor) sends the report BY E-MAIL, from the panel or from the app, to the addresses on the unit's list — but that part is OPT-IN, because not every county accepts reports by e-mail, and a reminder about work nobody asked for is the worst kind of noise in a panel. A brigade switches it on in its own settings; while it is off, the panel never asks for a report, does not show it on the callout card and gives it no column in the register. A new brigade starts with reports off — but no brigade that had already sent one, or that has recipients on file, had it taken away.
The report by e-mail: setting up and sending
SETTING UP (administrator). In the panel: Management → Alarming → the "Post-incident report" card. Switch on "We send post-incident reports by e-mail", enter the unit's address (replies to the report come back to it) and add recipients: a name and an e-mail address, for example a district command post or the municipality. The address list is each unit's own; switching the function off does not delete it. In the app, recipients are added in the Management tab. SENDING (administrator and editor). Open the written-up callout, fill in the report (equipment used, water used, kilometres, notes), pick a recipient and tap "Send report". In the panel you can also choose the language of the letter, Polish or English. You are asked to confirm first, because a sent message cannot be taken back. WHAT THE LETTER CARRIES: the unit, the type of incident, start and end, place, description, the vehicles by full name, the crew alphabetically with their role (commander, driver), equipment, water, kilometres and notes; for a rescue group an action report with the outcome, the number of people helped and whom they were handed over to. The message leaves from our domain, but the sender shown is the unit's name and a reply goes to the unit's address, if one is set. Every sending stays in the callout's history together with its text, so the same report can go to several places. A device account (vehicle, board, trigger) does not send reports.
Corrections to the alert data from members
A callout's data (kind, address, description, start and end) is corrected directly by the editor and the administrator. Any other member can propose a correction: it shows at the top of the callout card as "was → to be" and only takes effect once approved. The command learns about it from the bell, and the author is told the decision. The administrator can switch members' proposals off (panel settings; Management in the app); the editor and administrator then edit as before.
The board: events, tasks and polls
The "Board" tab (between Equipment and Statistics, also in the unit menu of the app) holds what happens apart from alerts. An EVENT has times, a place, an agenda, a limit of seats, a sign-up deadline and a waiting list; afterwards the command marks who attended. A TASK has a deadline and a limit of seats or people assigned up front. A POLL is a vote: the author sets the answers and, if allowed, participants add their own; you can pick one or several, vote anonymously and close the voting. Each item is visible to the groups chosen: everyone, responders, candidates, trained (meeting the unit's requirements; in a brigade a valid medical and basic training), command, drivers, commanders, medics or picked people. Who signed up or voted is visible to everybody who can see the item (except in an anonymous poll). Editors and administrators publish at once; any other member proposes an item for approval (the administrator can switch this off under Management). Notifications and reminders go to the bell and as a push. An item (an event, a task or a poll) can be marked MANDATORY: everybody in its audience has to answer — declining or voting counts too — by the given deadline (without one the sign-up deadline, the end of voting or the start of the event counts). Whoever has not answered sees an "Awaiting your answer" mark and a "Waiting for me" filter, the command sees who has not answered, and one reminder comes before the deadline. Answers on time count toward the engagement level (see above). The feature is free.
The board in your calendar
Under the board list there is a "Calendar" card. "Connect to a calendar" creates your private link; "Add to Google Calendar" opens Google with the entry ready to confirm, and "Copy link" is for Apple Calendar and Outlook. The calendar holds the events and the deadlines of tasks and polls you see on the board, with your answer (signed up, on the waiting list, no answer); items you decline disappear and cancelled ones are struck through. Nobody else is in it. Google refreshes such calendars by itself, usually every 12 to 24 hours, so a change may show up only the next day; urgent things arrive as a notification. The link works like a password to the calendar: do not share it, and if it leaks, generate a new one or switch the calendar off. The server keeps the link only encrypted. The calendar provider (Google, Apple, Microsoft) receives the titles, times, places and descriptions of the items, as with any calendar entry. A single item can also be added with the "Add to calendar" button on its screen. The feature is free.
Photos on an alert
Any member of the brigade can add photos to an alert that is on or waiting to be written up, and to a callout in the reports (a callout also shows its alert's photos). This is not the public gallery: photos from the scene never appear on the brigade's page. The author and the command can delete them. The administrator and the editor select photos and e-mail them, as attachments, to an address from the report-recipient list (up to 15 photos and 20 MB per e-mail). Sending has to be confirmed and leaves a trace in the history; it needs reports to be switched on.
The brigade's public page
Photos, vehicles, contact details and description — this is what every visitor to the map sees. A filled-in page is the brigade's shop window and what somebody searching for it online will find.
Where to start
The order is deliberate: each step opens the next. The brigade administrator starts; everyone else joins along the way.
1. Confirm your people
The Members tab, "Manage" button: approve the requests and assign roles. Until you do, nobody but you sees the panel or receives alerts. Firefighters who recorded themselves as "a firefighter of this unit" before the panel existed are not waiting on the list: that is only an entry in the database. They will apply to the unit themselves once the panel is running.
2. Fill in the vehicles
Without vehicles on the list you cannot create a cab-tablet account or assign equipment to them.
3. Connect dispatching
An integration with a dispatch system, or a trigger phone. Check that it works before you trust it at night — that is what the fetch-on-demand button is for.
4. Put the devices up
The screen in the garage and the tablet in the truck. Accounts are created in Management; you sign in once and leave them.
5. Enter equipment and dates
The one step that never ends — and the only one that starts watching the dates for you. Begin with whatever has inspection dates on it.