Large public security organization
Security leaders trace each alert to its outcome, seeing only approved records
We built a geospatial system that links alerts, incidents and responses from many teams on one map. One central access layer decides who sees what, and a record reaches maps and charts only after approval up the chain.
Government, Legal & DefenseGeospatial situational awareness platformBuilt from zero
The challenge
Alert, incident and response records came from many teams with uneven verification, nothing tied an alert to its outcome, and each user could see only what their role allowed.
What we did
We built access and approval once, in a central layer every module inherits, linked alerts to incidents and responses with suggested matches, and gave leaders a dashboard on approved data.
The outcome
Every core module, the linkage, access control, approvals and the leadership dashboard shipped, and the requirements added in later rounds, from profile approval to keyword search, were delivered too.
- What shipped
- Alerts, incidents, responses, links, dashboard
- Data shown
- Only records approved at defined levels
- Visibility
- By team, region and headquarters group
- Rules enforced
- Once, in one central access layer
The starting point
A large public security organization needed one place where its leaders could see security alerts, the incidents that followed and the responses, across many teams and regions. Leaders use it to spot hotspots, trace each alert to its outcome and decide where to act.
What had to change
Records came from many teams with different levels of verification, and nothing tied an alert to what happened next. Leadership needed one verified picture, while each team saw only its own data.
What could not break
- Each user sees only the records their team, region or headquarters group allows
- Nothing appears on a map or chart before approval at the defined levels
- The most sensitive fields can be entered by one designated role only
- A record is locked once it receives final approval
- Every module, including ones added later, follows the same rules
The calls we made
We treated who sees what, and when, as the core of the product, so access and approval were built once and every module inherits them.
- 01
One access layer, not one per module
A permission middleware and a generic role based data filter apply the same rules to alerts, incidents, responses, sensitive fields and profiles, so a new module starts with the same protection.
Ruled outVisibility checks written screen by screen, where one missed check exposes data.
- 02
Approval before display
Records move up from team to region to headquarters, rejected ones go back down the chain to the people who entered them, and final approval locks them.
Ruled outShowing records on maps as soon as they are entered and correcting them later.
- 03
Link records, then suggest links
Alerts link to incidents and to responses, with suggested matches from dedicated APIs, so leaders can trace each alert to its outcome.
Ruled outThree separate registers that leadership would have to reconcile by hand.
- 04
Groups decide, not one off exceptions
Headquarters users sit in groups that see specific regions, and group permissions take priority over settings on a single user, so access stays predictable as people change roles.
Ruled outGranting access person by person, which drifts out of step with the organization.
- 05
Scores people can act on
Alert severity went from ten levels to four and updates automatically through a scheduled job, and responses carry an efficiency score shown in four bands, from High to Low.
Ruled outThe ten level severity scale.
How the system fits together
What we built
Linkage and approvals
Alert to incident and alert to response links with suggested matches, and a hierarchical approval flow with rejection back down the chain and final locking.
Leadership dashboard
KPI cards, alert to incident correlation, response assessment, trends, zone cards and a map section, taken from design to static screens to live data in four iterations.
Alerts, incidents and responses
Entry with unique IDs and four alert types, listings, maps with layers, clusters, heat maps, drawing and annotation, and charts and reports for each module.
Access control and profiles
Roles, permissions and groups, protected routes, sensitive fields limited to one designated role, and profile records with four approval levels and version history.
Reports and search
Incident and response reports by region, and a universal keyword search that also reads descriptions.
How it works
Enter
A team clerk records an alert, incident or response with its location on the map.
Approve
The record moves up through team, regional and headquarters approval, or goes back down for edits if rejected.
Link
Approved alerts are linked to incidents and responses, with suggested matches to confirm.
Filter
Each user sees only the records their role, team, region or group allows.
Decide
Leaders read hotspots, trends and outcomes on the maps, reports and dashboard.
A closer look
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [12.34, 56.78]
},
"properties": {
"alert_id": "ALR-0418",
"alert_type": "Info report",
"severity": 3,
"approval": "Final, locked",
"linked_incidents": ["INC-0192"],
"linked_responses": ["RSP-0077"],
"suggested_incidents": ["INC-0201"]
}
}What changed
The client has one system where alerts, incidents and responses are linked, approved and filtered by role, with every core module, access control, approvals and the leadership dashboard delivered. Requirements added in later rounds, from profile approval to keyword search and regional groups, were delivered too, and the system went to the client as an on premise release.
Under the hood
- Datics role
- Product built by Datics
- Access control
- JWT authentication with token refresh, a permission middleware, role based filtering in every API's queryset and protected routes in the front end.
- Sensitive fields
- The most sensitive fields are writable by one designated role only, records lock after final approval, and profiles keep their version history.
- Maps
- Google Maps base layers, GeoJSON feeds for alerts, incidents and responses, clustering, heat maps, drawing and annotation, and admin managed boundary sets.
- Scoring
- Alert severity on four levels, recalculated by a scheduled job, and a response efficiency score shown in four bands from High to Low.
Apps and APIs
Also in the stack
How it shipped
Design and a thin slice
Database design, JWT sign in and a first end to end slice: alert entry, listings and a proof of concept map on Google Maps.
First milestone
The alerts module with maps, drawing and annotation, search and reports, after client feedback added charts and a severity formula.
Second milestone
Incidents, responses, linkage with suggested matches, profiles, and historical records loaded through import scripts.
Access, approvals and dashboard
The central access layer, hierarchical approvals and the leadership dashboard, tested role by role in a QA walkthrough with the client contact.
New requirements, then regression
Profile approval with four data levels, keyword search across descriptions and headquarters groups limited to specific regions, then full regression before the on premise release.
A thin slice first
We started with the design and an end to end slice of sign in, alert entry and a proof of concept map, then showed working builds on a regular rhythm.
Feedback into the next sprint
Each round of client feedback went into the following sprint, including major change requests such as hierarchical approvals, linkage and a new response module.
Scope kept visible
When scope grew, we presented progress against the original milestone plan in three reviews and proposed how to handle the added work.
What this unlocked
AI assisted parsing, a chatbot and OCR entry were planned and then held out of scope. The verified, permission filtered and linked data they would read is already in place.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.