Reflow 2.0.0

Projects are a new way to store and organize content. One Reflow instance holds as many as you need, each with its own pages, branding, equipment and deployment lifecycle.

• Multiple projects on one station. Each project carries its entire configuration, so a single install can serve a campus, a tenant and a demonstration site at once. Projects can link to one another or stay completely separate, which makes it practical to tailor an experience per client without duplicating work.
• Draft and publish. You edit a draft, never the live site. Build and refine for as long as you like; nothing your users see changes until you publish. The confirmation that follows a publish carries a View Project button that opens what you just shipped.
• Several drafts at once. Create a draft empty, duplicated from the active one, or seeded from any other, then rename, switch and delete as you go. Each browser remembers the draft it was editing, so two people can work on separate drafts of the same project without colliding.
• Every project has its own web address. A project's pages sit under /reflow/p/<project>/, so a link to a particular page of a particular project can be bookmarked, shared, or pointed at from Reflow 1. A link made before a project was renamed still resolves.
• Export, import and backups. Any draft exports to a self-contained .rfdraft file and imports onto another station; projects export the same way, carrying their images and referenced files with them. Backups run on demand and nightly, and restore as a new draft, a new project, or over the current one.
• Licensing counts published projects. Draft projects do not count against your license, so you can build and hold as many as you like and choose which ones go live.

Station files are managed from the browser, with no Workbench round trip.

• Browse, upload and organize station files directly in the interface, including the images and documents your pages reference. A single file can be up to 150 MB and one upload can carry 500 MB in total, everywhere the application accepts a file: the File Manager, plugins, language extensions and licenses.

Access is granted per user and per role, and mapped onto the projects each person should see.

• Two levels of access. Reflow View Access lets someone use the projects assigned to them; Config View Access lets them create, manage and edit projects and project content. Either can be granted to a role or to an individual user.
• Per-project assignment. Assign specific projects to a role or a user, or grant access to the default project. A starting project decides what a person lands on when they open Reflow.
• Niagara permissions are respected. Access depends on the read and write category permissions the user or role already holds on the ReflowService in Niagara, so Reflow does not become a second place to manage who can do what.

Plugins extend Reflow with the capabilities a site actually needs, without adding weight for the sites that do not need them. First and third-party plugins both load as independent modules.

• The Plugin Gallery. The Plugins page carries a gallery of plugins published by NiagaraMods alongside the ones your station already has, with a Featured row and Browse by Category beneath it. Searching adds an Available in the Gallery section listing what you do not have yet.
• Details pages. Every gallery plugin has a page of its own with screenshots, an about section, a Key features list, and a sidebar carrying version, publisher and category. Its main action reads Install, Update or Installed depending on what the station has, and an installed plugin can be enabled, disabled or uninstalled from the same page.
• Per-project plugins. A project's own Plugins panel lists the installed plugins that carry per-project settings, so two projects on one station can run the same plugin configured differently. A plugin that cannot be switched off shows an Always on badge.
• The gallery speaks your language. Plugin descriptions, key features and category names follow the language set in Settings, re-reading live when you change it.

Data sources are the connections a project draws on, installed from one place.

• Install what the project needs. The Data Sources page manages the connections available to your projects: connectivity to the host Niagara 4 station, map tile data and rendering, and global weather data and maps.

Reflow runs in twenty languages, and both the application and the content you author can be localized.

• Two independent languages. The interface language and the content language are set separately, so an author can work in English while the published site reads in French.
• Automatic detection. Each user gets the language their browser asks for, where the project supports it.
• Language extensions install in the app. Additional languages are downloaded and installed from the Languages page rather than shipped in the build. Each carries its own icon: a rounded tile showing the language's abbreviation in its own script.
• Your content localizes too. Any text you author (a block title, a label, an equipment name) can carry a value per language, with a Translate action to fill in the rest from what you wrote. Dates, times and numbers follow the reader's locale.

A project's identity is set in one place and applies everywhere it is published.

• Logo & Hero. Upload a logo and a hero image, with separate light and dark variants and a mobile logo size.
• Colors. Set brand, surface, content, menu and tooltip colors for light and dark mode. Primary Text and Secondary Text control what is drawn on top of your brand colors, and Reflow checks a pairing for legibility and offers a more readable alternative when one exists.
• Dynamic colors. A color can be driven by a value rather than fixed: map a range onto a spectrum, or onto discrete stops, and drive a block's text, icon or background from live data. A spectrum stop can hold an image as well as a color.
• Navigation. Build the published site's navigation from labels, dropdowns, mega menus, collection lists, and language and light/dark switchers.
• Themes. A theme controls the layout, navigation and overall look of a published site. The Themes panel lists every theme the station has: switch one on to make it available, then pick which available theme the project publishes with. Each theme carries its own light and dark mode, and its own colors, logos and heroes, so switching theme does not mean redoing your branding. Classic ships with the product.

Pages are built from blocks, edited directly in a live preview of the page rather than in a form beside it. This is what makes dynamic, genuinely custom screens practical.

• Edit in the preview. Add, move, resize and configure blocks on the page itself and watch it change as you work. A properties panel beside the preview carries the selected block's settings, grouped into Data, Content and Style.
• A grid that responds. Blocks sit on a responsive grid. Layouts can be set per breakpoint, so a page can be arranged deliberately for desktop, tablet and phone rather than reflowing by accident.
• Block groups. Blocks can be grouped, and a group lays its children out as a grid, a vertical stack, or a masonry packing. Groups nest.
• The block library. Text, Image, Point, Point List, Circle, Toggle, Divider, Table, BQL Table, Map, Canvas, Web View, Project Files, Weather Conditions, Weather Forecast and Weather Map, alongside the building automation blocks listed further down.
• Every built-in page is a template. Alarms, Histories, Schedules, Buildings and Device pages are all editable templates rather than fixed screens. A collection can have several: one is the project default, and alternates can be pinned to a particular equipment type or a particular device, so one project can present two device types completely differently.
• Interactions. A block can navigate, open a URL, command a point, show a command list, set a variable, or run several of those in order. Something carrying more than one interaction can ask which to run rather than running them all.
• Multi-select editing. Select several blocks and the panel shows what they have in common, marking a property the selection disagrees on rather than showing one block's value as if it were everyone's.

The Canvas Editor is a substantial step beyond the Floor Plan editor it replaces. It still draws floor plans, and it now builds equipment graphics, dashboard content and custom visual interfaces, which makes it a full replacement for anything previously built in the PX editor.

• One editor, several jobs. A canvas is created at a size preset for what it is for: a floor plan, a device graphic, or single, double and full width dashboard content.
• Drawing tools. Rectangle, triangle, polygon, circle, ellipse, line, zone, label and image elements, with opacity, rotation, alignment, layering and an aspect ratio lock.
• Zones. A zone can show a value, choose how its label behaves, and highlight on hover, dimming its neighbours the way the published view does.
• States. A canvas holds states, and each element can be shown or hidden per state. States are switched from the page at runtime, carry translated names, and one is the default.
• Bindings in one place. Every binding on a canvas can be reviewed and repaired from a single list; editing a row re-points every place that used it, and pointing at a row outlines the element on the canvas.
• Map a label to a record. A label can be mapped onto a device, building, space or weather station in one step, which fills its title, value and info lines from that record and adds a click that opens it.
• Browse mode. Press B to stand the editor down and use the canvas the way a viewer will, including running interactions for real, without publishing first.
• Export and import. A canvas exports to a file and imports into another project.

Buildings organize a site's equipment, alarms, histories and schedules, and give the published project its structure.

• Buildings and their spaces. A building holds spaces (floors, rooms, zones), each with its own photo, devices and pages. Spaces can be added in bulk.
• Building status. A building reports online or offline from one or more status points, on a test you configure. Status shows on the building's pages, in the building sub navigation, and on map markers.
• Per-building presentation. A building can carry its own hero image, its own sub navigation across all of its pages, and its own photo behind its page titles.
• Filter anything to a building or space. Data blocks scope to the building or space they sit in, so one page template serves every building.
• Blocks. Building List, Buildings Map, Spaces Grid and Space View.

Equipment covers the devices on a station, the systems they belong to, and the points they expose.

• Devices. Devices are discovered from the station and assigned to buildings, spaces and schedules, individually or several at a time. A device can carry a room name, choose its own status point, and show the controller it reports to.
• Device types. A device type groups devices that share a shape, and can choose the details page used for all of its equipment. Types can be kept off index pages.
• Systems. Systems group equipment that works together. Each system and system type gets its own details page, and buildings get system pages of their own.
• Point Catalog and point templates. The catalog is the base layer every template builds on: it recognizes points by pattern, gives them display names, and lets a template select and feature the ones a device type should show. Catalogs and templates export and import.
• Blocks. Device Index, Device Summary, Device Details, Device Header, Device Points, Device Graphic, Devices List, System Header, System Devices, System Counts and System Type Summary.

Niagara trend logs are browsed, charted and embedded in pages.

• Browse and chart. Histories are listed with search and filters, charted over a time range, and exported.
• Blocks. History List, History Chart and History Sparkline. A chart's primary Y axis can be given fixed bounds, and clicking a chart opens the histories page showing what it was displaying.

The alarm console is a set of blocks on an ordinary page, which means it can be laid out and extended like any other.

• Console and sources. Alarm records and alarm sources are listed, filtered, sorted, acknowledged and exported to CSV. Acknowledging respects the operator's Niagara permissions.
• Filter from a header. The Alarms Header block puts a time range, a priority filter and a record filter on the console, and you choose which blocks it filters. A page can open already filtered.
• Per-building alarms. Buildings have alarm pages of their own, and alarm counts follow device memberships as well as alarm classes.
• Blocks. Alarm Display, Alarm Shelf, Alarm Records Table, Alarms Sources Table and Alarms Header.

Niagara schedules are viewed and edited in the browser, and linked to the equipment they operate.

• Schedules in context. A schedule can be reached from the device it operates and from the building it belongs to, and its page shows the schedule's own name as its heading.
• Blocks. Schedules Index, Schedule List and Schedule View.

Bindings are the connection layer between your data and your interface. They are what lets a block show a live value without anyone wiring a graphic to a point by hand.

• Bind almost anything. A block's title, value, icon, color, image and background can each be bound, to a station point, a collection record, a variable, or a fixed value.
• Math without a wiresheet. Several points can feed one value through an operation (average, sum, minimum, maximum and others), so a summary does not need logic built in the station first.
• Dynamic colors, icons and text. A binding can drive appearance as well as content, so a value colors itself, swaps its icon, or changes its wording as it changes.
• Formatting and fallbacks. A bound value can carry its own formatting and units, and a fallback for when there is nothing to show. A binding pointing at something that no longer exists says so rather than reading blank.
• Variables. Pages and projects hold variables. A variable can take a collection record, a color, an icon or an image and drive a block with it; it can take its value from the address bar, so a filtered view is a shareable link; and a block can write back to it, which is how a picker changes what the rest of the page shows.
• Copy and paste. Bindings copy and paste, including between projects.

Conversations about a building live alongside the building, rather than in a separate inbox. Integrators, operators and teams work together inside the system they are discussing, instead of trading emails and screenshots.

• A timeline on every page. The collaboration panel shows a chronological feed of the comments, tasks and events for the page you are on, each entry naming its author and when it was added.
• Comments and tasks. Post a comment or a task; tasks carry a checkbox and are marked complete from the timeline. Entries can be edited after posting, and ⌘Enter or Ctrl Enter posts one.
• Pin what matters. An entry can be pinned at Urgent, High or For Review, which moves it into a Pinned section at the top of the timeline, ordered by priority and color-coded to match.
• Reactions. Hovering an entry offers six reactions. They collect into chips showing a count and naming everyone who reacted.
• Attachments. Comments and tasks carry files, added from the paperclip or dropped straight onto the box. Images, video, PDFs, Office documents, CSV, JSON, text and archives are accepted, and an attachment can be renamed to something friendlier than the filename it arrived with.
• Mention people and places with @. Typing @ lists the people on the station, and keeps searching into anything your project has a details page for: buildings, devices, schedules, histories, and items nested inside them. Hovering a mention opens a card describing it, clicking one goes there, and a mention survives a rename because it remembers what it points at rather than what it was called.
• Being mentioned notifies you. A bell on the panel carries a count of unread mentions, and the same count shows on the collaboration button with the panel closed. Mentions arrive as a toast the moment they are posted, and the notification takes you to the comment. Notifications are saved per person, so they follow you between browsers.
• Audit logs in context. A page bound to a station component shows the audit log for that component and everything beneath it, so what changed sits beside the conversation about it.
• Two people at once. Changes are checked against the server's copy before they are stored, and a change that arrives second is merged onto the newer timeline rather than overwriting it.

• Maps. Buildings are placed on a map with clustering, a full style system for markers, and popups whose every part can be colored, given indicator badges, and filled with live data. Marker styles organize into folders, and a collection carries a default popup style.
• Weather. Global weather data drives the Weather Conditions, Weather Forecast and Weather Map blocks, and a weather station can be mapped onto a canvas label.

• Global Search. Press ⌘K or Ctrl K on any page to search across pages, buildings, spaces, devices, points, histories and more. Results are live and categorized, and a query can be scoped with is:<category>, as in is:building or is:point is:numeric temp.
• Performance. The station compresses application files before sending them, taking a first load of the config and view apps from about 18.7 MB to 5.6 MB; the data Reflow requests from the station is compressed too. The saving is largest where it matters most, opening Reflow over a remote or cellular connection. Web Cache in App Settings governs it, and can be cleared from there.
• Real clipboard support. Copy and paste use the system clipboard, so content moves between Reflow and other applications.
• Software Updates. The Software Updates page reports the installed version, checks for a newer one, and shows the release notes for both the version you are running and the update waiting for you.
• Multiple tabs and multiple people. Changes synchronize between browsers and tabs as they are made, so two people editing the same project see each other's work rather than overwriting it.

The following are in development and are not part of this release.

• Migration from Reflow 1. Reflow 2 does not read Reflow 1 projects yet. It can be installed alongside Reflow 1 on the same station in the meantime, and a migration path for existing save files is in development for a later release. See the Reflow 2 FAQ for more information.
• More themes. The theme system ships with Classic. Further themes begin to arrive after this release, and install from the gallery like any other plugin.
• More plugins. The plugin gallery grows after release with first and third-party plugins, including animated equipment graphics, reporting and kiosk support.