Future concepts
Everything on this page is planned or conceptual unless a linked Technical contract explicitly says part of the foundation is already implemented.
Flow product integration
Section titled “Flow product integration”The typed engine, administration APIs, visual Studio, Scripts, Templates, Actions, sandbox, replay, and durable workers are implemented. Environment rollout remains gated. The next product step is shared context and navigation between these areas so that they read as one Flow workflow instead of separate automation products.
Raw storage remains independent. A transactional outbox created in the same database commit publishes a raw-stored event. The durable flow consumer loads the authoritative raw row, pins the active released flow version, and stores measurements idempotently before any action worker can run.
Repository-controlled TypeScript blocks are the default. A custom script may be released directly by its Platform-Admin author only after compile, manifest, forbidden-API, size, checksum, and sandbox-load gates pass. Fixture tests remain optional. The QuickJS/WASM boundary still needs its documented production security review and target-cluster proof before custom scripts can be enabled. Studio, Execution, and Dead Letter views should deep-link to the exact Flow version, node, template, recipient, and time context.
Customer telemetry
Section titled “Customer telemetry”The fixed one-Device dashboard and its bounded history endpoint are implemented. The view combines current values with 1-hour, 24-hour, 7-day, or 30-day history and preserves historical organization isolation. See Dashboards and Telemetry API v1.
Saved views, reusable dashboard configuration, cross-Device composition, and a free-form dashboard builder remain future concepts. Large requests will be directed to asynchronous exports instead of loading unbounded data in the browser.
CSV exports
Section titled “CSV exports”Exports will be asynchronous jobs so large time ranges do not block API requests. Creation, processing, status, authorized download, expiry, and audit will be separate steps.
Before implementation, the team must decide CSV columns, maximum range, file storage, retention, download expiry, and compression. Export authorization must be rechecked at download time and must never leak across tenant or organization boundaries. See the prepared Export contract.
Identity evolution
Section titled “Identity evolution”Local username/password sessions remain the implemented V1 identity model. Future tenant-specific OIDC and Microsoft Entra ID must map external identity to the existing platform user and database-authoritative roles without putting permissions into long-lived identity claims.
MFA, personal access tokens, service accounts, just-in-time provisioning, and support access require separate credential types, scope, revocation, and audit decisions.
Network Server synchronization
Section titled “Network Server synchronization”The current Netmore integration receives telemetry only. Later synchronization may cover devices, gateways, jobs, conflicts, and source-of-truth rules. Devices and gateways remain separate entities, and no Network Server topic or customer name may become tenant authority.
Operations beyond the first server
Section titled “Operations beyond the first server”Metrics, log aggregation, dashboards, alerting, public status, and SLO reports are implemented. Live target-cluster evidence, encrypted backup and isolated restore, load tests, and bounded query-performance evidence remain completion gates. High availability, multi-region, air-gapped installation, and advanced customer-owned on-premise operation are later capabilities. The current Helm and external configuration boundaries must avoid blocking them without introducing speculative topology now.