Managing Enterprise Users in Fuuz Industrial Operations

Enterprise Users

Managing Enterprise Users

Article Type: Concept / How-To
Audience: Enterprise Administrators
Module: Enterprise Admin - Enterprise Users
Applies to Versions: Fuuz 2024.1+

1. Overview

Enterprise Users are the foundational user records in the Fuuz platform, maintained at the enterprise level rather than within individual applications. These user records control platform access, authentication, and the basic permissions structure that governs what users can see and do across all applications and environments.

Only Enterprise Administrators have access to the Enterprise Users management interface. This centralized control ensures proper governance, security, and compliance across the entire Fuuz implementation.

Enterprise Users vs. App Users

Understanding the distinction between Enterprise Users and App Users is critical for proper platform administration:

Aspect Enterprise Users App Users
Definition Actual user record in the database Reflection of enterprise user with app-specific access
Scope Platform-wide (all tenants and apps) Single application/tenant only
Who Manages Enterprise Administrators only Application Administrators within their app
Contains Basic identity, authentication, access types, tenant assignments Role assignments, permissions, app-specific settings
Creation Must be created first; can exist without app access Created automatically when enterprise user granted app access
Key Concept: An Enterprise User record must exist before any application access can be granted. App Users are simply pointers to Enterprise Users that define what that user can do within a specific application.








User Creation Workflows

Fuuz supports two methods for creating Enterprise Users, each serving different organizational needs:

Method Who Initiates Use Case Result
Direct Creation Enterprise Administrator Enterprise-level users, bulk onboarding, pre-provisioning User created immediately with selected access types and tenants
Access Request Approval Application Administrator requests; Enterprise Administrator approves New employees, contractors, facility-specific users User created (if new) or existing user granted additional app access
Best Practice: Enterprise Administrators should prioritize reviewing and acting on access requests rather than creating users directly. This workflow provides better accountability and ensures local administrators have verified the business need for access.

2. Access Requirements & Prerequisites

Required Access Level

Managing Enterprise Users requires:

  • Access Type: Administrator (assigned at enterprise level)
  • Interface Access: Enterprise Admin Home interface enabled
  • Navigation Path: System → Access Control → Enterprise Users
Important: Application Administrators (those with Administrator access type within specific apps) cannot access the Enterprise Users interface. Only users who have been granted access to the Enterprise Admin Home can manage enterprise-level users.

Email Requirements

All Enterprise Users must have a valid email address that serves as their unique identifier. The platform supports:

Identity Provider Configuration

Before creating users, ensure appropriate Identity Providers are configured:

Provider Type Description When to Use
Internal Fuuz native authentication Default; operational users; users without SSO
OIDC Provider OpenID Connect compatible service Enterprise SSO integration

Understanding OIDC (OpenID Connect)

OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that allows users to authenticate through their existing enterprise identity provider rather than maintaining separate Fuuz credentials. This provides single sign-on (SSO) capabilities and centralizes authentication management.

Common OIDC-Compatible Services:

  • Microsoft Azure AD / Entra ID: Enterprise identity management for Microsoft 365 environments
  • Okta: Cloud-based identity and access management platform
  • Google Workspace: Google's enterprise identity provider
  • Auth0: Flexible authentication and authorization platform
  • Keycloak: Open-source identity and access management solution
  • Ping Identity: Enterprise identity management platform
  • AWS Cognito: Amazon's user identity and authentication service
Pro Tip: Configure OIDC providers before bulk user imports to ensure users authenticate through your enterprise SSO from their first login. This eliminates the need for password management and improves security compliance.

3. Step-by-Step Instructions

Method 1: Direct User Creation

Use this method when Enterprise Administrators need to create users directly without an access request workflow.

Step 1: Access Enterprise Users Interface

  1. Navigate to Fuuz → System → Access Control → Enterprise Users
  2. The Enterprise Users table displays all existing users with their access types, home tenants, and authentication status

Step 2: Initiate User Creation

  1. Click the + (Add) button in the toolbar
  2. The Create User: Details dialog opens

Step 3: Enter User Details

Complete the following required and optional fields:

Field Required Description
Email Yes Unique identifier for the user; must be valid email format
Active Yes Toggle; new users should typically be active
First Name No User's given name; appears in UI and logs
Middle Name No User's middle name or initial
Last Name No User's surname; appears in UI and logs
Phone Number No Contact number; may be used for multi-factor authentication
  1. Click the forward arrow (→) button to proceed to access control configuration

Step 4: Configure Access Control

The Create User: Access Control dialog configures authentication and access parameters:

Field Required Description
Identity Provider Yes Select "Internal" or configured OIDC provider
Access Type Yes Choose from Administrator, Developer, or Web Access (see Configuration Details section)
Home Tenant Recommended Default tenant for user login; if not set, user must select tenant each login
Select Role Conditional Available only if you have access to the Home Tenant; roles control granular permissions
Access Expires At No Specific date when access automatically expires; useful for contractors
Access Expires After Days of Inactivity No Default 90 days; user locked after this period of no authentication
Role Assignment Limitation: If you see the message "You do not have access to the home tenant selected. Please navigate to the App Users screen within the home tenant to assign roles and provide access," this means you as an Enterprise Administrator do not have access to the selected Home Tenant. You have two options: (1) Select a different Home Tenant where you do have access, or (2) Complete user creation without role assignment and have an Application Administrator within that tenant assign roles afterward.
  1. Click the + (Save) button to create the user
  2. The system creates the Enterprise User record immediately
  3. If roles were not assigned during creation, navigate to the Application's App Users interface to complete role assignment



Method 2: Access Request Approval

This method provides a governance workflow where Application Administrators request access for users, and Enterprise Administrators approve those requests.

Access Request Workflow

Step Who Action Location
1 App Administrator Submits access request with user email and business justification Within their application → Access Control → Access Requests
2 System Sends email notification to Enterprise Administrators Email inbox
3 Enterprise Administrator Reviews request and approves/denies System → Access Control → Access Requests
4 System Creates Enterprise User (if new) or grants access to existing user Automatic
5 App Administrator Assigns roles and finalizes access configuration Within their application → Access Control → App Users

Reviewing and Approving Access Requests

  1. Navigate to System → Access Control → Access Requests
  2. Review pending requests, noting:
    • Requesting administrator and application
    • Requested user email address
    • Business justification
    • Whether this is a new user or adding app access to existing user
  3. Select the access request record
  4. Click Approve or Deny as appropriate
  5. If approving:
    • System creates the Enterprise User record (if new user)
    • User is granted access to the requested application
    • Requesting administrator can now assign roles in their App Users interface
Pro Tip: Check for pending access requests regularly (daily or weekly depending on your organization's size). Setting up email filters to highlight Fuuz access request notifications helps ensure timely processing and reduces onboarding delays for new employees.

Granting Multi-Tenant Access

Users can be granted access to multiple tenants (applications). Each tenant access can have a different Access Type, allowing fine-grained control over user capabilities across the enterprise.

Adding Additional Tenant Access

  1. Navigate to System → Access Control → Enterprise Users
  2. Select the user record
  3. Click the TENANTS tab
  4. View existing tenant assignments with their Access Types
  5. Click + (Add) to grant access to additional tenant
  6. Select:
    • Tenant name
    • Access Type for this tenant (can differ from other tenants)
    • Active status
  7. Save the configuration
  8. Navigate to that tenant's App Users interface to assign roles
Note: Access requests create tenant access for only ONE specific application. If a user needs access to multiple applications, either multiple access requests are required, or Enterprise Administrators should add tenant access directly as described above.



Reactivating Locked Users

Users can become locked due to inactivity timeouts, excessive failed login attempts, or manual deactivation. Enterprise Administrators can reactivate these users.

  1. Navigate to System → Access Control → Enterprise Users
  2. Filter or search to find the locked user (inactive status or expired access)
  3. Select the user record
  4. Review the lockout reason in the AUTHENTICATION EVENTS tab if needed
  5. On the DETAILS tab:
    • Set Active to enabled
    • Clear or extend the Access Expires At date if applicable
    • Update Access Expires After Days of Inactivity if needed
  6. Save the changes
  7. The user will likely need to reset their password on next login
Security Note: Before reactivating a user who was locked due to excessive failed login attempts, verify with the user that the activity was legitimate. Repeated failed attempts may indicate an attempted security breach.

4. Configuration Details

Access Types Explained

Access Types determine the fundamental capabilities and menu visibility for users. These are distinct from Roles, which provide granular permission control within applications.

Access Type Menu Access Capabilities Typical Users
Administrator Access Control, Data Management, App Management, Logs, Reports, and all operational screens Manage users, roles, data models, application configuration, view all logs and reports IT staff, plant managers, department supervisors
Developer Environment application designer, troubleshooting features, API browser, plus operational screens granted via roles Create/modify data flows, screens, data models, saved queries, document designs; debug and troubleshoot; test features Application developers, integration specialists, business analysts with technical skills
Web Access Only operational screens granted via their assigned roles View data, enter transactions, run reports as permitted by role-based access control (RBAC) Operators, production workers, quality inspectors, warehouse personnel
Gateway Access None (system account) Used by gateway devices for IIoT data collection and device communication Automatically created by system (not manually managed)
API Access None (programmatic only) Programmatic API access for integrations and external systems Service accounts for ERP integrations, external applications, automated processes
Critical Distinction: Access Types control menu visibility and basic capabilities. Roles (assigned within App Users) control granular permissions to specific data and operations. Both Administrator and Developer access types typically also have roles assigned for testing and operational purposes.

Special Access Types

Gateway Access: These users are automatically created when initializing a gateway device and cannot be manually created or modified. Each gateway user is scoped to exactly one tenant and serves as the authentication identity for the physical gateway device communicating with the platform.

API Access: These users can only be generated by Enterprise Administrators and are scoped to specific tenants. API Access users receive an API key for programmatic authentication and are typically used for system-to-system integrations.

Home Tenant Configuration

The Home Tenant setting determines which application a user enters by default when logging into the Fuuz platform. This setting significantly impacts user experience and should be configured thoughtfully.

Home Tenant Behavior

Configuration Login Experience When to Use
Home Tenant Set User automatically enters their Home Tenant application immediately after authentication Most users; provides seamless login experience
No Home Tenant User must select an application from a list every time they log in before accessing any screens Users who frequently switch between many applications; administrators who need application selection flexibility

The Home Tenant can be changed at any time by modifying the user's Enterprise User record. Users retain access to all other assigned tenants and can switch between applications after login using the tenant/application switcher in the interface.

Pro Tip: For users who primarily work in a single application, always set an appropriate Home Tenant. The improved login experience significantly reduces friction and support requests. For Enterprise Administrators who manage multiple applications, consider leaving Home Tenant blank to maintain flexibility.

Plus Addressing for Operational Users

Plus addressing enables multiple unique user identities to be created using a single email mailbox. This is particularly valuable for operational environments where individual workers do not have corporate email accounts but still require unique, auditable system access.

How Plus Addressing Works

Plus addressing inserts a plus sign (+) and a unique identifier into the local part of an email address before the @ symbol. The email server treats these as distinct recipients for authentication purposes while routing all messages to the base mailbox.

Format Pattern:

baseaddress+identifier@domain.com

Examples:
supervisor@company.com+operator1
supervisor@company.com+operator2
admin@company.com+warehouse_clerk_1
plantmanager@company.com+forklift_driver_3
shiftlead@company.com+quality_inspector_a

Email Provider Compatibility

Email Provider Support Notes
Gmail Native support Fully supported; no configuration needed
Microsoft 365 / Outlook Native support Fully supported; no configuration needed
Yahoo Mail Alternative format Uses hyphen (-) instead of plus: user-identifier@yahoo.com
ProtonMail Native support Supported in paid plans; verify plan compatibility
iCloud / Apple Mail Limited support Not officially supported; test before deployment
Self-Hosted / Custom Varies Depends on mail server configuration; verify with IT administrator

Benefits of Plus Addressing

  • Unique Authentication: Each operational user has a distinct login identity even when sharing a supervisor's mailbox, enabling proper identity management
  • Audit Traceability: System logs track individual user actions by their unique identifier for compliance, quality management, and security investigations
  • Role-Based Access Control: Each plus-addressed user can be assigned different roles and permissions appropriate to their job function
  • Individual Lockout: Security policies can lock out individual users without affecting the entire team when password policies are violated
  • Centralized Management: Supervisor or manager receives all password reset and notification emails in one mailbox, simplifying communication
  • Cost Efficiency: Eliminates the need to provision individual corporate email accounts for every operational user
Best Practice: Use descriptive identifiers in plus addressing that indicate the user's role, shift, or location, such as +warehouse_operator1, +line_supervisor_shift_a, or +qa_inspector_building2. This improves readability in audit logs, user management screens, and makes user identification easier for administrators.

Security Considerations with Plus Addressing

While operational users share a mailbox for receiving emails, they are treated as completely separate users within Fuuz for authentication, authorization, and auditing. Each plus-addressed user:

  • Has their own password (separate from the base email account)
  • Can be assigned unique roles and permissions
  • Generates separate audit log entries for all actions
  • Can be individually locked out or deactivated
  • Has independent session management

Access Expiration Settings

Fuuz provides two mechanisms for automatically expiring user access, both serving important security and compliance functions.

Access Expires At

This setting specifies an absolute date and time when user access expires. This is particularly useful for:

  • Contractors: Set expiration to match contract end date
  • Temporary Workers: Align expiration with expected employment end
  • Project-Based Access: Expire access when project completes
  • Compliance Requirements: Meet regulatory requirements for periodic access review

Access Expires After Days of Inactivity

This setting (default 90 days) automatically locks user accounts that have not authenticated within the specified timeframe. This helps:

  • Reduce Attack Surface: Inactive accounts cannot be compromised
  • Compliance: Meet requirements for automatic account deactivation
  • License Management: Free up licenses from unused accounts
  • Access Hygiene: Prompt review of whether user still needs access
Important: When access expires (either method), the user is locked out immediately upon reaching the expiration point. They will be unable to log in until an Enterprise Administrator reactivates their account. Plan accordingly and communicate expiration timelines to affected users.

5. Common Issues & Troubleshooting

Authentication Events Log

The Authentication Events tab for each Enterprise User provides a detailed log of all authentication attempts, both successful and failed. This is a critical tool for security monitoring and troubleshooting user access issues.

Common Authentication Failure Reasons

Failure Reason Cause Resolution
Authentication failed: jwt expired User's session token has expired after period of inactivity User should log out and log back in; not a security concern
Authentication failed: wrong password Incorrect password entered User should reset password; watch for repeated attempts indicating potential attack
Too many failed attempts User exceeded maximum failed login attempts Administrator must reactivate account; verify legitimate user before unlocking
Access expired User's access expired due to inactivity timeout or absolute expiration date Administrator must reactivate account and may need to update expiration settings
IP restriction violation User attempting to access from unauthorized IP address Verify user is on VPN or within allowed IP range; update IP restrictions if legitimate
Password expired User's password exceeded maximum age per password policy User must reset password through password reset workflow
User not found / inactive User account does not exist or is marked inactive Administrator must create user or set Active flag to enabled
Security Monitoring: Enterprise Administrators should regularly review authentication events, particularly repeated failed login attempts from unusual IP addresses or at unusual times. These may indicate attempted security breaches or compromised credentials.


Troubleshooting Table

Problem Possible Causes Solution
Cannot assign roles during user creation Enterprise Administrator does not have access to the selected Home Tenant Choose a different Home Tenant where you have access, or complete user creation and have an App Administrator assign roles afterward. Alternatively, grant yourself access to the tenant first
Access request not received Email notification filtered or not delivered; administrator hasn't checked interface Check email spam/junk folders for Fuuz notifications; navigate directly to System → Access Control → Access Requests to view pending requests; set up email filter to prioritize Fuuz notifications
Plus-addressed email not working Email provider does not support plus addressing or has non-standard implementation Verify email provider compatibility (see Configuration Details section); Yahoo Mail requires hyphen (-) instead of plus (+); test with a sample email before creating multiple users
User exists in Build but not in Production Access types and user assignments do not automatically synchronize across environments Manually create the user in Production environment with same configuration; consider documenting user creation as part of deployment checklist
User has wrong permissions Access Type determines menu visibility; Roles control data and operation permissions Verify both Access Type (Enterprise Users) and Role assignments (App Users within application). Most permission issues are role-related, not access type
Cannot access Enterprise Users interface User has Administrator access type within apps but not access to Enterprise Admin Home Contact another Enterprise Administrator to grant access to Enterprise Admin Home interface. Application-level administrators cannot access enterprise-level user management
Cannot reactivate locked user User status shows as no longer active; account may be in locked state Navigate to Enterprise Users, select the user, enable Active flag, clear or extend Access Expires At date if set, and save. User will need to reset password after reactivation

Cross-Environment Access Management

Fuuz implementations typically include multiple environments (Build, QA, Production) that are completely separate instances. Enterprise Users and their access configurations do not automatically synchronize across these environments.

Manual Synchronization Required

When creating or modifying Enterprise Users, administrators must manually ensure consistency across environments:

  • User Creation: Must be performed separately in each environment (Build, QA, Production)
  • Access Type Assignments: Must be configured independently per environment
  • Tenant Access: Must be granted separately in each environment
  • Role Assignments: Can be packaged and migrated using Package Management features (typically managed by Developers)
Pro Tip: Maintain a standardized onboarding checklist that includes creating the user in all required environments (Build for testing, QA for validation, Production for live use). This ensures testing scenarios accurately reflect production access patterns and prevents deployment issues.

Role and RBAC Synchronization

While Enterprise User records must be manually synchronized, Role definitions and RBAC policies can be packaged and migrated across environments using Fuuz's Package Management features. This is typically handled by users with Developer access type who can:

  • Create a package containing role definitions
  • Export the package from Build or QA environment
  • Import the package into Production environment
  • Apply role assignments to users in Production

6. Best Practices & Tips

Security & Governance Best Practices

Enterprise Administrators are responsible for maintaining proper security controls across the entire Fuuz implementation. Since customers control their own access to suppliers, employees, third parties, and other stakeholders, they are responsible for maintaining proper security protocols and reviews of access controls to ensure data security.

Critical Security Notice: Should unauthorized access result in any data breach or other security incident where the customer granted access but failed to maintain proper control, this will be the customer's responsibility to remedy. Enterprise Administrators must exercise care in providing access to any IT system and maintain vigilant oversight of user access.

Essential Security Practices

Practice Implementation Benefit
Annual Access Review Review all users annually; verify job roles, access needs, and employment status Removes unnecessary access; meets compliance requirements; reduces attack surface
Inactivity Timeout Use "Access Expires After Days of Inactivity" (recommend 90 days default) Automatically locks unused accounts; prevents compromise of dormant credentials
Strong Password Policy Configure robust password requirements; avoid non-expiring passwords unless absolutely necessary Reduces risk of credential compromise; meets security compliance standards
IP Restrictions Apply IP restrictions for sensitive accounts or when using non-expiring passwords Limits access to known secure networks; prevents access from compromised locations
Authentication Monitoring Regularly review authentication events; watch for suspicious patterns Early detection of security threats; identifies compromised accounts quickly
Onboarding/Offboarding Checklists Add Fuuz to existing IT onboarding and termination procedures Ensures timely access provisioning and removal; prevents orphaned accounts

IT Policy Integration

Include Fuuz in existing or new IT policies that govern system access:

  • Access Control Policy: Define who can request and approve access, acceptable use, and access review procedures
  • Password Policy: Align Fuuz password requirements with organizational standards
  • Data Classification Policy: Define what data sensitivity levels exist in Fuuz and who can access them
  • Incident Response: Include Fuuz authentication logs in security incident investigation procedures
  • Compliance Documentation: Maintain records of access reviews and security configurations for audit purposes

Operational Best Practices

Access Request Workflow

  • Prioritize Access Requests: Review and approve access requests before creating users directly; this provides better governance and accountability
  • Monitor Request Queue: Check access requests daily or weekly depending on organization size; timely processing reduces onboarding delays
  • Email Filtering: Set up email filters to highlight Fuuz access request notifications in your inbox
  • Document Denials: When denying access requests, document the reason for future reference

User Data Management

  • Complete User Profiles: Always fill in First Name and Last Name; these appear in audit logs and make user identification much easier
  • Descriptive Plus Addressing: Use identifiers that indicate role or location (e.g., +warehouse_operator1, +qa_shift_b)
  • Set Home Tenant: Always configure Home Tenant for operational users; the improved login experience reduces support burden
  • Document Access Patterns: Maintain notes about why users have access to multiple tenants or special configurations

Multi-Environment Management

  • Standardized Onboarding Checklist: Document the need to create users in Build, QA, and Production environments
  • Test Access Patterns: Create test users in Build with same Access Types as production users to ensure testing scenarios are realistic
  • Package Role Definitions: Work with Developers to package and migrate role definitions across environments rather than manually recreating them
  • Production Deployment Checklist: Include user creation and access verification as part of deployment procedures

Identity Provider Selection

Scenario Recommended Identity Provider Rationale
Corporate employees with existing SSO OIDC (Azure AD, Okta, etc.) Leverages existing credentials; eliminates password management; meets security policies
Operational users without email Internal with plus addressing Cost effective; maintains unique identity; simple management
External contractors/suppliers Internal with time-limited access Simple provisioning; automatic expiration reduces risk; no dependency on external identity providers
Mixed environment OIDC for employees; Internal for operational/external users Balances security and convenience; appropriate authentication method for each user type
Pro Tip: Configure OIDC providers before bulk user imports to ensure users authenticate through enterprise SSO from their first login. This eliminates password management burden and improves security posture immediately.
  • App Users Management: Learn how Application Administrators manage users within specific applications, assign roles, and configure RBAC
  • Access Control Overview: Understand the complete access control model including roles, policies, and permissions
  • Access Requests: Detailed guide for Application Administrators on requesting access for new users
  • Identity Providers Configuration: Step-by-step guide to configuring OIDC providers for SSO integration
  • Roles and Permissions: Comprehensive guide to role-based access control configuration
  • API Keys and Programmatic Access: Guide to creating and managing API access users
  • Package Management: Learn how to package and migrate role definitions across environments

External Documentation

  • OpenID Connect Specification: Technical documentation for OIDC protocol at openid.net
  • Microsoft Azure AD Documentation: Configuring enterprise applications and OIDC integration
  • Okta Developer Documentation: Setting up OIDC applications
  • Plus Addressing Standards: Email addressing specifications (RFC 5233)

Support Resources

For additional assistance:

  • Fuuz Support Portal: Submit support tickets for technical assistance
  • Security Incidents: Report suspected security breaches immediately through priority support channels
  • Implementation Consulting: Contact Fuuz professional services for assistance with large-scale user migrations or complex access control requirements

    • Related Articles

    • Enterprise Admin Overview

      Article Type: Concept Audience: Enterprise Administrators, IT Management, Executive Sponsors Module: Enterprise Admin Applies to Versions: Fuuz 2024.1+ 1. Overview The Enterprise Admin interface represents the highest level of administrative control ...

    • API Keys

      Managing API Keys Article Type: Configuration / How-To Audience: Enterprise Administrators Module: Access Control Applies to Versions: All Versions Estimated Time: 15-20 minutes 1. Overview API Keys provide secure, programmatic access to the Fuuz ...

    • Authentication Events

      Authentication Events Article Type: Concept Audience: Enterprise Administrators Module: Enterprise Admin - Access Control Applies to Versions: All Versions 1. Overview The Authentication Events screen provides Enterprise Administrators with ...

    • Access Types

      Understanding Access Types Article Type: Concept Audience: Enterprise Administrators, Application Administrators Module: Enterprise Admin - Access Control Applies to Versions: All Versions 1. Overview Access Types define the fundamental level of ...

    • Access Requests

      App Access Requests Article Type: Configuration / How-To Audience: Application Administrators, Enterprise Administrators Module: Access Control Applies to Versions: All Versions 1. Overview App Access Requests provide a governed workflow for granting ...