# Action Requested — Pending Flock Camera Share Requests Series **21 variants** of the same auto-generated subject line (`Action Requested: Pending Flock Camera Share Requests`) sent from Flock's automated notification system to Burningham across the deployment lifetime. Each instance is a routine prompt to the Conway PD Flock administrator: other Flock-customer agencies have submitted camera-share requests that require Burningham's admin-side approval (or denial) on the Conway Flock instance. The series documents the **volume and continuity of inbound camera-share requests** Conway PD receives from other Flock-network agencies — which in turn anchors the topology snapshot in [[SharedNetworks 2025-12-17 Snapshot]] in time. ## What's inside **21 auto-notification emails** (Flock automated, from `[email protected]` or similar), all to Burningham, prompting him to review pending camera-share requests in the Flock admin UI. Each notification is a routine reminder; the actual share requests live inside the platform and are not enumerated in the email body. The 21-variant count over the corpus's operational window (April 2025 — when cameras started coming online — through April 2026 when the production was generated) implies approximately **one pending-share-request notification every 2-3 weeks** on average across the deployment. ## Key takeaways - **Conway PD receives a steady inbound stream of camera-share requests** from other Flock-network agencies. The 21 notifications over ~12 months works out to about 1.75 per month on average. Each notification is a *prompt* (some number of pending requests exists); the underlying number of requests per prompt is not in the email and lives in the admin UI. - **The Conway PD-side administrative pattern is to be the recipient of inbound requests.** Conway PD is not initiating the bulk of new sharing relationships through this notification channel; other agencies are requesting Conway's data. This is consistent with the [[SharedNetworks 2025-12-17 Snapshot]] showing 471 inbound-only relationships (other agencies sharing TO Conway without reciprocal share back), 427 outbound-only (Conway shares TO them), and 486 bidirectional. - **Burningham is the single Conway-side decision-maker.** All 21 notifications go to `[email protected]` — there is no delegate or backup admin. If Burningham is on PTO (and the corpus shows at least 2 OOO autoresponses), camera-share requests pile up. - **The series anchors the growth of Conway's sharing topology over time.** A future supplemental could request a refreshed SharedNetworks snapshot and compare against the 2025-12-17 baseline to quantify how many of these 21 notification cycles resulted in new sharing relationships actually being added. - **No per-request audit trail in the email body.** The volume signal is what's recordable; the substance (which agency requested, what they wanted, when Burningham acted, what he decided) lives only in the Flock admin UI logs (presumably the Organization Audit Log — see [[Flock Audit Logs and Retention]]). ## People and orgs mentioned - [[Lt. Andrew Burningham]] — sole recipient. - [[Flock Safety, Inc.]] — automated sender. ## Concepts invoked - [[Flock Network Sharing - Hot Lists]] - [[Surveillance Data Sharing — Default-On Posture]] ## Events documented - *21 share-request prompts received between roughly Apr 2025 and Apr 2026.* ## Cross-references - [[SharedNetworks 2025-12-17 Snapshot]] — the topology these notifications add to. - [[Conway PD Audit Logs Series]] — the platform-side record of Burningham's actual approvals/denials (if recorded). - [[Home Depot Camera Sharing Series]] — separate notification path for Home Depot's corporate-coordinated rollout (which used a different email subject line and a different Flock-side workflow). - [[Escambia County FL SO Hot List Share]] — example of an inbound share (hot list rather than camera share) from outside Arkansas. ## Open questions / follow-ups 1. **Per-notification request count.** Each "Action Requested" email represents N pending requests at the time of the prompt; N is not exposed in the email body. A supplemental request for "all currently-enabled custom hot lists" should be expanded to also ask for a per-request history of share requests received, decisions, and timestamps. 2. **What fraction of inbound share requests does Burningham approve vs. decline?** Not visible in the corpus. Audit-log inspection would only reveal which counterparties Burningham eventually approved; declined requests presumably leave no trace in the SharedNetworks export. 3. **Backup-admin question.** Is there a CPD-side backup admin? Burningham's OOO autoresponders (see [[Other Operational and Administrative Threads]]) imply at least short windows when he's unreachable; whether pending shares wait for his return or whether anyone else acts on them is open.