Access Types

Understanding Access Types

Article Type: Concept Audience: Enterprise Administrators, Application Administrators Module: Enterprise Admin - Access Control Applies to Versions: All Versions

Access Types define the fundamental level of platform capabilities granted to Enterprise Users within each Fuuz Application. Unlike Roles which control granular data permissions, Access Types determine which platform interfaces, tools, and system functions a user can access.

1. Overview

Each Access Type provides a predefined set of policies that enable specific categories of platform interaction.

Access Types are assigned at the Application level, meaning a single Enterprise User may have different Access Types across different Applications and Environments. Only Enterprise Administrators can assign and modify Access Types when adding or editing Enterprise User records.

Important: In current platform versions, Access Types are mutually exclusive - each user can have only one Access Type per Application. This limitation will be removed in Q1 2026, allowing users to hold multiple Access Types simultaneously for greater flexibility.

Note: Beginning in Q1 2026, the platform will introduce an explicit Enterprise Administrator flag on user records, separating the Enterprise Admin designation from the Administrator Access Type. This architectural change will provide clearer distinction between Application Administrators and Enterprise Administrators.

Key Concepts

• Access Type: High-level permission category that controls menu visibility and platform tool access
• Role: Granular permission set that controls specific data operations within Applications (separate from Access Types)
• Policy: System-defined permission that enables specific platform functions (automatically assigned based on Access Type)
• Application-Level Assignment: Access Types are assigned per Application, including the Enterprise Admin interface which is itself an Application
• Environment Isolation: Each Environment (Build, QA, Production) maintains separate Enterprise User lists with independent Access Type assignments

2. Architecture & Data Flow

Access Type Definitions

Access Type	Description	Provided Policies
Administrator	Administrative user with full Application control including user management, access control, data ingress/egress, role management, application settings, and audit logs	Complete administrative policies required to perform all administrative actions within the Application
Developer Access	Development user with access to App Designer tools (Screen, Data Model, Data Flow, Document Designers) and troubleshooting capabilities; can view all data but cannot manage users	Development policies required to create and modify Applications, access all design tools, and troubleshoot Application behavior
Web Access	Standard user for web frontend access; requires Role assignment with Role-Based Access Control (RBAC) to access any Application functionality or data	Basic policies required to authenticate and access the web frontend; all functional access controlled by assigned Roles
API Access	Restricted access type for external software systems requiring programmatic API access; provides no default policies and must be linked to specific Applications with explicit RBAC assignments	No additional policies by default; requires explicit Policy Group assignment to access any data or perform any actions
Gateway Access	System-controlled access type automatically assigned to users generated by Fuuz when authenticating a Gateway; restricted similar to API Access	Limited policies required to use and edit the Gateway; additional access requires Policy Group assignment

Enterprise Administrator Architecture

The Enterprise Admin interface is architecturally implemented as an Application within the Fuuz Platform. Users granted access to this Enterprise Admin Application with the Administrator Access Type are designated as Enterprise Administrators by default. This architectural pattern means that Enterprise Administrators are simply Application Administrators for the special-purpose Enterprise Admin Application.

In Q1 2026, the platform will introduce an explicit Enterprise Administrator flag on user records, providing clearer separation between Application Administrators and Enterprise Administrators while maintaining backward compatibility with the current architecture.

Environment Isolation and Access Type Assignment

Each Environment (Build, QA, Production) maintains its own distinct list of Enterprise Users with independent Access Type assignments. A user must be explicitly granted access to each Environment separately, and their Access Type can differ across Environments based on operational requirements.

Example Multi-Environment Access Pattern:

• Build Environment: User has Developer Access to create and test Applications
• QA Environment: Same user has Developer Access to validate Applications before production deployment
• Production Environment: Same user has Web Access with view-only Role to monitor Applications without modification capability

This isolation ensures that developers working in Build or QA Environments do not automatically have access to Production data and configurations. Enterprise Administrators in each Environment independently control which users have access and what Access Types they are granted.

Important: Different Enterprise Administrators may manage different Environments. The Enterprise Administrator in Production has complete independence from Enterprise Administrators in Build or QA, allowing organizations to implement strict separation of duties and change control processes.

Current Mutual Exclusivity Constraint

In current platform versions, Access Types are mutually exclusive within an Application - each user can hold only one Access Type per Application. This creates specific implications for access management:

• If a user has Administrator Access Type, they automatically have all Developer capabilities but cannot be separately designated as Developer
• If a user has Developer Access Type, they have all development tools but no administrative rights
• If a user has Web Access Type, they have no rights until granted a Role with RBAC permissions
• Users requiring both administrative and development work must use the Administrator Access Type

2026 Enhancement: The mutual exclusivity constraint will be removed in Q1 2026, allowing users to hold multiple Access Types simultaneously. This will enable more flexible permission models such as users who have both Developer and Web Access, or specialized administrative users who only need specific administrative capabilities without full Administrator privileges.

3. Use Cases

Administrator Access Type

Appropriate For:

• Application Administrators who manage user access and application configurations
• IT Managers responsible for access control and security governance
• Users requiring both administrative and development capabilities in a single Application
• Enterprise Administrators (when granted Administrator access to the Enterprise Admin Application)

Key Capabilities:

• Full access to all Application data without Role restrictions
• User and access management (add users, assign roles, manage access requests)
• Role creation and modification
• Application settings and configuration management
• Data import and export workflows
• Access to audit logs and authentication events
• Ability to perform any action within the Application

Note: Grant Administrator Access Type only to users who require explicit permission to ALL data within an Application and the ability to manage users and perform any administrative action. This Access Type should be reserved for trusted personnel due to its comprehensive permissions.

Developer Access Type

Appropriate For:

• Internal IT developers building Applications
• Implementation consultants and partners
• Technical users who need to create and modify Application designs
• Users who troubleshoot Application behavior and data flows

Key Capabilities:

• Access to App Designer suite (Screen Designer, Data Model Designer, Data Flow Designer, Document Designer)
• View all Application data by default (for development and troubleshooting purposes)
• Create and modify Data Models, Screens, Data Flows, and Documents
• Package creation and deployment preparation
• Access to development logs and debugging tools
• Testing Application functionality with full data visibility

Restrictions:

• Cannot grant access to users or external systems
• Cannot manage user accounts or access control
• Cannot modify application-level settings and configurations

Tip: Grant Developer Access Type in Build and QA Environments to users who need to create and test Applications. Consider granting more restrictive access (Web Access with limited Roles) in Production Environments to prevent accidental modifications while maintaining visibility for troubleshooting.

Web Access Type

Appropriate For:

• Operators and frontline workers using Applications for daily operations
• Managers requiring specific data access and reporting
• Business users with role-specific Application access
• External portal users (customers, suppliers, contractors)

Key Characteristics:

• No menu items or Application access until granted a Role
• All functional capabilities defined by assigned Roles with RBAC permissions
• Can have granular permissions down to specific Data Models and operations (Create, Read, Update, Delete)
• Menu visibility controlled by Role assignments

Role-Based Configuration:

Web Access users see nothing in their navigation menu until an Administrator assigns them one or more Roles. Each Role defines:

• Which Screens and menu items are visible
• Which Data Models can be accessed
• What operations can be performed (view, create, edit, delete)
• What data within each Data Model is visible (row-level security)

Note: Web Access is the most common Access Type for production users. The flexibility of Role-Based Access Control allows organizations to create precise permission models that match their operational and security requirements without granting excessive platform privileges.

API Access Type

Appropriate For:

• External software systems requiring programmatic API access
• Integration service accounts
• Automated data exchange processes
• Third-party applications consuming Fuuz APIs

Key Characteristics:

• Blank slate with no policies provided by default
• Must be linked to specific Applications
• Requires explicit Policy Group assignment to access any data or perform any actions
• Zero access without Policy Group configuration

Configuration Requirements:

1. Create Enterprise User with API Access Type
2. Link user to specific Application(s) where API access is required
3. Assign Policy Group(s) that define permitted operations and data access
4. Generate API key for authentication

Important: API Access Type should not be assigned to human users who also have Web Access. API Access is specifically restricted for external software systems and service accounts requiring programmatic access. Human users should use Web Access or Developer Access as appropriate.

Gateway Access Type

System-Controlled Assignment:

Gateway Access Type is automatically assigned by the Fuuz Platform when authenticating an Edge Gateway. This is a system-controlled Access Type that users generally do not manually assign. The platform creates these users automatically during Edge Gateway registration and authentication processes.

Key Characteristics:

• Limited policies required to use and edit the Edge Gateway
• Restricted access similar to API Access
• Requires Policy Group assignment for access beyond basic Edge Gateway operations
• Automatically managed by the platform during Edge Gateway lifecycle

Policy Group Extension:

If Gateway users require additional permissions beyond basic Edge Gateway operations, administrators can assign Policy Groups to extend their access. This might be necessary for Edge Gateways that need to write data to specific Data Models or trigger specific Data Flows.

4. Screen Details

Assigning Access Types

Navigation Path:

Enterprise Admin Home → Enterprise Users → [Create or Edit User]

Required Permissions:

• Access Type assignment is restricted to Enterprise Administrators only
• Must have Administrator Access Type in the Enterprise Admin Application

Assignment Process:

1. Navigate to Enterprise Users screen
2. Click Create to add new user or select existing user to edit
3. In the user form, locate the Access Type field
4. Select one Access Type from the dropdown list
5. Link user to specific Application(s) where access is required
6. For Web Access users, assign Role(s) to define permissions
7. For API Access or Gateway Access users, assign Policy Group(s) if additional permissions are required
8. Save the user record

Note: Access Type assignments are Application-specific. A single Enterprise User may have different Access Types in different Applications and Environments. You must explicitly grant access and assign Access Types in each Environment (Build, QA, Production) separately.

Menu Visibility by Access Type

Access Type	Visible Menu Sections	Key Interfaces
Administrator	Access Control, Data Management, Application Settings, Audit Logs	Users, Roles, Access Requests, Import/Export, Application Configuration, Authentication Events
Developer Access	App Designer, Troubleshooting Tools, Data Model Management	Screen Designer, Data Model Designer, Data Flow Designer, Document Designer, Logs, Debug Tools
Web Access	Only menu items defined in assigned Roles	Application-specific screens as defined by Role configuration; no platform administration tools
API Access	No web interface access	Programmatic API endpoints only; no UI access
Gateway Access	Limited Gateway management interfaces	Edge Gateway configuration, device driver management (if Policy Groups assigned)

5. Technical Details

Access Type and Policy System

Access Types function as containers for system-defined policies that grant specific platform capabilities. When an Access Type is assigned to a user, the platform automatically provisions all policies associated with that Access Type, enabling the corresponding platform functions and interfaces.

Policies are atomic permissions that control specific platform capabilities such as:

• Ability to view specific administration screens
• Permission to execute specific platform operations
• Access to design tools and development interfaces
• Capability to manage users and access control

Access Types vs Roles: Understanding the Distinction

Access Types and Roles serve fundamentally different purposes in the Fuuz security model:

Aspect	Access Types	Roles
Purpose	Control platform interface and tool access	Control data and operation access within Applications
Scope	Platform-level permissions (what tools/interfaces user can access)	Application-level permissions (what data/operations user can perform)
Assignment	One Access Type per user per Application (currently)	Multiple Roles can be assigned to single user
Configuration	System-defined, cannot be customized	Customer-defined and fully customizable
Example	Developer Access = can see Screen Designer	"Operator" Role = can view and create Work Orders

Administrator and Developer Access Overlap

Due to the current mutual exclusivity of Access Types, the Administrator Access Type includes all policies from the Developer Access Type plus additional administrative policies. This means:

• Users with Administrator Access Type can access all App Designer tools
• Administrators can create and modify Data Models, Screens, Data Flows, and Documents
• Administrators have the union of both administrative and development capabilities
• Organizations requiring strict separation between administrators and developers must assign these roles to different users

When the mutual exclusivity constraint is removed in 2026, this overlap will become explicit - administrators who also need development capabilities can be assigned both Access Types independently.

Policy Groups for API and Gateway Access

Policy Groups are collections of policies that can be assigned to users with API Access or Gateway Access types to extend their permissions beyond the minimal default capabilities. Policy Groups enable fine-grained control over what operations and data these restricted Access Types can access.

Common Policy Group patterns for API Access:

• Read-only access to specific Data Models for reporting integrations
• Write access to specific Data Models for data ingestion workflows
• Execution permissions for specific Data Flows
• Access to specific API endpoints for targeted integration scenarios

2026 Access Type Enhancements

In Q1 2026, the Access Type system will undergo two significant architectural improvements:

1. Non-Mutually Exclusive Access Types

Users will be able to hold multiple Access Types simultaneously within the same Application. This enables scenarios such as:

• Specialized administrators with only specific administrative capabilities rather than full Administrator Access (can be done now using Web Access in combination with custom Roles and Policies that you can create yourself)
• More granular permission models that better match organizational roles

2. Explicit Enterprise Administrator Flag

An explicit Enterprise Administrator flag will be added to user records, separating the Enterprise Admin designation from the Administrator Access Type. This architectural change provides:

• Clearer distinction between Application Administrators and Enterprise Administrators
• More explicit security model for enterprise-level permissions
• Improved auditability of enterprise administrative actions
• Backward compatibility with existing access control patterns

6. Troubleshooting

Issue	Cause	Resolution
User with Web Access sees no menu items	No Roles assigned to user	Administrator must assign one or more Roles that define menu items and data access
Developer has access in Build but not Production	Environments maintain separate user lists	Production Enterprise Admin must explicitly grant user access in Production Environment; consider assigning Web Access in Production instead of Developer for safety
Cannot assign multiple Access Types to single user	Current platform limitation - Access Types are mutually exclusive	Assign Administrator Access Type (includes Developer capabilities) or wait for Q1 2026 enhancement allowing multiple Access Types
API Access user cannot access any data	API Access provides no default policies	Assign Policy Group(s) to the user that define permitted operations and data access
User needs both administrative and standard user access	Mutually exclusive Access Types	Assign Administrator Access Type and also assign Roles for testing user experience; Administrator can perform all functions of Web Access users when Roles are assigned
Cannot find option to make user an Enterprise Admin	Enterprise Admin is not an Access Type - it's granted by giving Administrator access in Enterprise Admin Application	Create/edit user, link to Enterprise Admin Application, assign Administrator Access Type; note explicit Enterprise Admin flag coming in Q1 2026
Gateway Access user needs additional permissions	Gateway Access has minimal default policies	Assign Policy Group(s) to extend Gateway user permissions for specific Data Models or operations
Developer cannot manage user access	Developer Access Type does not include user management policies	Expected behavior - user management requires Administrator Access Type; contact Administrator if user access management is needed

7. Revision History

Version	Date	Editor	Description
1.0	2025-12-29	Fuuz Documentation Team	Initial Release including current functionality and Q1 2026 enhancement preview

See Also

• Enterprise-Users
• Access-Requests
• Enterprise-Admin-Overview
• Authentication-Events
• Roles
• API-Keys

---

Source: support.fuuz.com