Release notes

This page collects the capabilities delivered in 2026 Wave Three.

Three things characterise the wave. Field Execution can be adapted to a customer datamodel through configuration rather than development, including the customer-specific fields it inherits from NextGen FSM. Field work moves onto guided flows aligned with NextGen FSM, with a map that follows what the operator is doing. And the platform widens the range of infrastructure it can be installed and scaled on, from the runtime and the databases it supports to the event backbone it consumes.

Map and cartography

WMTS Support

NextGen Geo now supports OGC WMTS tiled map services, widening the range of cartographic sources that can be brought onto the map without an intermediate publishing step.

A WMTS service is added by URL, either its capabilities document or its base address. The system reads the capabilities, discovers the available layers, and makes them available in the Table of Contents, selecting a tile matrix set compatible with the coordinate system of the current map. Both the RESTful and the KVP styles are supported and are normally detected automatically, so in most cases the URL is the only thing an administrator has to provide.

Because a WMTS service can expose a large number of layers, the Table of Contents presents them as a single-choice list: one layer is displayed at a time, and selecting another one replaces it. Administrators can further shape the behaviour of a service, restricting which layers are offered, choosing which one opens by default, or forcing a specific tile matrix set, image format, or style.

This makes public and institutional tile providers directly usable — national geoportals, imagery archives, and similar sources — alongside the services already configured in the platform.

See: Configure WMTS services

Layer Labels

Labels become part of the configuration of a service instead of a choice each user makes again on every session.

An administrator states, per layer, which attribute is drawn as its label and how the label looks: text colour and size, and an optional background box with its own fill colour, border colour, and border thickness. A layer configured this way opens the label tool already filled in, so users display meaningful labels with one click rather than picking an attribute from a list of technical column names.

The default appearance of labels has also been reworked. Labels are drawn in the font of the interface theme, so they match the rest of the application, and two intensity sliders set how opaque the background box and its border are — from a solid box down to text floating over the cartography. Labels configured before this release keep the appearance they had.

See: Configure default layer labels

Layer Carousel

The Layer Carousel turns a service or group containing several layers into a sequence that plays automatically on the map, showing one layer at a time.

Starting the carousel from the Table of Contents context menu displays the first available layer, then replaces it with the next one after a few seconds, and continues until the last layer is reached. Only one layer is visible at any moment, so the effect is a slideshow rather than an overlay. Playback can be paused and resumed from the current position, and the menu entry reports the progress while it runs.

The capability is most valuable on chronological content — historical imagery, periodically updated datasets, any series where the interesting information is the difference between one layer and the next. Instead of toggling layers by hand to compare them, users watch the sequence.

The carousel works on any service or node that contains sub-layers, and it is a configurable tool: an administrator enables it and positions it in the Table of Contents context menu through the toolbar configuration.

See: Cycle layers with Layer Carousel

Spatial Analyst

The new Spatial Analyst widget answers questions that involve two layers at once: which features of one layer stand in a given spatial relationship with the features of another.

The user picks the layer to analyze, the layer to compare it with, and the rule between them — intersects, contains, or is contained — optionally adding a tolerance in meters to include nearby features, and optionally restricting the analysis to the visible map area. A summary sentence describes what is about to be executed, so the configuration can be verified before starting.

The analysis runs on the server and leaves the map usable while it proceeds. On completion, a notification reports how many features matched, and the attribute table of the analyzed layer opens already filtered to the matching records, with paging set so the whole result set is immediately visible. When nothing matches, the user is told and no table is opened.

Typical uses are operational rather than exploratory: finding the technical objects inside a set of selected zones, or the assets that intersect a portion of network. The widget works on platform layers and on external ArcGIS feature layers, in both single-map and dual-map layouts, and replaces the previous spatial analysis tool.

See: Perform spatial analysis with Spatial Analyst

Thematic Map Management

Thematic maps become a shared asset rather than a personal one, and they now govern clustering as well as symbology.

A thematic map can be marked as public, which makes it available to every user with access to the service instead of only to the person who created it, and new thematic maps are public by default. One thematic map per service can be marked as the default, and it is then applied automatically when the service is loaded, with no manual selection. A symbology built once by one person is therefore immediately useful to the whole team, and the representation that matters for a service no longer has to be chosen by hand every time.

Clustering has also moved inside the thematic map. Previously it was fixed when the service was loaded, which meant that applying another representation to a clustered layer left the grouping in place, interfering with the new one — a heatmap over a clustered layer kept showing clusters. A thematic map can now define symbology, clustering, or both, and switching leaves the map in a consistent state: clustering is applied when the thematic map includes it, removed when it does not, and cleared when the default representation is restored. On a feature service, a clustering configuration can target a single sublayer.

See: Manage thematic maps

Field Execution

Custom Fields in Field Execution

Field Execution can now work with the fields a customer actually uses, not only the ones the product ships with.

Customer-specific fields defined in NextGen FSM are imported into NextGen Geo together with their structure, and from that point on they behave like any other attribute: they are stored natively, queried by the search engine, and displayed in popups and information panels without custom development. Adding a field to a customer datamodel no longer requires a database change for every new information need: the field is declared once, centrally, and the platform carries it through persistence, search, and presentation. A dedicated schema service distributes the resulting datamodel to the parts of the application that need to know it.

The interface of the module is composed from that same declaration. Three areas of Field Execution — the search filters, the list of columns, and the detail view — are driven by a configuration that states which fields appear, in which order, and under which label, with labels taken from the platform dictionaries rather than from technical column names. Standard fields and customer fields are declared the same way, so a deployment can present the terminology and the information set of the customer instead of the default ones, and a layout can be arranged over the number of columns that suits the content.

The result is that adapting the module to a customer datamodel becomes a configuration activity instead of a development one, and the adaptation survives upgrades because nothing in the standard product is modified.

See: Configure the Field Execution module

Work Order Creation Wizard

Creating a work order from the map is now a guided, multi-step process, replacing the single form used before.

The wizard opens on the selection of the technical object: a spatial search on the technical objects layer returns the candidates in the area, which can be inspected and located on the map before exactly one is chosen. The work order details follow, with the selected object shown read-only, and then the operations, presented one at a time as cards that can be added, navigated with a dropdown or with previous and next controls, and deleted with a confirmation. Deleting the only remaining operation clears its fields rather than leaving the work order without any.

Everything entered is preserved while moving between the steps, and nothing is sent to NextGen FSM until the whole work order is valid. Saving validates the work order and every operation together and persists them as a single unit, so a partial or inconsistent work order is never created; closing the wizard with unsaved data asks for confirmation and leaves no draft behind.

See: Create a work order from the map , Manage entity metadata

Field Execution and the Map

The Field Execution module and the map now share the same operational context, so the geographic picture follows what the user is doing in the panel.

Changing the filters of the work order list updates what the map shows; selecting a work order highlights it; opening its details filters the map down to that work order alone, leaving out everything not relevant to it; selecting an operation or an associated technical object highlights that element. Going back to the list restores the full representation. Elements without a geometry are handled without errors: their data stays available and the absence of a location is reported instead of failing.

The cartographic focus has moved from the work order to the individual operations. The operations layer is the one displayed by default, styled by status so the state of the field activities is readable at a glance, with cluster, by-status and heatmap representations available and clustering applied by default to keep dense areas legible. Technical objects are styled by type and drawn below the operations. The legend in the module reflects the symbology currently on the map and follows the context as the user moves between the list and a single work order.

See: View work orders and technical objects on the map , Access work order data and components

Field Execution Availability and Initial Filters

Two changes make the Field Execution module predictable when its data is not in a usable state, and quicker to get into when it is.

The module now reacts to the state of the last work order import. While an import is running, opening the module asks for an explicit confirmation and then keeps a banner visible: the data can be browsed and inspected, but creating a work order is not available, so nothing is planned against a dataset that is still being loaded. If the last import failed, the module cannot be opened at all rather than exposing an incomplete cache, and access is restored automatically once the import completes successfully. A module whose data has never been imported points the administrator to its configuration.

Administrators can also define the filters applied when the module opens — a creation date range and a set of work order statuses — so users start from the subset that matters to them instead of the whole imported dataset. These filters are a starting state, not a constraint: users can change or clear them at any time. They are validated against the import scope, because filtering on data that was never imported would leave the module empty, and they are cleared if the import constraints change.

See: Open the module during a data import , Configure the Field Execution module

Work Order Import Reliability

The import of work orders from NextGen FSM has been reworked to survive interruptions and to be observable while it runs.

The dataset is now processed in pages, each one in its own transaction and in a stable chronological order. Every page that completes is saved before the next one starts, so a problem partway through does not undo the work already done. A record that fails validation is logged and reported in the summary, and the import continues; a blocking technical failure stops the task and leaves it in a state from which it can be resumed.

Progress is visible in Task Monitoring, which reports the page currently being processed and updates as the import advances. An administrator can stop a running import, in which case the page in progress is rolled back and the earlier ones are kept. In every case — a manual stop, a technical error, or a system going down — triggering the task again resumes from the page after the last successful one instead of starting over, and a completed task is never restarted. When the import finishes, a summary report shows the pages processed, those that failed, and the reason for each failure.

See: Monitor tasks

Configuration and everyday use

Module Management Experience

The window through which users open and switch modules has been reworked, and the windows anchored to the right edge of the map no longer hide what the map is trying to show.

Windows docked to the right edge now declare the strip of screen they occupy, so every centering operation — zoom to a feature, zoom to an extent, centering from a search result or from a list inside a module — places its target in the visible part of the map instead of behind the window. The map controls that sit on the right side are repositioned inside the visible area as well. A pin control in the header shows whether the window is docked and releases it with one click, and dragging a window away from the edge releases it automatically. The behaviour is shared by the Module management window, the Editor control center, and Documents.

The Module management window itself is denser and easier to navigate. A module switcher in the header replaces the static title, listing the full catalogue plus every module currently open, and each open module can be closed directly from that dropdown. Modules are listed one per row, grouped by tag, with a badge marking the one currently active; the search field stays always visible while the additional filters collapse behind a Filters button. Multi-select fields across the application now show a counter for the selections that do not fit in the field, so the size of a selection is readable without opening the dropdown.

See: Modules

Interface Density and Notifications

Two changes address how much information fits on screen and how the application reports what it is doing.

Users can select the visual density of the desktop interface from their own preferences, choosing between a compact arrangement that fits more rows and controls into the same space and a more spacious one, with the choice persisted across sessions. Operators who spend the day on dense lists and control rooms working on large displays no longer have to share a single compromise. Alongside this, wasted space inside module windows has been reduced and the date range control has been made compact, so the same panel shows more of its content.

Notifications now handle messages that do not fit on one line, stay on screen until dismissed when they carry something the user has to act on, and group repeated messages instead of stacking them. A long validation message or a series of identical warnings is readable rather than truncated or overwhelming.

Finally, a service in use by an open module can no longer be removed from the Table of Contents, so a module cannot lose the layers it depends on while it is running.

See: Account section

Dashboard Filtering by Map Extent

A dashboard chart can now be restricted to the area the user is looking at, so the dashboard answers what is in view rather than what is in the whole dataset.

An administrator enables the extent filter on the chart and selects the geometry column the filter has to use. Only geometry columns are offered, and the column is required once the filter is enabled, so the misconfiguration of filtering by extent without a geometry cannot be saved.

Once configured, the chart reloads every time the map settles after a pan or a zoom and shows only the records whose geometry intersects the visible area. The filter is applied on the selected column by the back end, so it works with the supported database connections and with REST services alike.

See: Create and update dashboard configurations

Report Scrolling and Dashboard Layout

Two changes make tabular reports and dashboards behave predictably whatever their size.

Report tables no longer page through their results. The table fetches records as the user scrolls and keeps only what is needed around the visible rows, so a report returning a large number of records opens as quickly as a short one and is browsed with the scrollbar alone, without the memory of the browser growing with the size of the result.

Dashboards lay their charts out over the space the window actually offers. Charts flow onto as many rows as they need and follow the window as it is resized, so the same dashboard is readable on a large display and inside a module window docked beside the map, with nothing to configure about position or size.

See: About Report module, Dashboard configuration

Extending the Field Execution module

The Field Execution module can now be adapted by the code a partner deploys alongside the product, without modifying it.

Custom code adds its own buttons to the main toolbar of the work order list, adds tabs to the work order detail — or replaces the standard ones — and hides the parts of the interface a deployment does not use, such as the creation of work orders in an installation where work orders only come from NextGen FSM. In the other direction, the module announces what the user is doing: which work order has been opened, which row has been clicked. Custom code can also drive the module, opening a work order or returning to the list, so that an action started elsewhere in the application ends where it belongs.

Each configuration can target a single module instance or every Field Execution module of the installation. Because the extension happens through events and nothing in the standard product is modified, an upgrade does not require re-applying custom changes.

See: Extend the Field Execution module

Platform and deployment

GeoSmartOperation

GeoSmartOperation gains the properties it needs to be deployed at scale and extended without custom builds.

Query results can now be served in a compact binary format alongside the standard JSON response. The same features travel in significantly fewer bytes, which shortens the wait exactly where it hurts — panning across a dense area, opening a layer with thousands of features, working over a slow connection — with no change for the user and nothing to configure. Recent results are also kept in a shared cache whose validity is decided per layer, so repeated navigation over the same area is served without querying the source database again, and layers can be tuned according to how often their data actually changes.

The component can be deployed as several instances behind a load balancer and treated as a single service. The state of long-running operations is held centrally rather than inside the instance that started them, so any instance can report on any operation: capacity is added by adding instances, and losing one does not lose the work already completed.

New spatial operations and new layers can be added by installing a package, without modifying the standard product. An operation added this way is listed, started, and monitored like a built-in one; a layer added this way is discoverable and queryable like a standard one. Definitions are validated at startup and conflicts are reported explicitly, and extensions run under the same authentication and visibility rules as the rest of the component. Because the core is never modified, an upgrade does not require re-applying custom changes.

Finally, the fields exposed by a GeoSmartOperation layer can carry aliases, so the technical column names of the source system are replaced by the terminology the customer actually uses, with a fallback to the technical name where no alias is defined.

See: Understand GeoSmartOperation performance and scalability , Extend GeoSmartOperation , Understand and configure field aliases

Event Ingestion on Azure

NextGen Geo can consume events from Azure messaging, in addition to AWS SNS/SQS and Kafka.

The event source is selected through configuration, with no change to the application and no project-specific adapter: the payload format and the processing pipeline are identical whichever provider is in use, and existing AWS and Kafka installations are unaffected.

This removes the constraint that previously kept NextGen Geo out of on-premise and restricted-cloud environments where AWS is not available and Kafka is not part of the target architecture. An installation chooses the event infrastructure that fits the customer environment, rather than adapting the environment to the product.

Deprecations and removals