Skip to main content

July 10, 2026

BluCARE Intelligence​

a. Module Rename​

The AI Ticketing module has been renamed to BluCARE Intelligence, reflecting its expanded capabilities while maintaining the same functionality.

BluCARE Intelligence module rename

b. My Queue​

Introduced a new My Queue section that displays all tickets currently assigned to the logged-in user for easier tracking and management.

My Queue showing tickets assigned to current user

Interactive Maps​

a. Regenerate BluSKY Regions for Existing Maps​

  1. Added a new BluSKY Regions option in Interactive Maps Edit Mode, allowing users to regenerate auto-generated BluSKY Regions for existing maps without recreating the map.

  2. By default, the BluSKY Regions option is disabled, and existing auto-generated regions remain unchanged when saving the map.

  3. Users can enable the BluSKY Regions option to regenerate auto-generated region polygons independently of the Generate Detections option.

  4. Any manually created or edited ROIs are preserved during the regeneration process; only auto-generated BluSKY Regions are updated.

  5. The BluSKY Regions option automatically resets to its default (disabled) state after each successful map save.

BluSKY Regions option in Edit Mode toolbar

b. ROI Label Readability & Vertex Selection Improvements​

Improved ROI editing by making ROI labels scale dynamically with the zoom level for better readability. Reduced the selected vertex indicator to a smaller fixed-size ring and removed the redundant hover ring, resulting in a cleaner and less intrusive editing experience.

ROI label readability and vertex selection improvements

c. Detection Labels Now Stay in Sync with Region Changes​

  1. Detection labels are automatically updated when BluSKY Regions are regenerated.

  2. Renaming a region updates the corresponding detection label (e.g., "Door in Reception").

  3. Deleting a region resets the label to its base class (e.g., "Door").

  4. Region polygons are automatically cleaned up when a device is moved out of a region.

  5. User-edited detection labels are preserved and are never overwritten during regeneration.

  6. If no region changes are detected, existing detection labels remain unchanged.

LogBook Reports​

a. Log Book Reports​

i. A new Reports tab has been added to the LogBook UI, alongside Log & Summaries. It provides a single place to generate all LogBook reports.

ii. Six new report types are available. Every report supports a required date range, System Group/System/Building scope, and export to Excel.

b. Log Book Entry List Report​

i. Key Filters:

  1. Log book Type & Entry Type -- narrow to a specific kind of type & entry (Incident, Check-In, Observation, etc.).
  2. Status Type -- show only Pending, Needs Review, Review Done, and so on.
  3. Person, Min/Max Risk Score -- focus on specific staff or/and on severity.
  4. Include Weather / Temperature / Amendments toggles -- control how much detail shows per entry.
  5. Has Amendments, Has Attachments toggles -- filter to entries that were changed or that have evidence attached.

ii. Value:

  1. One filterable view of all logging activity. Set Entry Type to "Incident Report" for an incident-only view, or raise Min Risk Score to surface only high-severity entries -- no separate report needed.

c. Log Book Review Status Report​

i. Key Filters:

  1. Status Type -- focus on what's still open or what's been signed off.
  2. Aging Threshold (Days) -- required, default 30; defines how many days is "too long" to wait.

ii. Value:

  1. Keeps the review process on track: surfaces entries still awaiting review and flags any sitting open longer than your tolerance, turning a static list into an SLA trigger.

d. Log Book AI Summary Report​

i. Key Filters:

  1. Summary Time Period -- choose the summarization window (Baseline, MultiScene, MultiReader, MultiAlarm, etc.).
  2. Min/Max Risk Score -- read summaries covering higher-risk periods first.

ii. Value:

  1. Read AI-generated summaries of a period instead of every individual entry -- a faster way to stay across activity without losing the context that matters.

e. Log Book Amendment Audit Report​

i. Key Filters:

  1. Original Author -- find changes made to entries originally written by specific people.
  2. Amendment Author -- find changes made by specific people.
  3. Has Attachments -- restrict to amendments that added supporting files.

ii. Value:

  1. A clear, defensible trail of who changed which entries and when -- separating who wrote an entry from who amended it is exactly what compliance and audit reviews need.

f. LogBook Personnel Activity Report​

i. Key Filters:

  1. Entry Type -- measure a specific kind of activity, e.g. check-ins vs. incidents.
  2. Person -- focus on specific staff members rather than the whole roster.

ii. Value:

  1. Shows who is logging, how much, and where -- useful for reviewing workload and coverage across a team.

g. Log Book Building Overview Report​

i. Key Filters:

  1. Date range, System/Building, and Log Book Type -- kept deliberately simple, with no additional filters.

ii. Value:

  1. A one-line health snapshot per building, giving management a clean building-by-building comparison across the portfolio.

Analytics: Visitor Management Analytics​

Added 11 new Visitor management analytics.

a. Visitor Demand per Facility​

i. Provides a per-facility view of visitor demand and how that demand was fulfilled.

ii. Metrics Displayed:

  1. Expected visitors
  2. Arrived pre-authorized visitors
  3. Arrived ad-hoc visitors
  4. No-show visitors
  5. Cancelled visitors

Visitor Demand per Facility

b. Visitor Lifecycle per Facility​

i. New funnel-style graph showing the visitor journey through each stage of a visit.

ii. Stages tracked: visitors expected, visitors arrived, visitors credentialed, first access, and visitors checked out.

iii. Behavior by Facility:

  1. Not all facilities support every stage; buildings without full onboarding will only show a subset (e.g. expected, arrived, credentialed, and first access).
  2. If a visitor is checked in manually by a guard, the "first access" stage may not appear for that visitor.

Visitor Lifecycle per Facility

c. Visitor Pre-Authorization Adoption per Facility​

i. Shows the pre-authorization adoption rate for each occupancy within a building.

ii. A higher pre-auth adoption rate means more advance information is known about visitors, reducing manual work for guards and improving building security.

iii. Pre-Authorized vs. Ad-Hoc Visitors:

  1. Pre-authorized: the host creates the visitor invitation in advance, so both the host and the building know the visitor is coming.
  2. Ad-hoc: no invitation is created in advance -- the guard creates one on the spot when the visitor arrives, with no prior screening and no count toward "expected" visitors.

d. Profile Completeness per Facility​

i. Shows which occupancies do a good or poor job completing required visitor profile fields at the time of invitation.

ii. Incomplete profile fields make it harder for guards to evaluate visitors at check-in and harder to assess risk overall.

Profile Completeness per Facility

e. Repeated Visitor Profile per Facility​

i. Identifies visitors who appear at a facility repeatedly and should therefore have a single recurring visitor profile rather than a new profile created for every visit.

ii. When hosts create a new invitation each time instead of reusing a recurring profile, the system cannot recognize the visitor's pattern, which weakens risk analysis.

Repeated Visitor Profiles per Facility

f. Duplicate Entries per Facility​

i. Measures how well guards/front desk identify existing visitor profiles instead of creating duplicate invitations for the same person.

g. Visitor Access Denials per Facility​

i. Tracks access denial patterns for visitors at building readers, showing where denials occur most.

ii. A high concentration of denials at a specific reader or location may indicate incorrect access provisioning or that visitors were given incorrect instructions.

h. Visitor Floor Access per Facility​

i. Shows which floors visitors from each occupancy access most frequently.

ii. Identifies the floors with the highest overall visitor traffic.

i. Visitor Reader Usage per Facility​

i. Shows which reader is used most by visitors from each occupancy.

ii. Displays the number of swipes recorded on each reader.

j. Visitor Management Quality per Facility​

i. Rates the overall visitor management performance of each occupancy.

ii. Produces a score classifying each occupancy's performance as good, okay, fair, or poor.

iii. Scoring Criteria:

  1. Number of invites
  2. Pre-authorization rate
  3. Profile completeness
  4. Access denials

iv. Enables the team to provide targeted guidance to occupancies on how to use BluSKY more effectively.

Visitor Management Quality per Facility

k. Visitor Check-in Channel per Facility​

i. Identifies exactly which account checked in each visitor at a facility (e.g. which guard performed the check-in).

ii. Displays the checking-in account together with the occupancy name.

iii. Details Captured:

  1. If multiple accounts check visitors in at the same facility, each account's name appears individually.
  2. Check-ins performed through the Web API are attributed to a dedicated Web API account, which also appears in this view.