The public transparency portal is a branded, unauthenticated web page about your UAS program: program statistics and a grid of flights with maps, published from records your pilots already create. Your community and local press can check your drone activity there without filing a records request.
This article is for the person who owns that page — usually the program manager or the PIO working with them. The portal runs only on a dedicated (enterprise) instance with the Public Portal feature enabled by the platform admin; it is never available on the shared multi-tenant app on any plan. Configuring it requires Global Admin; editing the branding it uses requires System Admin.
Before you start. The portal publishes automatically. Its per-instance master switch defaults to on,
the default release delay is
0days, and both content sections default to visible. If the Public Portalfeature has just been enabled for your instance, treat the page as already live and open it before you do
anything else.
What the portal publishes, and what it does not
The public page has two independently switchable sections: a statistics block headed UAS Operations — by the numbers, and Historical flight data, a grid of flight cards with maps. Each card links to a per-flight page with a larger, fullscreen-capable map.
| Published | Where it comes from |
|---|---|
| Agency name and logo | Agency branding on the Admin screen |
| Total flights, incidents responded, assisted arrests, calls assisted, average response time | Flight records and DFR incidents |
| Top call types, as a chart with counts and percentages | The call type on each DFR incident |
| Flight date and time, incident/case number, unit | The flight record and its post-flight checklist |
| Flight summary text | A post-flight checklist answer (see below) |
| Takeoff point, landing point, and the ground track on a satellite map | Recorded flight geometry and telemetry |
| Flight duration | The per-flight detail page only |
The portal requests a deliberately narrow set of fields. It does not include the pilot's name, the aircraft or its serial, altitude or speed figures, battery data, media or video, or any post-flight checklist answer other than the summary — the incident and equipment-problem fields stay inside the application.
The exposure that surprises people is geographic: the map shows the actual recorded takeoff location and, where telemetry exists, the flight's ground track. If your agency has a policy about publishing takeoff points near sensitive addresses, decide it before the page is live.
Verify, do not assume. Before you announce the URL, open the portal and one flight's detail page
yourself and read every value shown. If something appears that you did not expect, that is the moment to
fix it.
Turning the portal on and branding it
The platform-level Public Portal feature has to be enabled for your instance first — that is set in the control plane, not in your Admin screen. Once it is, a Public Portal card appears on Admin for Global Admins and above.
- Go to Admin and select Configure public portal.
- Set Public site enabled. Off makes the public site completely unavailable — it returns not-found rather than an empty page. There is no separate private preview, so if you need time to configure, turn this off first and back on when you are ready.
- Set the remaining options (below) and choose Save settings.
The header uses your agency branding: the agency name and logo, with the subtitle Drone Program — Public Transparency. Both come from the Agency Branding section of Admin, which on a dedicated instance is System Admin only. Set Agency name to the full name you want the public to read; the logo upload accepts an image under 500 KB. See admin and agency setup for the rest of that screen.
Choosing which flights appear
Three settings on the Public Portal screen control the population of the flight grid.
- What flights appear — either DFR flights only or All UAS flights. The default is DFR only, which matches flights recorded with a DFR mission type. If you select it and the grid comes back empty while you know flights exist, switch to All UAS flights and compare before deciding which scope to ship with.
- Release delay (days) — flights are held back until this many whole days have passed since takeoff.
0publishes them as soon as they exist. A few days is the usual choice: it gives supervisors a window to review a flight and pull it down before anyone outside the agency sees it. - Separate portal per unit — off gives one agency-wide page. On gives each unit its own page and adds a unit picker to the header.
Statistics are not filtered like the grid. The tiles and the call-type chart count every in-scope
flight and every DFR incident, including flights hidden from the grid and flights still inside the release
delay. If an aggregate count is itself a concern, turn Show statistics off rather than managing it
flight by flight.
Where the flight narrative comes from
There is no separate public-summary screen to maintain. The narrative on each card comes from the pilot's post-flight checklist, which is why the portal and the checklist are one mechanism rather than two.
When the portal is enabled, two questions are added automatically to every active post-flight template and locked there — they carry a Portal badge on the Checklists admin screen and cannot be deleted while the portal is on. Disabling the portal strips them back out of every template.
- Public page summary — a short required text field, hinted with examples like "Theft", "Assault", "Fire". This is the text that appears as the card's Summary.
- Remove this flight from the public page? — a toggle, covered in the next section.
The case or incident number captured on the same checklist becomes the flight's title in the app and the Incident value on the public card, so treat that field as public-facing too.
Watch which field supplies the text. The published summary is chosen by matching post-flight answers
against field names containing summary, narrative, description, or note, and the first match with
text in it wins in template order. Adding a "Supervisor notes" or "Narrative" field, or reordering fields,
can change what the public sees. Check the portal after any post-flight template edit.
For how the checklist is completed, edited, and applied across a mission, see post-flight checklists.
Keeping a flight off the public page
The portal is opt-out. Flights in scope publish on their own once the release delay passes; nothing waits on an approval step. The control is the checklist toggle Remove this flight from the public page? — answering yes hides that flight from both the grid and its own detail URL, and the public summary stops being required.
To pull a flight down after the fact, edit its completed post-flight checklist and set that toggle. A completed checklist can be edited by the person who completed it or by a supervisor and above, and saving re-applies the visibility answer immediately.
Note that a flight with no post-flight checklist at all is not hidden — nothing set the toggle, so it can still appear, with an em dash in place of a summary.
The public URL and per-unit pages
The portal lives at /public on your instance's own domain, and the Portal address card on the Public Portal screen shows the full URL for your instance and links to it. Individual flights are at /public/flight/ plus the flight's id. With per-unit portals on, a unit's page is /public?unit=… and the header carries a unit picker.
The grid pages nine flights at a time with Previous and Next controls. The page needs no login of any kind — anyone with the link can read it, and you should assume the link travels. Link it from your agency's website when you are ready for it to be found.
This page is the standing artifact behind the community-trust case for a DFR program made in the DFR program guide, and it carries much of the recurring publication burden California agencies face under AB 481. It is not by itself a compliant AB 481 filing — see the AB 481 transparency guide for what the annual report and policy publication require, and generate the AB 481 Deployment Report from the Reports screen for the filing.
Before you make it live
Work through this the first time, and again after any change to a post-flight template.
- Turn Public site enabled off while you configure, so nothing is readable mid-setup.
- Confirm the agency name and logo are the ones you want the public to read.
- Choose the flight scope and set a release delay your supervisors can work inside.
- Decide whether statistics should be on, knowing the tiles count hidden flights.
- Turn the site on, open the portal URL, and page through the whole grid — not just the first card.
- Open at least one flight detail page and read every field, including the map extent.
- Confirm the summary on several cards is the field you intended, with no free-text answer leaking in.
- Have someone outside the program read the page cold and tell you what it says.
Frequently asked questions
Does a supervisor have to approve each flight before it appears publicly?
No. The portal is opt-out: a flight in scope publishes automatically once the configured release delay has passed. The only control is the post-flight checklist question "Remove this flight from the public page?", which a pilot answers at completion and a supervisor can change afterward by editing the checklist. If you want a review step, set a release delay long enough for your supervisors to review flights inside it.
Is the pilot's name published on the portal?
No. The portal's data request does not include pilot, aircraft, serial number, altitude, speed, battery, or media. It publishes date and time, incident or case number, unit, the checklist-derived summary, duration on the detail page, and the flight's takeoff, landing, and ground track on a map. Confirm this against your own live page before you announce the URL.
Can I publish the portal without showing individual flights?
Yes. Turn Show mapped flights off and leave Show statistics on, and the page becomes program totals, average response time, and the top call-types chart with no per-flight cards or maps. The reverse also works: turn statistics off and publish only the flight grid. Both switches are on the Public Portal screen and take effect as soon as you save.
Why is my flight grid empty when the portal is turned on?
Two settings usually explain it. If the scope is DFR flights only, only flights recorded as DFR missions qualify — switch to All UAS flights and reload to see whether that is the cause. If the release delay is set to several days, recent flights are held back until that window passes. Flights explicitly marked "remove from the public page" never appear regardless of either setting.
Does turning the portal off remove flights that were already public?
Turning the instance master switch off makes the entire public site return not-found immediately, including individual flight URLs, so nothing is readable. It also removes the two portal questions from your post-flight checklist templates. It does not erase the hidden marks already recorded on flights, so if you turn the portal back on later, those flights stay off the page.
Where to go next
Settle the post-flight checklist before you make the portal public — the summary field is the whole narrative, so the wording and field order are worth getting right. Start with post-flight checklists, then DFR incident tracking if your statistics depend on DFR call types and response times, and admin and agency setup for the branding the page inherits.