Knogin
[Core Modules]

Field Worker Persona Architecture and Live Assignment Push

A security officer patrolling an industrial site, a paramedic responding to a call, a substation engineer working an outage, and an auditor on a compliance walk-around all do "field work", but the information they need o

Module metadata

A security officer patrolling an industrial site, a paramedic responding to a call, a substation engineer working an outage, and an auditor on a compliance walk-around all do "field work", but the information they need o

Back to All Modules

Source reference

content/modules/field-persona-architecture.md

Last Updated

Apr 17, 2026

Category

Core Modules

Content checksum

c764d65aed5b9930

Tags

modulescompliancegeospatial

Overview#

A security officer patrolling an industrial site, a paramedic responding to a call, a substation engineer working an outage, and an auditor on a compliance walk-around all do "field work", but the information they need on the screen is different. Calling a safety check a "Lone Worker Task" is right for a utility engineer and confusing for a hospital-contracted community paramedic. Showing an auditor a "Scene Photos" tab is wrong when what they need is "Site Photos". Forcing every field persona through a single generic mobile experience is how mobile apps get abandoned.

At the same time, a dispatcher assigning a work order or an incident to a field unit wants the unit's device to ring within a second of the assignment being recorded in the control centre. Pull-only polling is not acceptable in operational environments.

The Field Worker Persona Architecture addresses both. It models field workers as a unified persona with a domain (public safety, utilities, operations, enterprise) and a profile key (for example, field-responder, field-multi, operator, field-auditor) that selects the right tabs, vocabulary, offline cache, and sync action routes for their role. The Field Push Service broadcasts assignment changes to the assigned user over a tenant-scoped WebSocket so the responder's device receives the new job within milliseconds of the dispatcher saving it.

Diagram

flowchart LR
    A[User signs in on mobile responder PWA] --> B[MobileAppContextService]
    B --> C[Resolve Domain + Profile Key]
    C --> D{Domain}
    D -->|PUBLIC_SAFETY| E[field-responder]
    D -->|UTILITIES| F[field-electric / field-gas / field-water / field-multi]
    D -->|OPERATIONS| G[operator]
    D -->|ENTERPRISE| H[field-security / field-investigator / field-auditor]
    E --> I[Contextual Labels]
    F --> I
    G --> I
    H --> I
    I --> J[Offline Manifest]
    J --> K[Device-Side Cache]
    L[Dispatcher Assigns Work] --> M[FieldPushService.broadcast_assignment]
    M --> N[WebSocket UNIT_ASSIGNMENT_CHANGE]
    N --> O[Device picks up assignment]
    K --> P[Field Execution]
    O --> P
    P --> Q[Offline Sync Queue]
    Q --> R[Middleware Sync Processor]
    R --> S[Audit Trail]

Last Reviewed: 2026-04-17 Last Updated: 2026-04-17

Key Features#

  • Unified Field Persona Model: Every user with field responsibilities is resolved to a domain (PUBLIC_SAFETY, UTILITIES, OPERATIONS, ENTERPRISE) and a persona class (FIELD, DISPATCH, SUPERVISOR). A single code path resolves the profile key that determines the mobile experience, so a new role is added by registering a profile rather than branching the application.

  • Enterprise Domain: The platform includes an ENTERPRISE domain for corporate, industrial, and auditing use cases, with first-class field-security, field-investigator, and field-auditor profiles alongside the existing public safety and utilities profiles. Enterprise customers no longer have to shoehorn their field workforce into a public-safety profile.

  • Contextual Labels: A mapping of sixteen field role keys to persona-appropriate labels is injected into the offline manifest. The same data element is shown as "Site Photos" to a field auditor, "Scene Documentation" to a public safety responder, and "Patient Documentation" to a community paramedic, without changing the underlying payload.

  • Schedule Tab on All Field Profiles: A schedule tab is part of every field profile preset across utilities, public safety, operations, and enterprise. A responder on shift sees their roster and upcoming commitments without switching apps.

  • Offline Manifest with Contextual Labels: The manifest the device downloads at sign-in contains the data the responder needs (assignments, hazards, mission plans, procedures, schedule) plus the contextual labels for the active profile, so the device can render the right vocabulary with no second round trip.

  • Sync Action Types with Audit: The offline sync processor now routes four additional action types: form_submission_submit, mission_step_complete, mission_order_acknowledge, and contingency_activate. Every sync action is logged with a structured AUDIT record that includes the user identifier, tenant identifier, action, resource identifier, and outcome so a retrospective review can see exactly what the device synced and when.

  • Tenant-Scoped Real-Time Assignment Push: The FieldPushService broadcasts UNIT_ASSIGNMENT_CHANGE events over the platform's ConnectionManager WebSocket to the specific user who was assigned. The payload includes assignment type (work order, incident, mission), assignment identifier, title, severity, and tenant identifier. All broadcasts are scoped to the individual user so no other user, even within the same tenant, sees another user's assignment traffic.

  • Permission-Enforced Field Resolvers: Every field operations GraphQL resolver is decorated with permission_classes=[IsAuthenticated], closing the anonymous-read paths that existed before. Combined with the tenant scoping on all queries, this means a field responder cannot enumerate other tenants' work through the mobile GraphQL surface.

  • Feature Flag Awareness: Profile resolution consults the feature flag service so a tenant that has not enabled a domain (for example, a utility-only customer who has not enabled ENTERPRISE) never sees enterprise profile keys in their admin lists.

Use Cases#

  • Field Auditor on an Industrial Site: A compliance auditor signs in on their tablet. Their profile resolves to field-auditor. Tabs and labels match a site-audit vocabulary. Their schedule shows the day's audit stops. A dispatcher reassigns one of their audits mid-morning; the auditor's tablet pings within a second with the new assignment.

  • Paramedic in Marginal Coverage: A paramedic's tablet loads the offline manifest at shift start. The contextual labels for their profile show "Patient Documentation" and "Handover". Throughout the shift they record mission steps, acknowledge mission orders, and activate a contingency when a route is blocked. Each action queues locally with a signed offline sync policy token and syncs back when coverage returns. Every sync event is audited.

  • Utility Crew Multi-Service Callout: A multi-utility engineer with a field-multi profile is dispatched to a gas and water incident at the same address. The dispatcher's assignment hits the engineer's device immediately. The offline manifest includes both gas and water hazard cards. The schedule tab shows the remaining work orders for the day.

  • Security Officer Patrol: A security officer with a field-security profile conducts a rounds patrol. The mobile experience vocabulary ("Site Photos", "Patrol Log") is right for their task. When a supervisor assigns a responsive check, the officer's device pings. The officer submits the completed patrol through the offline sync queue.

  • Operations Persona in a Multi-Domain Tenant: A tenant that runs both public safety and operations has one user group on the operator profile and another on field-responder. Both see a schedule tab, both receive live assignment pushes, but each sees a different offline manifest, a different default tab order, and different default vocabulary.

Integration#

  • Mobile Responder Workspace: The mobile responder PWA reads the profile and contextual labels from the offline manifest on startup and uses them to render the correct tabs and vocabulary. The workspace listens on the WebSocket for UNIT_ASSIGNMENT_CHANGE events and updates the active assignment view in real time.
  • Field Operations GraphQL: All fifteen field operations resolvers enforce IsAuthenticated and pass organization_id on every query. Mobile clients call these resolvers using the session token issued at sign-in.
  • Offline Sync Policy Tokens: Offline actions are submitted with a signed sync policy token so the middleware can verify that the device is still authorised to sync when the connection returns.
  • ConnectionManager: The WebSocket transport is the existing platform ConnectionManager, extended with a broadcast_to_user method that scopes the message delivery to the specific user identifier rather than a tenant-wide channel.
  • Audit Trail: Every offline sync action, assignment push, and contextual manifest download is written to the platform's immutable audit trail.

Open Standards#

  • WebSocket (RFC 6455): the live assignment push uses standard WebSocket framing over TLS.
  • JSON Web Tokens (RFC 7519): offline sync policy tokens are signed JWTs with an explicit tenant identifier and a short expiry.
  • Schema.org Role vocabulary: persona modelling aligns with the Schema.org Role vocabulary where possible.
  • NATO STANAG 4774 / 4778: where a field record contains protected information, the platform applies the standard confidentiality marking and metadata binding at submission time.
  • WCAG 2.2 AA: all field mobile surfaces are tested against WCAG 2.2 AA as part of the platform accessibility baseline. AAA-level components are used where realistic in a mobile field environment (for example, minimum touch target sizes, colour contrast in bright-light conditions).