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. 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. 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.
A firefighter 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 firefighter sets their own password and nobody else knows it. The invitation carries the role and the operational functions the administrator assigned beforehand, so they walk into the brigade already holding them. 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 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 firefighter 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.
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.
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.
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. Settings, 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 Settings. 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 brigade Settings
Settings → 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. "Firefighters → 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 Settings 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 firefighter positions
We show a firefighter'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 Settings → 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 alert from the station" 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 Settings → Brigade 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.
Android: reading notifications — exactly what leaves the phone
Only the TRIGGER PHONE asks 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.
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 firefighter'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.
Sharing your position with the brigade
A separate switch. With it on, the officer in charge 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 deleted when the incident is closed.
Why membership has to be confirmed
A brigade's records are its firefighters' 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.
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.
Callouts and reports
Every alert becomes a callout to write up: resources deployed, what happened, who took part. A completed callout turns into a report sent to the addresses you set — 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 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: approve the requests and assign roles. Until you do, nobody but you sees the panel or receives alerts.
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 Settings; 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.