Infohub (Flow)Concept

Users, Groups, and Access

Infohub's group-based security model — users, per-object scoping, Windows accounts, and the honest limits (view-only, AD groups, multi-domain).

Updated 15 Oct 2026Infohub Docs

Security questions make up a steady stream of support traffic and, until now, had no article at all. This is the model as it actually is — including the limits, because half those tickets are asking for things the model does not currently express.

The model#

Infohub's authorisation is group-based with per-object scoping:

Users are identities (Windows accounts for interactive users).
Groups collect users (Group ↔ GroupsUsername).
Access is granted by attaching groups to objects: measure groups, metric-folder groups, report and report-folder groups, form and form-folder groups, message-channel groups. An object with no group attachments follows its container; attaching a group scopes it.

So "who can see this dashboard" is answered by walking: the dashboard's report/report-folder group attachments → the groups → their members. Content scoping (which parts of the model/reports a user sees) is the model's strength.

Groups also own server keys — the machine credentials used by federation and replication — so the same construct scopes both people and system access.

Windows accounts and domains#

Interactive users authenticate as Windows accounts. What works and what does not:

Adding individual domain users works, including from the domain the server trusts.
Importing an AD group (rather than individuals) has a known failure — the individual-import path works where the group-import path errors. Until that changes, import members individually or script the membership sync outside Infohub.
Multi-domain / multi-forest: Infohub resolves accounts through Windows; it works to the extent the server's own trust relationships do. A forest the server cannot resolve is invisible to Infohub — this is an AD-trust configuration question before it is an Infohub one, and "add accounts from the other domain fails" almost always reproduces with plain Windows tooling on the same server.

The limits, stated honestly#

These are the asked-for-repeatedly items the model does not currently express:

A true view-only role. Users granted access to content can broadly interact with what they see — there is no global "read-only everything, including forms" switch. The practical approximations: scope form access away from view-only audiences (forms are the main write surface), use the event-form AllowAttributeEdit permission (7.2.0-era) to separate attribute entry from event editing, and keep Flow Config itself off limits — Config access is model-edit access.
Fine-grained event rights (split-but-not-edit): not expressible; see Event Lifecycle Operations.
Role hierarchies / permission inheritance between groups: groups are flat; compose by membership.

When a hardening review asks for these, the honest answer plus the compensating control (scoping + procedure) lands better than improvisation.

Service accounts and least privilege#

Two distinct accounts matter, and hardening reviews conflate them:

The Bootstrap service account runs every service object. Least privilege for it:

Log on as a service; no interactive rights needed
db_datareader/db_datawriter on the Infohub database plus DDL rights during upgrades (schema migration alters objects — grant temporarily for upgrade windows if the standing account must stay minimal)
Whatever each connection needs outward (historian read, share write) — grant per system, not admin anywhere
Not local Administrator, and not NT AUTHORITY\SYSTEM once any integrated-security connection exists

Config-tool users connect directly to SQL. Minimum SQL rights for a modeller: read/write on the Infohub database. Schema-changing operations (create instance, upgrade) additionally need DDL — which is why a locked-down modeller account works daily and fails on upgrade day. Plan the two tiers explicitly.

Important

Config access is not scoped by Infohub groups. Infohub's group model scopes the web experience. Anyone who can open Flow Config against the database has model-edit power constrained only by SQL permissions and the lock system. Treat Config + SQL credentials as administrative access, and keep the modeller circle explicit.

SQL connection trust#

A modern SQL client refusing to connect without "Trust Server Certificate" reflects SQL Server's encryption defaults, not Infohub: either install a real certificate on SQL Server (right answer) or accept trust-server-certificate in the connection (the workaround). When Infohub suddenly cannot reach SQL after an infrastructure change, this — not Infohub configuration — is the first suspect. See HTTPS and Certificates.

Auditing access#

Reviews ask "who can do what". The answers are enumerable:

Group membership: Group/GroupsUsername — via Config or read-only SQL
Object scoping: the per-object group tables (measure/folder/report/form/channel)
Web actions: user-attributed writes (form entries, comments, event edits) carry the username — comments and event versions are attributable per user

That attribution is also the answer to "who changed this value": versions record the author.

Setup that prevents the common tickets#

Create groups per audience (Operators, Supervisors, Viewers-by-area), not per person.
Scope forms tightly first — they are the write surface.
Add users individually (AD-group import has the known defect) and keep membership mirrored to an AD group by procedure, so leavers get removed.
Document the two-tier SQL rights (daily vs upgrade) with your DBA.
Re-verify after upgrades: permission-adjacent behaviour (event form editing, free-entry cells) has changed across versions — test one operator account after each upgrade.