Enterprise Users
Article Type: Concept / How-To Audience: Enterprise Administrators Module: Enterprise Admin - Enterprise Users Applies to Versions: Fuuz 2024.1+
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.
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.
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 |
Tip: 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.
Managing Enterprise Users requires:
- Access Type: Administrator (assigned at enterprise level)
- Interface Access: Enterprise Admin Home interface enabled, with access to the Enterprise Users screen under Access Control
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.
All Enterprise Users must have a valid email address that serves as their unique identifier. The platform supports:
- Standard Corporate Email: user@company.com
- Plus Addressing: supervisor+operator1@company.com (for operational users without individual email accounts)
- External Email: contractor@vendor.com (for suppliers, contractors, third parties)
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 |
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
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.
Use this method when Enterprise Administrators need to create users directly without an access request workflow.
- Open the Enterprise Users screen from the Access Control area
- The Enterprise Users table displays all existing users with their access types, home tenants, and authentication status
- Click the + (Add) button in the toolbar
- The Create User: Details dialog opens
Complete the following required and optional fields:
| Field | Required | Description |
|---|---|---|
| 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 |
Click the forward arrow (→) button to proceed to access control configuration.
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 |
Note: 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.
Then:
- Click the + (Save) button to create the user
- The system creates the Enterprise User record immediately
- If roles were not assigned during creation, use the Application's App Users interface to complete role assignment
This method provides a governance workflow where Application Administrators request access for users, and Enterprise Administrators approve those requests.
| Step | Who | Action | Location |
|---|---|---|---|
| 1 | App Administrator | Submits access request with user email and business justification | Access Requests screen within their application |
| 2 | System | Sends email notification to Enterprise Administrators | Email inbox |
| 3 | Enterprise Administrator | Reviews request and approves/denies | Access Requests screen (Enterprise Admin) |
| 4 | System | Creates Enterprise User (if new) or grants access to existing user | Automatic |
| 5 | App Administrator | Assigns roles and finalizes access configuration | App Users screen within their application |
- Open the Access Requests screen from the Access Control area
- 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
- Select the access request record
- Click Approve or Deny as appropriate
- 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
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.
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.
- Open the Enterprise Users screen
- Select the user record
- Click the TENANTS tab
- View existing tenant assignments with their Access Types
- Click + (Add) to grant access to additional tenant
- Select:
- Tenant name
- Access Type for this tenant (can differ from other tenants)
- Active status
- Save the configuration
- Use 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.
Users can become locked due to inactivity timeouts, excessive failed login attempts, or manual deactivation. Enterprise Administrators can reactivate these users.
- Open the Enterprise Users screen
- Filter or search to find the locked user (inactive status or expired access)
- Select the user record
- Review the lockout reason in the AUTHENTICATION EVENTS tab if needed
- 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
- Save the changes
- The user will likely need to reset their password on next login
Important: 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.
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 |
Important: 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.
Gateway Access: These users are automatically created when initializing an Edge Gateway 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.
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.
| 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.
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 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.
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+operator1@company.com
supervisor+operator2@company.com
admin+warehouse_clerk_1@company.com
plantmanager+forklift_driver_3@company.com
shiftlead+quality_inspector_a@company.com
| 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 |
- 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
Tip: 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.
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
Fuuz provides two mechanisms for automatically expiring user access, both serving important security and compliance functions.
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
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.
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.
| 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 |
Note: 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.
| 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; open the Access Requests screen directly 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 | Open 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 |
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.
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)
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.
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
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.
Important: 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.
| 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 |
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
- 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
- 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
- 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
| 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 |
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.
- Enterprise-Admin-Overview
- Enterprise-Users-vs-Access-Requests
- Access-Requests
- Access-Types
- Authentication-Events
- API-Keys
Source: support.fuuz.com