Xurrent ITSM - September 2026 Product Updates

This post is a living document, updated throughout the month as new product releases roll out. Each update listed here is released to our QA environment on the date shown and typically promoted to production the following week. Along the way, customers can review changes, share feedback, and help shape what ships next. Xurrent delivers product updates on a weekly cadence to keep enhancements moving continuously.

September 3, 2026

Shortcuts: Watch a Record with W

While looking at a record, a user presses W to start watching it, and presses it again to stop. The key does what the "Start watching" and "Stop watching" items of the watch menu do, without opening the menu, and it works both while a record is being read and while it is being edited. Watching is independent of the form, so the key never saves the record and never changes what is on the form.

The key is available to a user who has the personal preference "Use custom shortcuts" on, which is the preference every user starts with. It is listed in the keyboard shortcuts overlay that Shift+? opens, alongside the E key for the edit form.

The key stands down wherever acting on it would be wrong: while the cursor is in a field, so the letter can still be typed; while a menu, dialog or picker the user opened covers the record, the watch menu included; on an index view with several rows selected, where the watch button starts a mass action rather than a toggle; and where the record offers no watch button or offers one the user may not use. A record shown in a dialog, as an agile board shows one, is the record the key acts on, never the record on the page behind it.

The watch button announces the key to a screen reader only where the key works. It announces nothing in Self Service, where the key does not exist, nothing on a multiple-row selection, nothing where the user may not toggle watching the record, and nothing when the preference is off.

Reservations: The "On Update of Reservation" Trigger

Automation Rules gain the trigger "On update of reservation". A rule on this trigger fires when the start date, start time, end date, end time or reserved configuration item of an existing reservation changes, whoever makes the change and wherever they make it: the requester in the Self Service Portal, a specialist on the reservation edit page or from inside the request, or the API.

This closes a gap that made reservation automation unreliable. A schedule change reached the parent request, and therefore the automation on it, only when the person making the change was neither the reservation's owner nor its creator. A requester moving their own booking saved and displayed correctly while nothing downstream heard about it, so workflow tasks carrying the booking time held outdated values with nobody aware of it.

A rule on the trigger reads the reservation's new values through reservation and the values it held before the change through reservation_was, so a rule can report the move itself and write the new start time into a related workflow task.

Two points are worth knowing before an administrator builds on this. The trigger is offered on the Automation Rules of every request, because the trigger list is per record type rather than per category; it never fires on a request that has no reservation. And existing rules change no behavior: an owner-initiated date or time change is visible to automation only through the new trigger, so a rule on any update of the request does not start firing on edits it never saw before. Creating a reservation, and changing a provisional one, still fire nothing.

The person who makes a change is still not notified about their own edit. See Important Messages for the effect an owner-initiated reschedule now has on the request's Updated timestamp and its update webhook event.

Task Templates: Auto-Assign Across a Team

A task template gains an "Auto-assign" checkbox. When it is checked, a task created from that template is assigned to an available member of its team at the moment the task would otherwise wait for assignment with no member, which is when its predecessors finish and the workflow sets it to "Assigned".

The member is selected on the basis requests already use: members who are out of office or set to do not disturb are skipped, working hours are respected, the member who last held the task is avoided, the available member with the fewest open items in their inbox is preferred, and assignments rotate across members whose workload is equal. Where no member of the team is available the task stays unassigned rather than going to someone who is not there. A system note on the task names the member that was selected.

The checkbox is offered on an Implementation task template when a team is selected, no member is selected and no dynamic assign-to option is checked, and it is cleared when any of those stops being true, on the same basis the template already clears the team and member fields. It defaults to unchecked, so every existing task template behaves as it does today.

The Auto-assign box on the Team record is unchanged and continues to govern requests only. Checking or clearing it changes no task behavior. A team that wants its tasks distributed leaves the Member field empty on the template and checks the box there.

Self Service: Reserve Without Leaving the Calendar

Selecting a slot on the Self Service reservation calendar opens the booking form in a dialog over the calendar, so the calendar the slot was chosen on is still visible behind it and reconsidering the slot costs nothing.

The form groups its fields under two headings, "Request Information" carrying "Requested for", "Service instance" and "Subject", and "Reservation Details" carrying the reserved item, "Start", "End", "Repeats" and "Description". The reserved item is read only, with helper text saying it came from the calendar selection: changing it means returning to the calendar, which is the only place its availability is known.

The offering's rules are now reported while a person types rather than on save. A duration that is not the offering's minimum plus a whole number of step durations, or that exceeds the offering's maximum, is reported inline with the permitted increments or the maximum stated. A start or end outside the offering's operating hours is reported with the nearest valid time. One message covers both, positioned with the "End" pair rather than repeated across four inputs. The date pickers no longer offer days the offering's calendar and maximum duration disallow, up to a year ahead.

Times render in the requested-for person's timezone and that timezone is labeled, matching the calendar cell the slot was chosen on. Where the offering's timezone differs, it is shown alongside.

"Cancel" leaves the person on the calendar without creating a request, releases the held slot straight away rather than leaving it standing until the provisional sweep reaches it, and asks first when there is entered content to lose. "Submit Request" creates the request, confirms the reservation, assigns it to the offering's fulfillment team and opens the request. A slot taken between selection and submit is refused with the conflict stated, returning the person to the calendar with what they typed still in the form.

Settings: Product Custom Fields

A new "Product Custom Fields" section in Settings lists every custom field the account's product UI extensions define, once, with its ID, its name, its value type, the number of products using it and whether the extensions that define it disagree.

Each product can carry its own product UI extension, so a mature CMDB account holds hundreds of them, authored at different times by different people. Until now the only answerable question was which custom fields one product has, never which fields the account already uses, and the result is drift: firmware_version, firmware_ver and fw_version living side by side, invisible until someone tries to report across them. The section names two kinds of disagreement directly. A field whose value type differs between the extensions defining it is flagged as a type conflict and reports no single value type. A field whose name differs between them is flagged as a naming inconsistency.

Fields from both the active and the being-prepared version of an extension are listed, so a field counts as soon as a designer has drafted it. Where both versions define the same ID, the active version decides its type, because that is what the configuration items carry. Attachment, suggest and location fields appear with no value type, since the UI extension field type has no value-type equivalent. The list is read only; to change a field, an administrator opens the UI extension that defines it.

The section is available to a Configuration Manager, an Account Administrator, an Account Designer and an Auditor, on support domain accounts above the basic plan.

Locations: Accented Names Keep Their Accents

A Location saved with an accented name keeps that name. Where an account already holds Munster and a record is saved with Münster, the two are now separate Locations rather than the second collapsing silently into the first.

The old behavior was decided by whichever spelling reached the account first, in either direction, and it was not limited to German umlauts: Pérbig collapsed into Perbig the same way. The save reported success, nothing appeared in the import log and no message appeared on screen, so a customer with two different towns, such as 29633 Munster (Niedersachsen) and 48143 Münster (Westfalen), could not represent both. A nightly integration writing the correct value showed the field being set back on every run.

Names that differ only by capitalization still share one Location. Munster and munster remain a single entry, which is intended and unchanged. The same treatment applies to Product Brand and to Project Program, which use the same name lookup, and the behavior is identical through the user interface, a CSV import and the API.

Records that were already merged keep the merged name. The change stops the loss from happening again. See Important Messages for the effects this has beyond accents.

Reports: Monthly AI Usage and Corrected Totals

AI usage is recorded once per calendar month, and the AI Usage report's date filter now matches that. "Quick Ranges" offers month, quarter and year based ranges, and the "Custom Range" interval dropdown offers Month and Quarter. Quick ranges phrased as "X to date" are labeled "current X" on this report. Day and week based ranges are removed; a saved link or API call that still requests one resolves to a monthly interval. No other report's date filter changes.

Previously, a range shorter than a month could show no data, and a month-aligned range charted at a daily or weekly interval showed the whole month's total as a spike on the 1st.

The report's totals are also corrected. The nightly job that records non-Sentiment AI usage left stale data behind on each run, which inflated totals over time. A daily reconciliation now removes it, and a one-off repair is available for the months already affected. See Important Messages for the effect on totals already reported.

AI: Sentiment Follows the Enabling Accounts

Sentiment analysis usage is now attributed to every account that participates in a request and has "AI Sentiment" enabled. Accounts with the feature off are not attributed, including the account that owns the request. In service provider setups, a provider with the feature on now receives sentiment on the requests its customers assign to it, regardless of the owning account's setting.

Previously, attribution followed the owning account. A customer with "AI Sentiment" off could appear in the AI Usage report as using it when a provider analyzed its requests, while the provider that enabled the feature showed no usage.

The AI Usage report now shows a sentiment entry only for accounts that currently have "AI Sentiment" enabled. Earlier entries are kept, not deleted, and reappear if the feature is switched back on. See Important Messages for how per-account figures change.

The request page also now labels a sentiment explanation with the language it was generated in, the owning account's language, so a specialist viewing a request owned by an account in another language is offered a translation. Previously the label used the viewing account's language and no translation was offered.

Sera AI: One Switch for AI, One for the Chat

A few weeks ago we described the settings rework. This release finishes that work. "Sera AI" is now the single setting that turns AI on or off for an account, honored on every path. "Enable Virtual Agent" governs exactly one thing: the Self Service chat widget.

Until now "Enable Virtual Agent" reached well beyond the chat. It was checked before the Sera AI Studio would open, before an AI caller could reach the conversation API, before the tools that file a request would accept one, when choosing which support domain fulfils a request filed by AI, and by Sera Assist, which involves no chat at all. The Studio has grown the Golden Set, agent instructions, template readiness and knowledge article readiness, none of which involve the chat. Through the API with the chat off, a caller could update a request, post notes, search and read records, but not create one.

For an account with "Sera AI" on and the chat off, the Studio and every tab inside it now open, MS Teams and iPaaS conversations are answered, integrations can file requests, Sera Assist works, and the account is a valid support domain for a request filed by AI. A person no longer has to belong to a Self Service skill pool for AI to file a request on their behalf; skill pools continue to control who is offered the chat widget.

Nothing needs to change on your side for this release. If the Self Service chat showed "Sera AI not enabled for the account" after the settings changes a few weeks ago, that is the directory-account case described in "A brief note on AI settings," and the fix there still applies: the account owner turns "Sera AI" on for the directory account. The only addition here is that the chat now blocks at the entrance when either "Sera AI" or "Enable Virtual Agent" is off, including when the endpoint is called directly rather than through the rendered widget.

"Enable Virtual Agent" itself is unchanged. It stays on the Self Service Settings page and keeps its stored value when "Sera AI" is unchecked. No account with "Sera AI" on loses access on any channel. An administrator who switched the chat setting off in order to stop an MS Teams integration should revoke that integration's scope grant instead.

Request Templates: Fallback Limited to Sera AI

A request template designated as Sera's fallback in Sera AI Studio stops being something anyone can pick. It is withdrawn from the Self Service request catalog, category browse and the request template widgets on the Self Service home page, from Self Service global search and type-ahead, from agent global search, from the template picker on a new request and the browse-by-service panel, and from every path that returns request templates inside a Sera AI conversation.

The fallback template exists to catch conversations Sera cannot match, and it is built for that job: a store field, a note structure and downstream automation keyed to low-quality inbound questions. It is not a service the account offers, so a request created from it by hand carries none of the conversational context it was designed to hold, and putting a deliberately generic catch-all in the catalog takes users away from the specific template they would otherwise have found.

The one route that still works is a Sera AI conversation that could not match anything else, including when the conversation hands the requester into the full request form to finish a template it cannot complete in chat. That hand-off is authorized by the conversation itself, so copying, editing or constructing the link returns the standard not-available result rather than the form. A direct link or an existing short URL to the template's new request form returns the same result, for a specialist as well as an end user.

A designated template is now eligible as the fallback when it is active and covers the requester, independent of its "End users" and "Specialists" settings, so a template that is not available to end users at all can be designated and still works.

The template remains a record throughout. It stays in the Request Templates administration list, can be opened, edited, enabled, disabled and reported on, keeps its audit trail and its automation rules, and Sera AI Studio still offers it in the designation picker. Clearing the designation, or pointing it at a different template, restores it everywhere in the same save. See Important Messages for the effect on specialists who were applying the template and on existing links to it.

Sera Assist: Analytics Questions Carry Their Filters

Sera Assist in Analytics applies the conditions in a question to the report it opens. A user asking "open requests per team for the last 30 days" gets the matching report with the date filter set to the last 30 days, rather than the report's default view.

Previously the report opened in its default view and the conditions in the question were not applied.

Applied filters appear in the standard filter controls where they can be changed or cleared. A condition is applied only where it matches one of the filters the report declares; a condition the report cannot filter on is never applied and never turned into a query of its own. A filter value that resolves to no account data, such as a misspelled team name, or that resolves to more than one record, is named in the response rather than guessed at, and the report opens without that filter. Every condition that could not be applied is named alongside the opened report, so the user knows what the view does and does not reflect. A question with no conditions opens the report in its default view as before.