How do I know a job was completed by a sensor?

This article explains how sensor readings automatically complete scheduled jobs in BriqSafe, how to identify these auto-completed jobs, and where their activity appears. It is intended for inspectors and managers who need to distinguish jobs completed by sensors from those completed manually and understand the compliance implications.

Note

Required role: Viewer

How Sensors Auto-Complete Scheduled Jobs

Sensors mapped to specific compliance parameters can fill and complete scheduled jobs automatically without manual input.

1. Open the Location where monitoring is set up and ensure jobs are scheduled for today or earlier (in the Location's own day).
2. If a job is Pending or In Progress and requires a parameter that a mapped sensor measures, the system will auto-fill that parameter with the sensor's latest reading automatically.
3. The reading used must be younger than the mapping’s staleness threshold, which is 24 hours by default; older readings are skipped.
4. Each parameter filled stores that single reading’s value, unit, and timestamp within the job record — not the sensor’s full history.
5. Once all required parameters are filled, the job status changes to Completed. If only some are filled, the job remains In Progress. If none are filled, the job status does not change.
6. No manual action is needed for this automatic filling to occur.

Important: Jobs due in the future are never auto-filled; automatic completion only applies to jobs currently due or past due. Also, the Automatic Job Execution setting at the Structure level can disable auto-filling for every job beneath it.

Spotting a Job Completed Automatically by a Sensor

To tell whether a job was completed by a sensor or by a person, review the job activity recorded in the Location.

1. Open the Location and select the Logbook tab.
2. Switch to the Activity view to see a chronological feed of activity at the Location.
3. Look for entries labelled Task auto-completed. These entries indicate jobs completed by the sensor pipeline.
4. Note the actor listed for these entries is System, unlike human users who appear under their own names.
5. Select the row for details, which show the usual event information just like other jobs.

Keep in mind that sensor-completed jobs behave identically to manually completed jobs everywhere downstream in the system, so the Task auto-completed entry and its System actor are the only direct identifiers.

If a job is performed manually after auto-completion, the manual entry supersedes the automatic one.

Reviewing Sensor Activity in the Device Timeline

The device timeline shows connectivity and lifecycle events for an IoT device but does not log sensor readings.

1. Open a device from the IoT Devices list.
2. Scroll down to the Device Timeline card at the bottom of the device’s detail page.
3. Review the device events such as registration, placement, moves, offline periods, and battery warnings.
4. Note each event records the time and actor (System, Vendor, or User), and offline events indicate duration or state if ongoing.

Important: The timeline does not record incoming sensor readings; those values appear only in the device’s telemetry chart higher on the page. The timeline reflects device lifecycle and connectivity only.

Silent Recording of Unneeded Readings

Sensor readings that are not required by any pending job are still stored but do not trigger any action.

• When a reading arrives but no due job requires that parameter, the system records the reading silently for historical reference.
• No job status changes, recommendations, or notifications result from such readings.
• The reading remains visible on the device’s telemetry chart for later review.
• If a new job is created after the reading arrived, and that job is due, it may be auto-filled from this recent reading if it meets staleness criteria.

This behavior ensures sensors act only as measurement instruments tied to scheduled jobs, not as independent alarms.

Understanding Device Status and Compliance

The device status shown in BriqSafe indicates only connectivity, not compliance or measurement quality.

• The device page header displays one of these four states based on lifecycle and last seen time: Online, Pending (registered but not transmitting), Unknown, or Offline (last seen over 30 minutes ago).
• A device’s list row badge shows states such as Online, Offline, Low Battery, or Poor Signal (for weak readings on connected devices).
• Battery and signal indicators differ slightly in threshold between the device page and list rows.
• Critically, an Online device does not prove that any job or measurement passed compliance checks.
• An Offline device also does not by itself signal non-compliance.
• Compliance is determined per job and parameter, not at the device connectivity level.

When a Reading Breaches a Threshold

If a sensor reading used to auto-complete a job breaches a compliance threshold, the following occurs:

1. The job completes normally with no blocking of completion.
2. Breach evaluation happens server-side after job completion.
3. If escalation is warranted, the system creates a draft Technical Recommendation in the Location’s Recommendations tab for review.

No direct alert or case is created immediately from the sensor breach. The draft recommendation must be reviewed and approved or dismissed through normal risk assessment workflows.

Summary Table: Key Differences Between Sensor and Human Completed Jobs

Feature	Sensor Auto-Completed Job	Manually Completed Job
Completion Trigger	Latest sensor reading within 24 hours fills job automatically.	User manually enters readings or measurements on site.
Job Status Change	Status becomes Completed if all needed parameters are filled.	Status updated when user completes or marks a job done.
Logbook Activity Entry	Shown as Task auto-completed with System actor.	Shown with the name of the user who completed the job.
Reading Display	Values stored with job but source sensor not shown on job screens.	Values entered directly and visible on job forms.
Follow-up on Threshold Breach	Draft Technical Recommendation created for review; no immediate alert.	Same process; breach evaluation happens server-side after completion.