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 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. 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.

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

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.

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

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

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)

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

Gateway Access Type

System-Controlled Assignment:

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

Key Characteristics:

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

Policy Group Extension:

If Gateway users require additional permissions beyond basic Gateway operations, administrators can assign Policy Groups to extend their access. This might be necessary for 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

Menu Visibility by Access Type

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:

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 user 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. Resources

Related Articles

Access Control:

• Enterprise Users Management
• Role-Based Access Control (RBAC)
• Access Control Policies and Policy Groups
• App Access Requests Workflow
• Authentication Events and Security Monitoring

Administration:

• Enterprise Admin Overview
• Application Administrator Guide
• Managing Users Across Environments
• Security Best Practices

Development:

• App Designer Overview
• Screen Designer Guide
• Data Model Designer Guide
• Data Flow Designer Guide
• Package Creation and Deployment

Integration:

• API Access and Authentication
• Gateway Configuration Guide
• Creating API Service Accounts

7. Troubleshooting

8. Revision History