Understanding Fuuz Platform Architecture: Enterprises, Organizations, Applications, and Environments

Article Type: Concept
Audience: All Users, Enterprise Administrators, Application Administrators, Developers
Module: User Guide - Platform Architecture
Applies to Versions: All Versions

1. Overview

The Fuuz Industrial Operations Platform is built on a sophisticated four-tier architecture designed to provide enterprise-grade security, flexibility, and scalability. Understanding how Enterprises, Organizations, Applications, and Environments work together is essential for effective platform navigation, user management, and application deployment.

This article provides a comprehensive overview of the Fuuz Platform's organizational structure, helping users understand how to navigate between different areas of the system, manage access across multiple business units, and leverage different environments for development, testing, and production operations.

Who Should Read This Article

• New Users: Understanding platform structure for effective navigation
• Enterprise Administrators: Managing organizational structure and access control
• Application Administrators: Working across environments and applications
• Developers: Understanding deployment paths from Build through QA to Production
• Business Users: Navigating between different business units or locations

What You'll Learn

• How the Enterprise Mesh Architecture provides security and isolation
• The difference between Enterprises, Organizations, Applications, and Environments
• How Organizations group Applications for business structure
• How to navigate between different Applications and Environments
• When to use separate Applications versus a single unified Application
• The purpose and update schedule for each Environment type
• Available deployment options and infrastructure choices

2. Architecture & Data Flow

Enterprise Mesh Architecture

Unlike traditional multi-tenant cloud software where all customer data resides in a shared database, Fuuz employs an Enterprise Mesh Architecture that combines the scalability benefits of cloud services with enhanced security through data isolation. This hybrid approach provides each customer with dedicated services for their applications and data while leveraging a centralized service mesh for standard platform features and functions.

The Enterprise Mesh Architecture was designed specifically to address cybersecurity risks inherent in traditional multi-tenant systems. By keeping customer data isolated rather than intermingled, Fuuz significantly reduces the attack surface and potential blast radius of any security incident. This architecture also enables the platform's exceptional flexibility, allowing customers to create custom fields, tables, screens, and workflows without impacting other customers or requiring platform-wide changes.

Definitions

• Enterprise: The top-level organizational boundary identified by a unique subdomain, representing your entire organization within the Fuuz Platform
• Organization: A logical grouping within an Enterprise that helps define the radius of a particular business unit, campus, or region
• Application (App): The primary data isolation boundary within an Organization, typically representing a physical site, facility, or functional area (formerly called "Tenant")
• Environment: A complete instance of your Fuuz deployment with a specific purpose in the development lifecycle (Build, QA, or Production)
• Access Type: High-level permission category that controls menu visibility and platform capabilities (App Admin, Developer, Web Access)
• Role: Granular permission set that controls specific data and operations within applications for users with Web Access

Four-Tier Organizational Structure

The Fuuz Platform organizes access and data through four hierarchical levels, each serving a distinct purpose in your operational structure:

Deployment Options

Fuuz offers multiple deployment models to meet varying infrastructure, security, and scalability requirements. Contact the Fuuz sales team for detailed information on current offerings and licensing options suitable for your organization.

3. Use Cases

Enterprise Structure Examples

Example 1: Regional Manufacturing Company

• Enterprise: acme.fuuz.app
• Organizations: "Eastern Region", "Western Region", "Central Region"
• Applications per Organization: Each manufacturing plant as a separate App
• Rationale: Regional grouping enables regional managers to oversee multiple facilities while maintaining data isolation at each plant

Example 2: Diversified Industrial Company

• Enterprises: acmeprod.fuuz.app, acmedist.fuuz.app, acmeafter.fuuz.app
• Organizations per Enterprise: Product lines or geographic divisions
• Applications: Individual facilities or functional areas within each division
• Rationale: Complete separation between business units with independent IT management while allowing flexible internal structure

Example 3: Single Site with Multiple Applications

• Enterprise: facility.fuuz.app
• Organization: "Main Campus"
• Applications: "Production Floor", "Quality Lab", "Warehouse", "Maintenance", "Employee Portal"
• Rationale: Single physical site uses multiple Apps to separate functional areas and manage access control more granularly

Data Sharing Strategies

Applications provide complete data isolation by default, but organizations can implement various data sharing patterns based on their operational needs:

• Centralized Common Data Model: Create a dedicated App that serves as a shared data repository accessible by multiple other Apps within or across Organizations
• Organization-Level Aggregation: Build Apps that roll up data from multiple Apps within an Organization for regional reporting and analysis
• Enterprise-Level Consolidation: Create enterprise-wide Apps that aggregate data from all Organizations for executive dashboards and corporate analytics
• Complete Isolation: Keep all Apps fully isolated with no data sharing, maximizing security and simplifying access control
• Cross-Organization Sharing: Apps in one Organization can share data with Apps in another Organization through data flows and integration patterns

4. Screen Details

Enterprise Access

Your Enterprise represents your organization's top-level boundary within the Fuuz Platform and is identified by a unique subdomain. The subdomain typically corresponds to your company's domain name.

URL Pattern Examples:

• Cloud Production: https://acme.fuuz.app
• Cloud QA: https://qa.acme.fuuz.app
• Cloud Build: https://build.acme.fuuz.app
• Single Server: http://server-ip or custom domain
• Kubernetes: Customer-configured domain structure

Organization Selector

Organizations are logical groupings of Applications and are visible in the user interface. Users with access to multiple Organizations can navigate between them, though they are actually accessing the Applications within those Organizations rather than the Organizations themselves.

Application Selector (Tenant Selector)

Users can access multiple Applications if their Enterprise User account has been granted appropriate access. The Application selector is located in the bottom right corner of the Fuuz interface. The displayed name indicates your current Application context. Click this section to view all Applications you can access, then select your desired Application to switch contexts.

Environment Indicator

You can identify your current Environment through the Environment indicator in the bottom right corner of the Fuuz interface (the "tray") and through the URL in your browser's address bar. Always verify your Environment before performing operations to ensure you're working in the intended context.

Environment Indicators:

• Production: Displays "production" in the tray, URL has no environment prefix
• QA: Displays "qa" in the tray, URL begins with "qa."
• Build: Displays "build" in the tray, URL begins with "build."
  

5. Technical Details

Enterprise

The Enterprise level provides complete data isolation from all other Fuuz customers. This isolation extends to dedicated application services, ensuring that performance issues, security incidents, or customizations in one customer's Enterprise cannot impact another customer's operations.

Larger organizations may choose to deploy multiple Enterprises when business units operate independently or require complete separation. Each Enterprise maintains its own subdomain structure and independent management.

Organizations

Organizations serve as logical groupings within an Enterprise to help define business structure. An Organization might represent a geographic region (Southern Region, EMEA), a business division (Engine Block Division, Aftermarket Services), a campus, or any other organizational construct that makes sense for your operations.

Organization Capabilities:

• Purely a logical grouping mechanism - Organizations do not enforce data isolation
• Applications belong to Organizations and inherit the organizational context
• Users access Applications within Organizations but interact directly with Applications
• Single physical sites may use multiple Applications within one Organization
• Organizations can be structured however makes sense for your business model

Organization Limits by Deployment:

• Kubernetes Global: Unlimited Organizations supported
• Cloud: Unlimited Organizations supported
• Single Server: Limited to 1 Organization per installation
• Developer: Limited to 1 Organization per installation

Applications (Tenants)

Applications provide the primary data isolation boundary within your Enterprise. Each Application maintains its own data, users, roles, and application configurations, though the platform architecture remains consistent across all Applications.

When to Use Separate Applications:

Environments

Environments represent complete instances of your Fuuz deployment with specific purposes in the development and deployment lifecycle. Each Environment maintains separate data, configurations, and platform versions.

Production Environment:

• Where live operations occur with real transactions and active integrations
• Monthly platform updates after thorough testing in Build and QA
• Available in all deployment models
• URL: [yoursite].fuuz.app (Cloud) or configured domain (Kubernetes/Single Server)

QA Environment:

• Testing ground for user acceptance testing, training, and validation
• Platform updates every couple of weeks
• Available in Kubernetes (as namespace) and Cloud deployments
• Not available in Single Server unless multiple servers are deployed with additional licensing
• URL: qa.[yoursite].fuuz.app (Cloud) or configured domain (Kubernetes)

Build Environment:

• Development workspace for creating and refining applications and workflows
• Nightly platform updates with latest features from engineering team
• Available in Kubernetes (as namespace) and Cloud deployments
• Not available in Single Server unless multiple servers are deployed with additional licensing
• URL: build.[yoursite].fuuz.app (Cloud) or configured domain (Kubernetes)

Database Architecture

All Fuuz deployment models include a fully embedded MongoDB database with a proprietary ORM layer and GraphQL API for data persistence and retrieval. Customers can also bring their own databases and leverage them through built-in connectors within Data Flows.

Access Management

Access Types:

• App Admin: Full administrative access to application configuration and user management
• Developer: Access to design tools (Screen Designer, Data Model Designer, Data Flow Designer, Document Designer)
• Web Access: Standard user access to applications with role-based permissions

Roles:

• Provide granular control over specific data and operations within applications
• Control create, read, update, and delete permissions on individual Data Models
• Required for users with Web Access to interact with applications and data
• Can be assigned to App Admins and Developers for testing purposes

Platform Design Tools

Users with Developer access can utilize the Fuuz App Designer suite:

• Screen Designer: Create user interfaces using JSONata expressions for dynamic behavior
• Data Model Designer: Define data structures, relationships, and validation rules
• Data Flow Designer: Build integration workflows and business logic using pre-built connectors
• Document Designer: Create report templates and document layouts

The platform uses JSONata with custom bindings and JavaScript as primary scripting languages. In Screen Designer, JSONata is used directly for dynamic expressions. Within Web Flows (part of Data Flows), developers can leverage JSONata, JavaScript, or other languages through Open API integrations with external services.

Integration Capabilities

The Fuuz Platform includes comprehensive integration capabilities:

• Data Flows (iPaaS): Pre-built connectors for enterprise software systems including SAP, Oracle, SuccessFactors, ADP, and others
• Gateway: Drivers for industrial equipment including PLCs, databases, printers, and folder monitoring (bundled with in-house deployments, separate for Cloud)
• Database Connectors: Built-in connectors to leverage customer-provided databases alongside the embedded MongoDB

6. Resources

Related Articles

Getting Started:

• Fuuz Platform Introduction and Navigation
• First Login and Account Setup
• Understanding the Fuuz User Interface

Access Management:

• Enterprise User Management
• Understanding Access Types and Roles
• Access Control Policies and Security
• Managing App Access Requests

Administration:

• Enterprise Admin Overview
• Application Administrator Guide
• Organization and Application Management
• Package Installation and Deployment

Development:

• Screen Designer Guide
• Data Model Designer Guide
• Data Flow Designer Guide
• Document Designer Guide
• JSONata Expression Reference

Integration:

• Data Flow Connectors Overview
• Gateway Configuration and Device Drivers
• Enterprise System Integration Patterns
• API Integration with External Services

External Resources

• Fuuz Website: https://fuuz.com
• Sales Team: Contact for information on deployment options, licensing, and current offerings
• Support: Refer to platform support documentation for SLA information and support contacts

7. Troubleshooting

8. Revision History