Users and Groups
What are Users and Groups?
Users are people who access Factry Historian to view, input, or configure data.
Groups are collections of users who share the same permissions within a specific organization.
In Factry Historian, users are assigned to groups per organization, and those groups define what they can access and do within that scope.
This page only applies to Factry Historian. Grafana users and groups are managed separately, with their own authentication and permission model.
Why does it matter?
Factry Historian is used by different roles (e.g. operators, engineers, the quality function, or IT admins), each with different access needs.
Groups make it possible to control access consistently and apply the principle of least privilege.
How does it fit in the system?
Per-organization model
- Each organization has its own set of groups
- All permissions are scoped per group
- A user can belong to different groups in different organizations, and therefore could have different permissions across organizations.
There are no cross-organization permissions or global roles.
Group permissions
Groups define what users can do, such as:
- Reading and/or managing assets, collectors, events, manual entry forms, etc.
- Reading and/or managing audit logs, settings, and task schedulers
- Reading and/or managing user groups and privileges
- Reading and/or managing time-series databases or external databases
Users inherit all permissions from the groups they belong to. Permissions are never assigned directly to users.
Authentication options
Factry Historian supports multiple authentication methods:
- Built-in authentication Managed entirely in Historian, with local passwords
- LDAP Log in against (local) LDAP hosts
- Azure Entra ID (formerly Azure Active Directory) Log in with Microsoft work accounts using OAuth
- Google OAuth Log in using Google Workspace or Gmail accounts
When using LDAP (with user groups) and/or Azure Entra ID (with security groups), users' groups can be mapped to groups in Factry Historian automatically. In the case of Built-in authentication or Google OAuth, users are assigned groups manually.
Example
User [email protected] can be:
- An Operator in Ghent Brewery
- An Admin in Antwerp Packaging
- Not assigned to any group in Bruges R&D (and has no access there)
When you use it
Use the user and group model in Factry Historian when:
- Governing access to various settings in Factry Historian
- Separating access and permissions across organizations, production sites or divisions
Common misconceptions
- Groups in one organization do not apply to another. Each organization manages its own group list and permissions.
- Authentication itself confirms a user’s identity, but it does not determine access. Grafana and Factry Historian access must be managed separately.
- Users who are not in any group for a given organization cannot access Factry Historian at all.
Best practices
- Keep group definitions aligned with job roles (e.g., Operator, Engineer, Admin)
- Use external authentication when possible for easier user management
- Review group memberships regularly and deactivate users who no longer need access
- Document group permissions clearly, especially in multi-org environments
More information
- Creating a user groupCreating a user group
- Creating a local userCreating a local user