April 2026

Updates released in April 2026.

April 29, 2026

App Builder — generated apps always close Domain API transactions

• The ERP.net Domain API allows only one open transaction per session. If an app opened a transaction and an error happened before it closed, every later attempt to start a new transaction failed with "Maximum allowed transactions for this session have been reached" until the session expired — effectively breaking the app for the user. The App Builder is now explicitly instructed to (a) avoid transactions when a single write is enough, and (b) whenever a transaction IS used, wrap it in a try / catch / finally block that rolls it back on any error path. New apps generated by the App Builder will follow this pattern automatically; existing apps that show the symptom can be regenerated or patched in the App Builder to pick it up.

April 28, 2026

Business Specialist — full daily capability set now visible to all users

• Normal users opening Capabilities for the Business Specialist agent were only seeing 4 of its 10 capabilities (General Knowledge, Entity Schema, Email, Documentation). The other six — Query Data, Support Tickets, Calendar Management, Document Management, File Management, and Update Data — were hidden because their per-row level requirement was higher than a normal user's role level. These capabilities are part of the agent's intended default set and require an instance connection to do anything destructive, so the level gate has been removed. Business Specialist now shows all 10 included capabilities for every signed-in user.

April 28, 2026

App Sharing — clearer errors and stale-session recovery

• The "Share with Instances" form on an app's Share tab was failing for everyone except global admins with a misleading "Instance not found" error. The UI was reading the erpnet_instance_deployments table directly to resolve the UIN, but that table is locked down (it stores OAuth client secrets) so non-admin reads silently returned nothing. Resolution now goes through a security-definer helper that returns just the deployment id, so any signed-in user can share with any deployed instance whose UIN they know — secrets stay protected. The input field accepts mycompany, mycompany.my.erp.net, or https://mycompany.my.erp.net.
• Follow-up: when sharing failed for a different reason — typically an expired sign-in session — the form was still showing the same "Instance not found" toast. The form now refreshes the auth session before the lookup, surfaces the real lookup error if PostgREST rejects the call (e.g. "JWT expired"), and only shows "Instance not found" when the deployment genuinely isn't registered. The downstream insert into user_app_instance_shares also includes the underlying error message in its toast so RLS rejections are no longer silent.
• Follow-up 2: rows in the Share with Instances list were displaying the raw deployment GUID for non-admin users because the enrichment query also ran against the locked-down deployments table. The hostname (e.g. inko.my.erp.net) is now resolved through a second security-definer helper that returns only the public base URL, so every user sees the friendly instance name they shared with — no OAuth secrets exposed.

April 28, 2026

Manage Instance Users — instance admins now see real names and emails

• On /manage-instance-users, instance admins were seeing other connected users as "Unknown User" with no email. The connection rows were visible, but the linked profile data wasn't — so admins couldn't tell who they were assigning roles or policies to. Instance admins can now read the display name, email, and avatar of any user with a connection on an instance they administer. Visibility is scoped strictly to that instance's connected users; nothing else in the profile table becomes accessible.

April 28, 2026

App SDK — writable: true no longer blocked by deployment read-only flag

• The deployment-level read-only flag on instance deployments is for deployment protection (it locks OAuth credentials and blocks the install/uninstall webhook from overwriting the row). It is not a data-write gate. App-SDK conversations that ask for writable: true were incorrectly being demoted back to read-only when this flag was set, even though normal chat and automations on the same instance kept writing freely. That override is removed: writable: true now means write mode, with per-record authorization still enforced by the user's ERP permissions and any instance permission policies — exactly like normal chat.

April 28, 2026

App Builder — image attachments from apps now work (final fix)

• Earlier today's fix only corrected the path for new messages. Existing app-SDK messages still had type: "file" stored alongside an image MIME type, so the agent kept routing them to the unsupported text-extraction pipeline. The agent now also detects images by MIME type and filename extension, so JPG/PNG/WebP attachments always take the vision path regardless of the stored type field.
• When an app-SDK execution fails before producing any text, the proxy now returns the actual error string (e.g. unsupported file type) instead of an empty response, so apps can show a meaningful message instead of a silent blank.

April 28, 2026

App Builder — separate history tab for app-initiated conversations

• Conversations started by an app through the SDK no longer get mixed up with App Builder build conversations. Returning to an app on /app/:id now always reopens the build conversation, even if the app launched runtime conversations against the same app.
• The history sidebar gets a new App AI tab (sparkles icon) listing conversations started by an app via operator.ai.createConversation. App building conversations stay in the existing Apps tab.

April 28, 2026

App Builder — agents see attached files, and can opt into write mode

• When an app passes a file to an agent (via addMessage({ file })), the agent now actually sees the file content during the run — images, PDFs, spreadsheets, and the rest. Previously the agent ran blind even though the file was correctly stored on the user message.
• Conversations launched from an app are read-only by default. If your app needs the agent to create or update ERP records, just say so when describing the app (e.g. "the agent should be able to update records") — the App Builder will switch the conversation into write mode for you. Per-record authorization is still enforced by the user's ERP permissions and any instance permission policies.

April 28, 2026

App Builder — user agents now run with their own settings

• When an app launches a conversation with one of your own user-defined agents, the conversation now correctly inherits the agent's base persona, reasoning level, and capability list. Previously the conversation fell back to the Advisor base, which capped reasoning at "Fast" and hid the agent's data tools.
• Apps can still narrow an agent's capability list for a specific use case, but they can never widen it beyond what the agent itself is allowed to use.

April 28, 2026

App Builder — agents by name, no UUIDs

• When you tell the App Builder to use one of your own agents (or one shared with you), it now finds the agent by name and wires it into the app for you. End users of the app no longer need to type a "User Agent ID" or paste a UUID anywhere.
• Built-in agents (Advisor, Business Specialist, System Architect, Partner, Sales Executive) work the same way — just refer to them by name.
• If you mention an agent name the App Builder cannot find, it will ask you (the app author) to pick from the list — never the end user.

April 28, 2026

App Builder — your apps can now use AI

• When you describe an app, you can ask the App Builder to use AI as part of it. Two flavors are available:
  • Pure AI — fast, one-off thinking. Great for "classify this message", "summarize these notes", "extract the total from this invoice photo", or "translate this to French". You can choose how hard the AI thinks: Fastest, Fast, Smart, or Expert.
  • Full agent conversations — let your app run any Operator agent in the background, exactly like the assistant in the main chat. Pick a built-in agent (Advisor, Business Specialist, System Architect, Partner, Sales Executive) or one of your own user-defined agents, and optionally limit which capabilities it uses inside the app.
• Conversations started from an app appear in the user's normal chat history and run against the instance the user has selected in the toolbar.
• See the new AI in Apps help topic for examples of what to ask for.

April 28, 2026

Permission Policies — AI is warned about restrictions up-front

• When the AI looks up an entity (during normal data discovery), the response now includes the user's effective access — full, read-only, or none — based on the assigned permission policy. The AI uses this to warn you proactively before attempting a query that would be denied, and to avoid retrying similar lookups against entities outside your scope.

April 28, 2026

App Builder — self-service support policy documented

• The App Builder help now includes a Support Policy section. AI-generated apps follow a self-service model and are not covered by traditional support: you are responsible for testing, security configuration, and accepting the risks of AI-generated code. You always own the code and can export it.

April 28, 2026

New help topics: Permission Policies & Topic Guard

• Added a detailed Permission Policies guide for instance admins, covering the scope tree editor, Read vs Update access, the Allow off-topic switch, assigning policies to users, and how enforcement works alongside ERP.net's own security.
• Added a Topic Guard topic explaining how the setting keeps AI conversations focused on ERP.net work, and what the locked state means when a permission policy controls it.

April 28, 2026

Permission Policies — Allow off-topic conversations

• Each Permission Policy now has an Allow off-topic conversations switch above the scope tree.
• When disabled, users assigned to that policy can only discuss ERP.net and business topics — they won't be able to chat with the AI about unrelated things (e.g. the weather).
• For affected users, Settings → AI-enhanced → Topic guard is automatically turned on and locked, with a hint explaining that their instance admin controls it.

April 28, 2026

Permission Policies — visual tree editor

• The Policies editor in Manage Instance Users → Policies is now a single interactive tree of all ERP.net namespaces and entities.
• Tick any namespace to grant access to its entire subtree, or expand and pick individual entities. Mixed grants are shown with an indeterminate state.
• Pick Read or Update per branch (Update covers create, update and delete). Search filters the tree and auto-expands matches.
• Saving a policy automatically collapses your selection to the smallest equivalent set of scope entries (e.g. a fully-ticked Crm branch becomes a single Crm.* entry).

April 28, 2026

Permission Policies for instance users

• Instance admins can now define Permission Policies in Manage Instance Users → Policies and assign one to each internal or client user.
• Each policy lists scopes (e.g. Crm.*, Logistics.Inventory.*, Finance.Accounting.Accounts) with Read or Update access (Update covers create, update and delete).
• Policies are enforced on top of ERP.net's own security: when an assigned user queries or modifies data, Operator checks the policy first and blocks operations on entities outside the granted scopes.
• Users without a policy keep unrestricted Operator-side access (ERP.net security still applies).
• Policy assignment changes are recorded in the instance Audit Log.

April 27, 2026

Code tab now visible to everyone in App Builder and Site Builder

• The Code tab is now available to all users in both the App Builder and Site Builder workspaces, regardless of role level. Previously it was restricted to developer-level accounts. Anyone with access to design an app or work on a site can now inspect the underlying code directly from the workspace.

April 26, 2026

Knowledge search now spans all of ERP.net documentation

• "Search documentation/knowledge" now searches the entire ERP.net knowledge corpus in a single call: official Technical, Developer, Presales, Web Client, and Windows Client documentation, the Zendesk knowledge base, system business rules, and every companion app's docs (Bank Sync, Operator, Retail POS, Retail POS Manager, VOX). Previously the assistant could miss articles that lived in the new product-documentation indexes — now they are ranked side-by-side with everything else.
• Ranking across all sources is now done in one pass with a unified relevance score, so the most relevant article wins regardless of which source it came from.

April 26, 2026

Better knowledge search for non-English questions

• The assistant now searches the English documentation and knowledge base more effectively regardless of the conversation language. When you ask a question in Bulgarian, German, or any other language, the assistant translates the search intent to English before querying — so full-text matching works as designed and you get relevant results instead of an empty response. ERP.net-specific identifiers (rule codes, entity names, error codes) are still passed through verbatim.

April 26, 2026

Continue now reliably picks up where the agent stopped

• Previously, after the platform paused a long App Builder run with the "Paused — Continue" prompt, hitting Continue could cause the agent to start reasoning from scratch instead of resuming the prior chain of thought. The first AI call after Continue is now correctly chained to the paused run's last response in every pause case (including platform CPU-time pauses), so the next turn carries the full reasoning context and you don't pay for redundant re-derivation.

In-progress assistant text now survives a paused build, even mid-stream

• Previously, when a long App Builder turn was paused by the platform mid-streaming (the "Paused — Continue" case), any text the assistant was currently streaming was lost on reload — the bubble came back empty even though you saw the words appear during the build. (A related fix on Apr 25 covered text from already-completed iterations; this one covers the iteration that was actively streaming when the pause hit.)
• The in-progress text is now persisted live as it streams, throttled so it doesn't add overhead to the build. Paused builds reload with everything you saw on screen, and Continue picks up cleanly from there.

April 25, 2026

More headroom for heavy agentic loops

• The per-turn time budget for an AI run is now 5 minutes (up from 4). Heavy agentic loops — many tool calls or large App Builder turns — were hitting the 4-minute ceiling and pausing for Continue when they were still actively making progress. The complementary upstream-silence guard was raised in lockstep to 5 minutes as well.

April 25, 2026

Long reasoning turns are no longer prematurely marked as Paused

• The system that detects stalled AI runs now waits 120 seconds of silence (up from 45) before flagging a run as paused. With the latest reasoning models, a single AI request can legitimately take 60–120 seconds to come back, and the previous threshold was misfiring on perfectly healthy long turns. Genuinely stuck runs are still detected automatically — just within ~2 minutes instead of ~45 seconds.

April 25, 2026

Assistant text no longer disappears on reload of a paused build

• When a long App Builder turn was killed mid-stream by the platform CPU limit (the "Paused — Continue" case), the assistant's explanatory text that had streamed visibly during the build was lost on reload — the bubble came back empty even though the file changes and tool-call breadcrumbs were intact. Root cause: the orchestrator only saved per-iteration text into the durable accumulator at the very end of a turn, so any iteration that mixed text + tool calls (the normal builder pattern) had its text dropped if the turn didn't reach the end. The text is now folded into the durable accumulator as soon as each iteration returns, so paused/killed turns reload with the full assistant message intact.
• Same fix incidentally repairs an older silent loss on successful turns: any text emitted in an iteration that also produced tool calls used to be dropped from the persisted message (only the final tool-free iteration's text was kept). All assistant text from the turn is now preserved.

April 25, 2026

Friendlier, action-oriented messages when a turn is interrupted

• Every interruption banner now tells you in plain language what happened and what to do next, instead of developer-flavored phrases like "server restarted mid-turn" or "isolate killed".
• The most common case — a long App Builder run hitting the platform's per-turn CPU limit — now consistently shows a neutral "Paused. This turn ran longer than the platform allows. Your progress is saved — click Continue (or type continue) to pick up where it stopped." banner with a one-click Continue button.
• Recoverable failures (AI service stopped responding, connection dropped, rate limited) get an amber "Try again" button. Informational failures (browser disconnected, save failed) explain what's intact and what to do next, without a misleading button.
• Conversation-list tooltips were rewritten to match — a quick scan of the icons now tells you which threads need a click and which are mid-thought.

Stalled builds recover within ~90 s instead of 3 min

• The background sweeper that flips abandoned builds from "Building app…" to a clear paused/failed state now runs with a 90-second cutoff (was 180 s) for every kind of conversation. The heartbeat-aware fast path still detects platform CPU kills within ~45 s and tags them as cpu_exceeded so the friendly Continue banner shows up immediately — no more waiting 3 minutes to know a turn died.

April 24, 2026

Long app builds no longer get killed mid-turn by the platform CPU limit

• Several pieces of recently-added background bookkeeping inside the orchestrator (per-event SSE trace inserts, repeated Supabase client construction, double-writing the assistant message every few seconds, JSON deep-cloning all 130+ tool schemas) were quietly piling up isolate CPU on long builder turns. Cumulatively they were the actual cause of the "server restarted mid-turn" failures around turn 12–15 — not the AI model or the tools themselves. Trimmed:
  • SSE trace logging is now off by default (still enabled per-deployment via SSE_TRACE_ENABLED=true for targeted diagnosis).
  • The mid-turn assistant-message checkpoint now only fires after a builder write tool (create_app, create_site, write_app_file, patch_app_file) — every other turn relies solely on the terminal end-of-turn write, eliminating 10–20 redundant row rewrites per long turn.
  • Status updates, response-id updates and trace inserts now reuse a single Supabase client per isolate instead of constructing a new one every call.
  • Tool definitions are no longer deep-cloned on every turn for strict-mode coercion.
• When the platform does still hit the CPU ceiling, the failed turn now shows a friendly "Build paused — type continue to keep going" banner with a one-click Continue button (same flow as the existing work-budget pause), instead of the cryptic "execution failed" badge.

April 24, 2026

App and site creation no longer fails on slug collisions

• App and site slugs are globally unique across the platform, so list_apps (which only sees the current user's apps) couldn't reliably prevent conflicts. The create_app and create_site tools now detect a unique-key collision server-side and automatically append the smallest free numeric suffix (-2, -3, …), retrying up to 5 times to absorb races. The result includes slug_adjusted: true and the original requested_slug, so the agent can mention the rename to the user — e.g. "created as 'sales-2' (the slug 'sales' was already taken)". No more wasted turns retrying with random suffixes.

April 24, 2026

Per-prompt work budget raised so app builds reach completion

• The orchestrator's per-prompt safety limits were tuned for short Q&A turns and were tripping during normal App Builder runs — often before create_app was even called. Limits raised to 30 turns, 30 file writes, 750 KB written, and 240 s wall time per prompt (from 12 / 10 / 250 KB / 90 s). The 240 s wall budget now matches the existing 4-minute inactivity watchdog. The graceful "say continue" pause still kicks in for genuinely oversized requests.

Earlier today

• Switching from /c/:id to /app/:id after create_app now happens as soon as the local stream finishes, instead of waiting on a slow background DB write.
• Long App Builder turns that hit the per-prompt work budget no longer occasionally lose the final summary message. Terminal writes are now synchronous, and a new final_persist_failed reason flips the row to failed immediately if persistence itself errors (instead of waiting 3 minutes for the stale-reaper).

Failed executions now explain why they failed

• When an execution flips to failed, the system now persists a structured failure reason (e.g. ws_inactivity_timeout, client_disconnected, openai_rate_limited, tool_loop_error) plus technical details. Hovering the red status icon in the conversation list now shows a friendly message — e.g. "Timed out — try a new conversation or lower reasoning level" — instead of the bare "Execution failed". This means post-mortems no longer depend on rotated edge-function logs.

April 23, 2026

App Builder now keeps a .memory/ notebook for each app

• The App Builder maintains a small set of Markdown notes inside each app under .memory/ (purpose, file roles, verified OData endpoints, design decisions, deferred items). The top-level .memory/index.md is loaded into the agent's context every turn — so follow-up questions like "what does kanban.js do?" or "where do we filter sales orders by date?" are answered from a 6 KB summary instead of re-reading the whole codebase. The folder shows up in the file tree as Memory at the bottom; you can inspect or edit any of the notes manually, or delete the folder entirely and the agent will rebuild it as it works.

Stuck-build recovery is now continuous (was every 15 minutes)

• A background sweeper now runs every minute and clears any build stuck for more than 3 minutes — including ones that were waiting on a tool confirmation. Previously this only ran every 15 minutes and ignored confirmation-pending builds.

Stuck builds now self-heal — no more 15-minute spinner lies

• If a build silently dies mid-stream (network drop, browser tab put to sleep, edge worker restart, OpenAI handshake failure), the conversation is now marked as failed instead of staying pinned at "Building app…" forever
• The preview now shows a Reset and try again button after 90 seconds with no progress, so you're never stuck staring at an indefinite loader
• Stale builds older than 3 minutes are auto-cleaned the next time the chat list loads or the window is refocused — old bricked conversations from before this fix will clear themselves automatically

April 22, 2026

App Builder — "New" button now reliably leaves the previous app

• Pressing New while inside an existing app no longer snaps the view back onto that app a moment later. Your next prompt now starts a clean Creator-mode conversation, and once the new app is built the URL, header and preview switch to the newly created app instead of staying stuck on the previous one
• Same fix applied to the Site Builder

April 22, 2026

App & Site Builder — no more accidental sibling projects

• Inside an existing app or site conversation, the agent can no longer call the create-new-project tool. The tool is filtered out of the model's tool list once the conversation is bound to an app_id (or site_id)
• This makes the "agent silently spawns a brand-new app while you're editing another one" mismatch structurally impossible — the URL, header, preview and conversation always stay aligned
• To start a brand-new app or site, open the agent menu and pick New to begin a fresh conversation

April 22, 2026

App Builder — small apps now finish in a single turn

• The App Builder no longer stops after the first file and asks you to reply continue for trivial apps (a form, a calculator, a single-purpose widget). Small apps are now built end-to-end in one turn
• Multi-turn pacing is reserved for genuinely large, multi-module apps where streaming the build over several turns produces a better UX and avoids response-size limits
• All hard safety caps (per-file size limits, per-prompt work budget) are unchanged — only the over-eager "stop after one file" behaviour was relaxed

April 22, 2026

Platform — legacy chat execution path retired

• All chats and automations now run on the unified WebSocket execution engine. The legacy HTTP fallback path has been removed
• The "WebSocket mode" toggle in Settings → Experimental has been removed — there is now a single, consistent execution engine for everyone
• No user action required; the change is fully transparent

April 22, 2026

Settings — new "Fresh context on each agent run" experimental option (default ON)

• Each new message you send now starts the agent's processing loop without re-attaching the previous AI response. This dramatically reduces token usage and AI credit cost on long conversations, where the silent re-loading of the prior response chain was the main source of bloat
• Tool-call turns within the same run (turn 2, 3, …) still chain efficiently — only the first turn of each new run is affected
• You can flip the option off in Settings → Experimental if you want the old behaviour where the model carries a long prior reasoning chain across separate messages
• App Builder and Site Builder always start fresh on every new run, regardless of this setting — these builders accumulate large code/page payloads, so re-attaching the prior response chain would explode token usage

April 22, 2026

App Builder — preview now shows live build progress instead of a frozen "Loading…" message

• Fixed an issue where, after creating a new app, the preview panel would display a static "Loading app preview…" message while the agent was still writing files in the background — making it look like nothing was happening when in fact the build was progressing
• The preview now shows a clear in-flight state during a build: "Building … 1m 12s · 4 tool calls" with a live elapsed timer, so you can see at a glance that work is happening
• The chat keeps showing the typing indicator and tool-use stream for the entire build (previously these signals could disappear partway through long builds)
• The preview lights up automatically the moment the first file is written — no manual refresh needed
• Empty apps opened directly now say "This app has no files yet." instead of the misleading loading message

April 22, 2026

Instance sessions — "Reconnect" prompt no longer appears when your session is actually fine

• Fixed an issue where the "Session expired" prompt could appear right after you reconnected an instance, even though valid tokens were already saved on the server. The chat now silently restores the session from the server before showing any prompt
• The Reconnect prompt now names the specific instance whose session needs attention — for example "Session expired for TESTDB (testdb.my.erp.net) — Reconnect TESTDB" — so you'll never wonder which connection it's referring to when you have several
• The check that decides whether to show the prompt is now strictly tied to the active connection in the selector, so reconnecting one instance never leaves a stale prompt up for a different one
• Apps using AI conversations: the conversation is now bound to the same instance you have selected in the toolbar at the moment the app calls operator.ai.createConversation(). Previously, an internal database flag could occasionally point the conversation at a different instance than the one you actually had selected. The flag has been removed; the toolbar selection is now the single source of truth

April 22, 2026

App Builder — large apps now build in bounded, resumable chunks

• The App Builder now follows an Incremental Build Protocol: skeleton-first, then one non-trivial file per turn — so very large "build the whole app" requests no longer stall mid-generation
• A per-prompt work budget (turns, file writes, bytes, wall-clock) ensures the assistant cleanly pauses instead of timing out when a request is too big to finish in one shot
• When the build pauses, you'll see a small "App build paused — type continue to keep building" hint with a one-click Continue button. Picking up where it left off is just one message away
• Per-file size cap (80 KB) is now enforced at the tool boundary — the assistant is forced to split oversized files into modules instead of failing silently

April 21, 2026

App Builder — Creator Mode no longer silently edits a different existing app

• Fixed an issue where starting a brand-new conversation in App Builder could result in the AI quietly amending one of your existing apps (whose purpose looked similar) instead of creating a new one
• New conversations are now strictly bound: file tools (write_app_file, patch_app_file, delete_app_file, get_app_file, list_app_files) only work after create_app has been called in the same conversation
• To edit an existing app, open it from /apps (or via the app selector) and continue the conversation from there

App Builder — "New" reliably leaves the current app

• Fixed an issue where pressing New while viewing an existing app would briefly clear the context and then snap back to the same app
• New now consistently returns you to Creator Mode (home URL, empty preview), so the next prompt creates a fresh app
• Typing in the chat while on an app's page continues to amend that app — unchanged

Reliability — App Builder no longer gets stuck after creating an app

• Fixed a class of silent hangs where the AI service would stop responding mid-conversation (most visible in App Builder right after create_app, before app files were written)
• The connection to the AI is now monitored with a 120-second inactivity watchdog and a periodic heartbeat
• If the AI goes silent or the connection drops, the request is automatically retried — and if it still fails, you now get a clear error instead of an indefinite spinner

April 13, 2026

Faster App Launching

• Opening an app now starts directly in Execute mode without first loading its design conversation
• The related design session is loaded only when you switch to Design, Code, Properties, or Deploy
• App execution now uses dedicated app routes for faster startup and cleaner app-specific URLs

April 11, 2026

App Builder — Build Custom ERP Data Apps with AI

Operator now includes a built-in App Builder — a fast, AI-assisted way to create small ERP data apps that integrate directly into the platform. Describe what you need in natural language, and the App Builder generates a working application connected to your ERP.net data via the Domain API.

Built apps can be deployed in multiple ways:

• Inside Operator — run apps directly within the Operator interface
• Full-screen — open any app in a dedicated full-screen view
• In the ERP.net Web Client — add apps as main menu items or embed them inside panels in other forms
• In the ERP.net Marketplace — publish apps for other ERP.net users to discover and install

Manage all your apps from the dedicated My Apps page — create new apps, resume design sessions, toggle visibility, or remove apps you no longer need.

April 8, 2026

Domain API Availability Check

• Auto-discovery on connection setup — when adding a new ERP.net instance, Operator now verifies that Domain API is activated before allowing the connection. If Domain API is missing, a clear error message explains the requirement.
• Post-authentication warning — after completing OAuth, Operator checks Domain API availability and warns if it's not activated, so you know immediately why features won't work.
• Better Enterprise Context errors — the Enterprise Company dialog now correctly detects when Domain API is missing (instead of showing an empty list) and advises contacting your ERP.net administrator.

April 5, 2026

More Reliable Session Recovery

• Single-flight token refresh — when multiple parts of the app detect an expired session simultaneously, only one refresh request is sent to the server, eliminating duplicate "invalid_grant" failures caused by token rotation races
• Reliable token persistence — rotated tokens are now durably written to the database before the UI continues, preventing stale credentials from being used on subsequent requests
• Accurate refresh token expiry — the system now tracks real server-provided refresh token lifetime instead of assuming a fixed 30-day window
• Precise connection identity — the app now distinguishes between different connection types (Internal vs. Client) for the same instance, preventing session mix-ups