Skip to content
Skip to main content
Novel Systems home
Release notes

Platform release notes & system changelog

Everything shipped since v2.0.0, in the order it shipped. Breaking changes are labelled as breaking rather than filed under “improvements,” and every deprecation names the release in which the old behaviour stops being served.

How we version

Two version numbers, and only one of them is a promise

A platform release number tells you how much moved. A dated API contract tells you whether your integration still works. Conflating the two is how vendors end up shipping a “minor” release that takes a customer’s ERP sync down on a Tuesday.

  • The platform version counts capability

    Major, minor, and patch describe how much of the product moved. They are a release label, not a compatibility promise — which is why a patch release can carry a new identity provider without that being a semantic-versioning violation.

  • The API version carries the compatibility promise

    Every request resolves against a dated contract sent as X-NS-Api-Version. A published contract keeps its exact response shape for 12 months after the day it is superseded, and breaking changes can only ever appear under a new date. Upgrading is therefore something you schedule, not something that happens to you.

  • Deprecations ship with a removal release, not a vague intent

    Nothing is deprecated here without a named release in which it stops being served, and that release is at least two minor versions out. If we cannot name the release, it is not deprecated yet.

Dated API contracts

  • 2026-07-01introduced in v2.4.0 · current, no retirement date
  • 2026-04-15introduced in v2.3.2 · served until July 1, 2027
  • 2026-01-20introduced in v2.2.0 · served until April 15, 2027
  • 2025-10-08introduced in v2.1.0 · served until January 20, 2027
  • 2025-06-03introduced in v2.0.0 · served until October 8, 2026

Send the contract you built against in X-NS-Api-Version. A contract is served for 12 months from the day it is superseded, so the retirement date only exists once a newer contract has actually shipped.

API reference
Open deadlines

What is currently scheduled to stop working

3 items are still served today and will be removed in a named release. This is the whole list — there is no second one held back for the account team.

Deprecated fields are served for at least two minor releases after the announcement, and the removal release is named on the day the deprecation is published. If a deadline lands badly against your own release calendar, raise it with support before the removal ships rather than after.

Reading this log

Six labels, each with a defined obligation

The label is not decoration. It states what an integrator has to do about the entry, which is the only reason to classify changes at all.

  • Breaking

    An integration built against the previous contract will fail until it is updated.

  • Deprecated

    Still served, with a published removal release. Migrate before that release ships.

  • Security

    A change to the security posture. No customer action unless the entry says so.

  • Added

    New capability. Opt-in unless the entry says otherwise.

  • Improved

    Existing behaviour got faster or better. Same contract, same call sites.

  • Fixed

    A defect that produced wrong output or wrong timing, and no longer does.

What this log does not contain

Patch builds, security backports, and infrastructure rollouts ship continuously and are announced in-app to the tenants they affect rather than listed here. A public log that tries to include every deployment stops being readable, and a changelog nobody reads protects nobody. Performance figures quoted in entries below come from our internal load harness on synthetic data, and are labelled as such where they appear.

The history

Every release, newest first

Filter by the part of the platform you integrate against, or narrow to the entries that actually require work from you.

Filter the history

26 entries across 5 releases

  1. v2.4.0

    MinorCurrent

    Convergence · July 1, 2026

    Offline edits now merge field-by-field instead of last-writer-wins, quote recalculation moved onto a precompiled deduction table, and the GraphQL schema opened up beyond the read-only preview.

    API contract
    2026-07-01
    Minimum tablet build
    2.4.112
    Released
    Jul 2026
    • ImprovedCPQ

      Sub-10 millisecond quote recalculation

      Deduction resolution moved from a per-line rule walk to a precompiled lookup table built when a price book is published. On our internal load harness a 40-line quote recalculates in 8.4 ms at the median and 12.1 ms at p95, against 68 ms and 141 ms on v2.3.2. These are harness numbers on synthetic quotes, not measurements from a customer tenant.

    • ImprovedMobile

      Conflict-free offline sync

      Two technicians editing the same work order in a dead zone used to resolve on reconnect by last-writer-wins, which silently discarded the earlier edit. Each field is now a conflict-free replicated register, so both edits survive and only genuinely contended fields raise a review flag. A 2,000-operation backlog converges in 1.9 s against 26 s previously.

    • AddedAPI

      GraphQL schema expansion

      The read-only preview became a supported surface: quote, quoteConnection, dispatch, and technician root fields, cursor pagination on every connection, persisted queries, and a per-tenant complexity budget so one deep query cannot starve the rest of the tenant.

    • AddedPlatform

      Audit ledger export

      Administrators can export the field-level audit ledger over any date range as CSV or JSONL, including margin-override reason codes. Exports are themselves audited, because an unlogged export of an audit log is a gap auditors ask about.

    • DeprecatedAPI

      Scalar lineItems[].deduction

      The scalar deduction value is replaced by an object carrying { value, unit, source }, because the scalar could not express which rule produced the number — the question every disputed quote eventually turns into. The scalar keeps being served alongside the object until v2.6.0.

    • AddedAPI

      Route responses name the constraint that excluded a technician

      Route and assignment responses carry a rejections array naming the technician, the job, and the specific constraint that ruled them out. Dispatchers stopped having to open a ticket to find out why a particular person was never offered the job.

    • FixedFMS

      Routes crossing the DST boundary

      Where a technician's device timezone differed from the tenant timezone, stops scheduled across the March transition were sequenced an hour early. Scheduling now resolves entirely in the tenant timezone and converts for display only.

    What you have to do

    • Move to the object form of lineItems[].deduction

      Removed in v2.6.0

      Read deduction.value instead of deduction. The unit and source fields are additive and can be ignored until you need them. Both shapes are served today.

    • Pin the API date header on GraphQL calls

      Send X-NS-Api-Version: 2026-07-01. Requests without the header resolve against the oldest contract your tenant has ever used, which is safe but will not expose the new root fields.

  2. v2.3.2

    Patch

    Directory · April 15, 2026

    Azure AD as a first-class identity provider, customer-branded quote documents, and a rotation change to the key hierarchy.

  3. v2.2.0

    MinorBreaking

    Wayfinder · January 20, 2026

    Dispatch stopped being a static plan. Routes re-sequence when a job overruns, technicians carry skill tags that assignment respects, and the dispatch payload was renamed to say what it means.

  4. v2.1.0

    Minor

    Ledger · October 8, 2025

    Price books became multi-currency, the margin floor became a governed policy rather than a hard-coded constant, and an intermediate rounding defect that shifted cut dimensions was corrected.

  5. v2.0.0

    Major

    General availability · June 3, 2025

    The first release available to customers outside Novel Blinds Inc. Everything before this ran as an internal division tool and is deliberately not in this log — it had one tenant, no contract, and no compatibility promise worth publishing.

Ahead of the release

Breaking changes reach you before they reach production

Tenants with an API key on file are notified at the point of announcement, not at the point of removal. Enterprise agreements add a sandbox tenant pinned one contract ahead, so your integration team can run the new shape against real fixtures before the date it becomes the default.

Webhook payloadsSupport & SLA

  • Release notice

    Announcement at least two minor releases before any removal, sent to the technical contact on the account.

  • Migration window

    Both shapes are served for the whole window. You migrate on your calendar, not on ours.

  • Questions on a specific entry

    Quote the version and the change title to support@novelsystems.ca and it routes to the team that shipped it.