Public CRR Request Forms: From Resident Request to Logged Activity

Most CRR requests reach a department the hard way: a voicemail at the station, a note passed along after a public event, an email that sits in someone's inbox. Public request forms give residents a front door instead. You build a form, publish it to your department's public portal, and every submission lands in a triage queue where your team can assign it, schedule it, and log the completed visit — with the resident kept informed by email the whole way.

The flow, end to end:

1. You build and publish a form tied to one of your CRR programs.
2. A resident fills it out — no account needed — and confirms their email.
3. The request appears in your queue as a card on the Requests board.
4. Your team schedules a visit window, which the resident can see on their own status page.
5. After the visit, you log the activity. The request is marked complete, the resident gets a confirmation email, and the numbers roll into your program metrics.

Before You Start

• Claim your public portal address. Request forms live on your department's public portal, so you need a portal address first. Go to Settings → Public Portal and choose your department's slug (for example, metro-city-fire). Until you do, forms can be drafted but not published — the form editor will point you to this setting.
• Check permissions. Building and publishing forms, and working requests, uses the same CRR permissions as programs and activities. Anyone assigned to a request (or in the assigned crew) can work that request without needing department-wide CRR access.
• Have a program to attach the form to. Every form belongs to a CRR program, and that's where completed work gets counted. If you don't have one yet, create it under CRR → Programs first.

Setting Up a Form

Go to CRR → Forms and click New Form.

Basic info

Give the form a title and description residents will see, pick the program it belongs to (this can't be changed later — it determines where completed work is counted), and choose a URL slug. The editor shows a live preview of the public link, with buttons to copy it or print a QR code poster.

Questions

A resident's name and email are always collected automatically — you don't add questions for those. Beyond that, build whatever your program needs, up to 40 questions. Drag to reorder, and duplicate a question to reuse its settings.

Twelve question types are available: short text, long text, dropdown, multi-select, checkbox, yes/no, number, photo/file upload, date, phone, email, and address. A few options worth knowing:

• Conditional follow-ups. Use "Show when…" to reveal a question only when an earlier answer makes it relevant. Ask "Do you own or rent?" and only renters see "Has your landlord been told the alarms need replacing?"
• "Other" with write-in. On dropdown and multi-select questions, enable Allow "Other" with write-in to add an Other choice that reveals a text box. This is how a catch-all services form stays short without turning away requests you didn't anticipate.
• Number bounds. Number questions can set a minimum, a maximum, and whether decimals are allowed — useful for "How many alarms do you think you need?"
• File uploads. Let residents attach up to 5 photos or files per question (10 MB each) — a photo of a car seat label, for instance, lets your technician check for recalls before the appointment.

Populate request fields

Each question can optionally populate a request field — the resident's phone number, preferred language, service address, preferred dates, or the "what they need" description. Mapped answers become first-class fields on the request that your team can act on directly: the address shows on the request and pre-fills the logged activity, and preferred dates inform scheduling. Unmapped answers still appear in full on the request — mapping just saves your staff from re-typing.

Confirmation and notifications

Write the confirmation message residents see after submitting (it also appears in their verification email), and choose who on your team gets notified when a new request arrives — individual users, groups, or both. Group recipients are resolved when the notification is sent, so roster changes take effect automatically.

Publish

When the form is ready, click Publish. It's now live at your portal URL — share the link on your website and social media, or print the QR code for station lobbies, senior centers, and community events. Unpublish takes it offline any time without losing the form or its requests.

What Residents Experience

The resident fills out the form on your branded portal page — no account, no app. After submitting, they're asked to confirm their email by clicking a link (valid for 7 days). This step matters: a request never reaches your queue until it's confirmed, which keeps spam and typo'd email addresses out of your triage board. Unconfirmed submissions are discarded automatically after 7 days.

Once confirmed, the resident gets a link to their own status page. When your team schedules a visit, the page shows the committed window in your department's local time; when the request is completed or declined, the page and an email say so.

Managing Requests

Confirmed requests appear under CRR → Requests as a four-column board: New, Scheduled, Completed, and Declined. Each card shows the program, the requester, how long they've been waiting, and who's assigned; the full details, including the service address, live one click away on the request itself. Filter by program, or switch between All, Mine, and Unassigned to focus your view.

Drag a card to move it through the pipeline — dragging to Scheduled opens the scheduling dialog, dragging to Declined asks for a reason, and dragging a scheduled request to Completed starts the activity log. Or open the request and use the header actions.

The request detail

Open any card to see the full picture: the requester's contact details and preferred language, the service address, every questionnaire answer with any uploaded files, and a timeline of the request's history.

Assign it

Assign a request to a person, a crew (group), or both. Assigning just a crew puts it in that crew's shared queue; a crew member can then claim it. The assignee — or anyone in the assigned crew — can work the request even without broader CRR permissions.

Schedule a window

Click Schedule and commit to a date and time window. The window is shown to the resident on their status page and in an email, so treat it as a promise — you can always Change window later, and the resident sees the update.

Decline when you must

Not every request is something your department can do. Decline asks for a reason, which is emailed to the resident and shown on their status page. A clear reason — and an alternative, when there is one — turns a "no" into good community relations.

Log the visit

When the work is done, click Log activity. A new activity form opens pre-filled from the request: the program, the address, the scheduled date, and a title are already there. Fill in what your crew actually did — alarms installed, batteries replaced, referrals made, hours spent — and save.

Saving the activity automatically marks the request Completed and links the two together. The resident gets a completion email, and the metrics count toward the program — so your annual report reflects the work without any double entry. There's no shortcut that skips the activity: a completed request always has the record of what was done behind it.

Three Forms That Work in the Real World

A free smoke alarm program

The workhorse. Keep it short — the address, whether they own or rent (with a landlord follow-up for renters), how many floors the home has, whether any alarms currently work, and an optional "anything our crew should know" box. Map the address to the service address field and the open-text box to the request description. A resident can finish it in two minutes, and your crew arrives knowing exactly how many alarms to bring.

Car seat inspection appointments

Ask how many seats and what kind (multi-select: rear-facing infant, convertible, forward-facing harness, booster), whether the family is expecting — with a conditional due-date question so you can prioritize before-birth appointments — and offer an optional photo upload of the seat's manufacturer label so your technician can check for recalls before the family arrives.

A catch-all "fire services request" form

One broad front door so residents never have to guess which form to use: a dropdown of everything you offer — smoke alarm installation, home safety visit, car seat check, extinguisher training, business fire and life safety inspection, Knox box application — with "Other" and a write-in for everything you didn't list. Add a property-type question with a conditional business-name follow-up for commercial requests. Route it to your public education program and re-categorize when you log the activity.

Many departments run both: focused forms linked from campaign pages, plus the catch-all linked from the website footer.

Tips

• Shorter forms get finished. Every question you add costs completions. If your crew can ask it at the door, leave it off the form.
• Use conditional questions instead of instructions. "If renting, please also tell us…" becomes a question that only renters see.
• Print the QR code where your audience already is. Senior centers, pediatrician waiting rooms, food banks, apartment lobbies — the form travels better than a phone number.
• Watch the Unassigned filter. A request that sits in New unassigned is invisible to no one — the waiting-days line on each card makes queue age obvious at standup.
• Declines are outreach too. A declined request with a helpful reason (and an alternative) still counts as a resident who reached your department and got an answer.