What's New

To support new features in Flex

Work Location Status 

• A new endpoint to retrieve user preferences for an authenticated user: /v2/{nodeid}/UserPreferences

Parking slot bookings

• To support the new feature, we now have two more fields being added to the v2/{nodeid}/bookings endpoint:
  • Parent_Booking_Id - string
  • Parent_Booking_Relation_Type - enum

Team Bookings 

The ability to create teams and make bookings for them has been added to the platform. To support this we now have:

• New TeamId and TeamBookingId fields in the endpoints:
  • POST v2/{nodeid}/bookingparties?bookingid={bookingid}
  • POST v2/{nodeid}/bookingparties/import/{bookingid}
• New endpoints:
  • GET v2/{nodeid}/bookings/team-bookings/{teambookingid}
  • PATCH /v2/{nodeid}/spaces/{teambookingid}/team-checkin
  • PATCH /v2/{nodeid}/spaces/{teambookingid}/team-checkout
  • PATCH /v2/{nodeid}/bookings/team-bookings/{teambookingid}/cancel
  • PATCH /v2/{nodeid}/bookings/team-bookings/{teambookingid}

To support new features in OneLens

Visitor Dashboard

To support this feature the following additions have been made:

• V2/VisitSummaries/Daily/{start-date}/{end-date}
• V2/VisitSummaries/Weekly/{week-start-date}/{week-end-date}
• V2/VisitSummaries/Monthly/{month-start-date}/{month-end-date}
• Added enhancement to calculate averageVisitDurationMinutes for the weekly and monthly summary data

New import functionality

Users with the Create Visitor permission can bulk import standalone visitors into IBSS. A new API endpoint has been added to support this:

• /v2/{nodeid}/visits/import

Various improvements to make the import of catering items and menus possible. To support this:

• Added a new permission API.CateringMenuItems.Import to the available rights
• Extended the webjob to handle the import as a background task
• Modified v2/{nodeid}/catering-menuitem/import to handle the import file

New export functionality

Users can now pick and choose what booking data they want to include in the export of bookings. To do this we have added the endpoint:

• /v2/{nodeId}/bookings/download

New catering report downloads

We've created several standard catering report downloads. These are supported by the following new endpoints:

• /v2/{nodeid}/catering-order/report/download
• /v2/{nodeid}/catering-menuitem/report/download
• /v2/{nodeid}/catering-order/report-supplier-cost/download
• /v2/{nodeid}/catering-order/{orderid}/report-catering-menuitem/download
• /v2/{nodeid}/costcodes/{costcode}/report-catering-orders/download
• /v2/{nodeid}/catering-order-policy/{cateringOrderPolicyId}/report-catering-menuitem/download

To support new features in Admin Portal

Device Configuration

Where Unity or Inspire apps have been deployed within an environment, a new interface has been created to apply configuration changes to these. To support this the following permissions is available:

• New: ADMINPORTAL.Manage.Devices
• Existing: DATAMODEL.Devices.CRUD

Space Configuration

The ability to import and export the space configuration on a per floor basis has been improved. We now:

• Have handling for background processing of bulk imports in to the v2/{NodeId}/spaceconfigurations/import endpoint
• Introduced additional validation on the Node ID 
• Added the Space_Light_Mode field

Building Parameters

The ability to control building level configuration parameters has been added. To support this the following have been added/updated:

• Permissions
  • New permission for page: ADMINPORTAL.Manage.Parameters
  • Existing permissions: DATAMODEL.Parameters.CRUD

Booking Policies updates

• External attendees control. You can restrict some spaces so that users will not be able to add external attendees to bookings in those. There won't be any notification to the user from app perspective that the space booking conditions have changed. We expect that spaces with external attendee restrictions are communicated separately organisation-wide. To support this:
  • We've added the new field AllowExternalAttendees to the following endpoints:
    • POST /v2/{nodeid}/bookingpolicies
    • PUT /v2/{nodeid}/bookingpolicies/{bookingpolicyid}
  • Extended the booking parties validation method ValidateAttendee to check if the booking participant is external.
• Extended recurrence limit from 52 to 365 maximum events with additional options:
  • RecurrenceLimit building parameter to ensure that no series of recurrent bookings exceeds one calendar year.
  • API.Bookings.IgnoreRecurrenceLimitsInPolicy permission to override recurrence limit set by a booking policy.

What's changed

For all users

• Language selector is added to all web apps.
• We've added support for passive occupancy (“Signs of Life” – SoL) sensor data via a new V2 endpoint /v2/{nodeid}/Spaces/update-space-occupancy, enabling spaces to be marked as occupied based on sensor activity rather than bookings. Introduced a building parameter SensorSignsOfLifeUpdates to turn on the sensor data usage.
• We've added the API support for the future functionality of adding up to 10 image attachments to a raised Service Request to be available in Flex and Roamer X in an upcoming release.

For OneLens users

• Added Quantity (total capacity) to the monthly space utilisation summary on the Booking Analytics page.
• Space booking records have the Space_Name & Space_Name_Label fields populated from the specified space records not the booking record.
• Added validation for the ticketed event ID passed in the update payload.
• Updated validations on the endpoints:
  • POST/PUT/PATCH /v2/{nodeid}/catering-restriction/{cateringRestrictionId}:
    • Node ID can only be of type Building
    • Section can only be 1 of 2 string values - 'Dietary' or ‘Allergen’
    • Image URL is a valid URL
  • POST/PUT/PATCH /v2/{nodeid}/catering-order-policy/{cateringOrderPolicyId}:
    • Node ID can only be of type Building
    • Kitchen_OperatingHours_Start & Kitchen_OperatingHours_Stop must both be in HH:MM format (for example 09:30)
    • Kitchen_OperatingHours_Start cannot be a time later than Kitchen_OperatingHours_Stop

For Admin users

• We are gradually moving our products to a new look and feel as well as reorganise pages structure for improved user experience and clearer logic.
  As the first step to it, we’ve redirected a few Setup admin pages to a new location. Relevant users will see the redirect link on these pages.

For API users

• The Bookings PUT/PATCH functionality has been updated to create a visit record when Visitor Pass is updated from 0 to 1 and cancel the visit record when Visitor Pass is updated from 1 to 0.
• Removed the name uniqueness of the Nodes object. Currently the name has to be unique across the board, instead it should only the combination of Node_Id & Nodes name that have to be unique.
• Standard deployment now automatically has types and fields created to reduce errors during deployment.
• When creating a new tenancy, a native identity provider, native admin user, and native admin role are created automatically.
• Enabled importing of information against a floor using POST /v2/core/{tenancy}/nodes/{nodeid}/import.
• Prevent duplicate Ontology Names being used within the same tenancy.
• Added PATCH endpoint /v2/security/{tenancy}/users/{userid} to allow the user to update preferred name, user initials, and a combination of both.

What's fixed

Bookings

• Corrected an error message to reference space class rather than space type when concurrent booking restrictions are applied.
• Fixed an issue where recurring bookings created with alternative spaces could result in booking occurrences being automatically cancelled by the system. Recurring bookings with alternative spaces are now created successfully and remain active as expected.
• Fixed an issue affecting pre-upgrade recurring bookings where bookings with null TeamId and TeamBookingId values were incorrectly displayed as team bookings. Team icons are now shown only for genuine team bookings.
• Fixed an issue where the Team Booking check-in button displayed a translation key instead of user-friendly text. Correct labels are now displayed in supported languages.
• Fixed an issue where the Meta_Loc_Zone value was not persisted when bookings were created using the v2 Bookings POST endpoint. Zone information is now correctly saved and updated, allowing zone-based filtering, reporting, and exports to return accurate results.
• Fixed an issue where cancelling a booking via the API did not set the Booking_IsActive field to 0. Cancelled bookings are now correctly marked as inactive, preventing subsequent processes from treating them as active bookings.
• Fixed an issue where the Spaces Schedule Zone filter used translated values rather than the expected system value when running in German. Selecting Beliebig now correctly applies the Any filter.

Spaces

• Fixed an issue where spaces could remain stuck in the In-Use state after booking completion.
• Fixed a webjob issue preventing space transitions to the Checked-In state.

Visitors

• On Visitor Analytics, we've fixed Visits Summary durations being reported in seconds instead of minutes.
• On Visitor Analytics, we've fixed an issue where no-show visitor records were excluded from Visits Summary calculations. Visitor Analytics now correctly calculate expected visitors, attended visitors, no-shows, and attendance percentages.
• Fixed Visitor Pass printing not correctly applying the configured badge template.
• Fixed an issue where visitors imported using the Visits Import endpoint were not automatically approved when the building approval setting (Vis_Req_Approval) was disabled. Imported visitors now correctly receive approved status, approval flags, and approval timestamps, allowing them to be checked in successfully without requiring manual approval.

Team Management

• Added validation to prevent Teams being created with unsupported non-English characters.

Monitoring & Reliability

• Improved API startup resilience with additional health checks and initialization validation for core services.

Diagnostic Improvements

• Added additional logging around space state transitions and occupancy processing to assist with diagnosing intermittent space synchronisation issues observed in customer environments.

Catering

• We've removed the “Deleted” field from the POST /v2/{nodeid}/catering-templates endpoint. This field is included only in PUT and PATCH endpoints.
• Export requests are now successful for Catering Suppliers.
• We've corrected the following validations when creating and updating catering orders:
  • Menu_Item_Id
  • Cost_Code_Allocation
  • Catering_Total_Value
  • Catering_Service_Time
  • Catering_Cleaning_Time
• Fixed validation of the ImageURI Value for Catering Menus POST/PUT/PATCH calls.

Bookings

• Bookings now correctly stay in the Completed status after checking out and they don't transition to No Show any more after this.
• Fixed adding attendees to a booking. Previously the space required an event created to accept attendees.
• Fixed the issue when a booking is updated, associated catering orders went back to the Pending Approval status. Now catering orders retain their status when the booking is updated.
• When importing attendees, the capacity check doesn't count the Is_Remote = 1 field any more.
• Fixed updating the Booking Spaces record when the space is moved within one floor when the node ID is not changing but the space ID does.
• Fixed updating a booking owner when the ProcessBookingParties = false.
• Fixed the PUT /v2/{nodeid}/bookings/{bookingid} endpoint for users to update Setup/Reset booking slots.
• Setup/Reset booking slots are auto cancelled as they should along with their main booking.
• User is now able to checkout of a Linked Space booking, it doesn't return Code 500, and the Booking Status is correctly changing to Completed.
• We've fixed the SearchForDuplicatesIn parameter in the payload of POST /v2/{nodeId}/bookings to validate against the region Node ID to ensure that users without the permission to book unlimited spaces of the same space type correctly book just one space at a time across their assigned region, not one building as it was before.
• When an attendee number was changed in a booking with an automated catering order, the number of menu items didn't change accordingly. We've fixed this for  /v2/{nodeid}/bookingparties/ endpoints. 
• For bookings of linked spaces where one of the spaces has automated catering orders set up, these catering orders are now created with no issue.
• For linked space bookings the auto check-in didn't work for both spaces. Now both spaces correctly update states and contain booking data.
• Approving and denying Bookings using /v2/{nodeid}/bookings/{bookingid}/deny or /v2/{nodeid}/bookings/{bookingid}/approve no longer updates the Booking Start and End fields to null. The fields remain unchanged as expected.

Resources

• Status of the resource returns to available after it has been removed from the booking and can be added again.
• Resource duplicates are not created any more after they were added to the booking.

Other fixes

• Corrected calculations for Occupancy, Utilisation, and PeakOccupancy in the following call: /v2/spaces-summary/daily/
• The ConcurrencyStamp error is resolved in the PUT call on Admin Portal > Spaces page.
• As part of the ongoing work, we've updated error messages in a couple of places to add meaningful details. For example, API returns a better error in the following scenarios:
  • When there's a conflict during a task update
  • When a user tries to check in to the space with the incorrect PIN
• When using /v2/nodeid/ticketedevents/participants/import to import event participants, the system used to return a 500 Internal Server error. It's resolved now.
• Fixed both /v2/{nodeid}/visits/import and /v2/{nodeid}/visits to create the Visit Record with the Visit_Host_Email as lower case. Previously upper case letters were saved.
• We've added the Space_Clean_Status field to the SpacesConfiguration entity for the values to be accepted during import.

Known issues

Catering

• When a booking is moved to a new floor and a new space where the automated catering order is set up, the automated catering order fails to create. In this scenario, catering orders have to be created manually.
• /v2/{nodeid}/catering-menu/{cateringMenuId} allows returning a menu with the different valid Node ID than the one linked to the catering menu.

Visitors

• VisitorTypeId isn't properly updating for Booking Parties record and Visit Record when booking attendees are added or removed.
• Creating a visit via /v2/{nodeid}/visits has the following issues (Note, these are only applicable if using the API directly, the user interface mitigates against these):
  • It does not populate space name if the Space ID is provided. Space Name remains empty. 
  • User is able to create a visit record without a Host Email / Name.
  • Visitor_Dietary_Pref and Visit_Save_Info fields are not validated or saved to visit record.
• Visitor File import does not create the Visit Records with a Populated Space_Id, Visitor Type, and PACS Id.

Other fixes

• /v2/configuration/{nodeid}/spaces/{spaceId} allows returning spaces with the wrong Node ID.
• /v2/{nodeid}/tag2eventtype - providing an OrderBy field is not sorting the response.
• /v1/Devices/{deviceId} doesn't update device's MAC address if it's empty.
• /v2/{nodeid}/shortcuts allows creating a shortcut with Start date after End Date.
• /v2/{nodeid}/bookings/{bookingid} does not update the Visit Host/Owner Details when the Booking Owner is updated.
• Success code is returned instead of an error in the following scenarios:
  • Creating a booking party with missing fields in /v2/{nodeid}/bookingparties returns code 200 instead of code 422.
  • POST /v2/Users/check-pin - null value or an empty string for PIN or invalid numeric UserName value do not return 422.
  • Executing PUT /v1/NotificationHubRegister/{id} and DELETE /v1/NotificationHubRegister/{id} with the invalid ID do not return the 404 error as expected. The response is either empty or code 200 with the Bad Request reason.
  • GET /v2/{nodeId}/visits-summary/daily/{startDate}/{endDate} - End Date before the Start Date returns Code 200 instead of Code 422.
  • POST /v2/{nodeid}/catering-order returns 201 instead of 422 Missing Status Code when Booking_Id does not exist.
  • POST /v2/{nodeid}/bookingparties - User can set Pass, IsRemote, IsParticipant_On_WaitingList, IsExternal all = 1 on Type 3 Party where it should have returned a 422 error.
• There's outstanding error responses standardisation across several endpoints to correct HTTP status codes.