Master Data Table Screen Design Standard

Article Type: Standard / Reference
Audience: Solution Architects, Application Designers, Developers
Module: Fuuz Platform - Application Designer
Applies to Versions: 2025.12+
Template Reference: Table_Screen_Design_Template_0_0_2.json

1. Overview

Master Data table screens provide the primary interface for viewing, filtering, and managing collections of critical business entities that change infrequently but are essential to operations. This design standard defines a comprehensive framework for building filter-and-table data management screens for Master Data, ensuring consistent layouts, optimized performance, and role-appropriate functionality across all Master Data entities in Fuuz applications. Master Data includes foundational business entities such as Products, Customers, Suppliers, Locations, Equipment, Bill of Materials, Users, and other reference data that supports transactional operations.

What is Master Data?

Master Data represents relatively stable, critical business entities that provide context and meaning to transactional operations. These records are created less frequently than transactions but are referenced constantly throughout business processes. Master Data is typically managed by designated data stewards or administrators, though end users may need read access or the ability to request changes.

Examples of Master Data:

• Products: Product catalog, specifications, pricing, images, bill of materials
• Customers: Customer accounts, contacts, addresses, credit terms, preferences
• Suppliers: Vendor information, contacts, payment terms, certifications
• Locations: Sites, buildings, warehouses, workcenters, storage bins
• Equipment: Machines, tools, instruments, vehicles with specifications and maintenance history
• Users/Employees: Personnel records, skills, certifications, assignments
• Materials: Raw materials, components, supplies with specifications

Design Principles

1. Consistency First: All Master Data table screens follow identical layout patterns for predictable user experience across Products, Customers, Equipment, etc.
2. Filter-Then-Act: Users filter to find specific master records, then act upon selections (view details, edit, relate to transactions)
3. Preserve User Context: Layouts remain stable; users customize views via tool panels rather than rebuilding screens
4. Performance Awareness: Screen configuration adapts to Master Data volume characteristics (typically hundreds to thousands of records)
5. Rich Media Support: Master Data screens support images, documents, and rich descriptions to fully represent business entities

Master Data Characteristics

2. Architecture & Data Flow

Template Architecture

The standard Master Data table screen uses a horizontal split layout with a resizable filter panel:

ROOT (Screen)
└── ContainerOuter (Horizontal flex, flexGrow)
    ├── ResizableFilterPanel (0-300px, collapsible)
    │   └── ContainerFilterOuter
    │       ├── ContainerFilterPanelHeader (40px, with Search action)
    │       │   └── BrandSeparator (4px gradient)
    │       └── FormFilterPanel
    │           └── [Filter inputs: Selects, Switches, GraphQL Builder]
    │
    └── ContainerBody (flexGrow, left border #5b30df)
        ├── ContainerTableHeader (40px, action toolbar)
        │   ├── ContainerActionsStandard (Create, Delete)
        │   └── ContainerActionsCustom (Bulk Create, Wiki)
        ├── BrandSeparator (4px gradient)
        └── Table1 (flexGrow)

Visual Layout

┌────────────────────┬──────────────────────────────────────────────┐
│  Filter Panel      │  ContainerBody                               │
│  (Resizable 0-300) │                                              │
│                    │  ┌────────────────────────────────────────┐  │
│  ┌──────────────┐  │  │ ContainerTableHeader (40px)            │  │
│  │ Filter Panel │  │  │ [Create] [Delete] │ [Bulk] [Wiki]      │  │
│  │ [🔍 Search]  │  │  └────────────────────────────────────────┘  │
│  └──────────────┘  │  ════════════════════════════════════════════│
│  ═══════════════   │                                              │
│  ┌──────────────┐  │  ┌────────────────────────────────────────┐  │
│  │ Name/Code    │  │  │                                        │  │
│  ├──────────────┤  │  │              Table1                    │  │
│  │ Category     │  │  │                                        │  │
│  ├──────────────┤  │  │  ☐ │ ⋮ │ [IMG] │ Name   │ Category  │  │
│  │ Status       │  │  │  ☐ │ ⋮ │ [IMG] │ Prod A │ Widget    │  │
│  ├──────────────┤  │  │  ☐ │ ⋮ │ [IMG] │ Prod B │ Component │  │
│  │ Location     │  │  │  ☐ │ ⋮ │ [IMG] │ Prod C │ Assembly  │  │
│  ├──────────────┤  │  │                                        │  │
│  │ ☐ Active Only│  │  │                                        │  │
│  ├──────────────┤  │  └────────────────────────────────────────┘  │
│  │ Advanced     │  │                                              │
│  │ Filters      │  │  Status: 3 selected | 1,247 total records   │
│  └──────────────┘  │                                              │
└────────────────────┴──────────────────────────────────────────────┘

Container Hierarchy

ContainerOuter

Purpose: Primary horizontal layout container for filter panel and main content.

ResizableFilterPanel

Purpose: Collapsible, resizable filter panel that users can adjust or hide.

BrandSeparator

Purpose: 4px visual brand accent between sections using Fuuz gradient.

3. Use Cases

• Product Catalog Management: Browse and manage product master data with images, specifications, pricing, and categorization for manufacturing or retail operations.
• Customer Account Management: View and maintain customer records with contact information, credit terms, delivery addresses, and transaction history for sales and service teams.
• Equipment Registry: Maintain equipment and asset records with specifications, maintenance schedules, locations, and operational parameters for maintenance and operations personnel.
• Supplier Management: Manage vendor master data including contacts, certifications, payment terms, and performance metrics for procurement operations.
• Location Hierarchy: Browse site, building, warehouse, and workcenter master data with hierarchical relationships for logistics and operations planning.
• Bill of Materials Management: Maintain product structure and component relationships with quantities, alternatives, and effectivity dates for engineering and production.
• Material Catalog: Manage raw materials, components, and supplies with specifications, units of measure, and supplier relationships for inventory and purchasing.
• User Administration: Maintain employee and user records with contact details, roles, skills, and certifications for HR and system administration.
• Data Governance: Provide data stewards with tools to maintain data quality, resolve duplicates, standardize attributes, and ensure master data integrity.

4. Screen Details

Auto-Search Configuration

Default to manual search (autoLoad: false) unless the Master Data table contains fewer than 250 records.

{
  "query": {
    "autoLoad": false  // Default for Master Data
  }
}

Filter Panel Standards

Filter Organization Hierarchy

Filters must be organized in this specific order:

1. SelectInput Filters (Top Priority): Maximum 4 select inputs, most commonly used first (Name/Code, Category, Status, Location)
2. Switch/Checkbox Filters (Secondary): Maximum 3 switches (Active Only, Has Image, etc.)
3. GraphQL Advanced Filters (Last): For power users needing complex attribute queries

Typical Master Data Filters

• Name/Code Filter: Primary identifier search (product code, customer name, equipment tag)
• Category/Type Filter: Classification or grouping (product category, customer type, equipment class)
• Status Filter: Active, Inactive, Deprecated, Under Review
• Location Filter: Site, facility, or organizational unit assignment
• Active Only Switch: Toggle to show/hide inactive master records

SelectInput Filter Configuration

{
  "type": "select",
  "height": "80px",
  "width": "100%",
  "variant": "filled",
  "labelFontSize": 12,
  "dataFontSize": 14,
  "dialogMode": "never",
  "isClearable": true,
  "searchPredicate": "contains",
  "stateTracking": "full",
  "optionLimit": 5
}

Filter Actions

Table Configuration

Essential Table Properties

{
  "width": "100%",
  "height": "0px",
  "flexGrow": true,
  "selectable": "multiple",
  "showToolPanels": true,
  "showStatusBar": true,
  "enableGrouping": true,
  "enableCharts": false,
  "showColumnMenu": false,
  "enableRowDragging": false,
  "disableColumnDragging": true,
  "disableDragLeaveHidesColumns": true,
  "masterDetail": false,
  "hideTableHeader": false,
  "rowMultiSelectWithClick": false
}

Query Configuration

{
  "query": {
    "api": "Application",
    "model": "YourMasterDataModel",
    "dataPath": "edges",
    "autoLoad": false,
    "fields": ["id"],
    "dataSubscription": { "enabled": false }
  }
}

Default Sort

Always configure a default sort on the primary identifier column (Name, Code, etc.):

{
  "defaultSort": [
    { "field": "TableColumnName", "direction": "asc" }
  ]
}

Column Standards

Column Layout Order

All Master Data table screens follow strict left-to-right column order:

1. Selection Column (if selectable enabled) — 40px
2. Actions Menu Column (if row actions needed) — 40px
3. Image Column (Master Data specific - product photos, equipment images, etc.)
4. Primary Identifier Column (Name, Code, etc. with linkTarget to detail screen)
5. Descriptive Columns (Description, Category, Type, etc.)
6. Attribute Columns (Status, Location, Owner, specifications)
7. Audit Columns (CreatedAt, CreatedBy, UpdatedAt, UpdatedBy) — always last

Image Column (Master Data Specific)

{
  "label": " ",
  "format": "image",
  "sortable": false,
  "dataPath": "image",
  "editable": false,
  "width": "60px"
}

Primary Identifier Column with Link

{
  "label": "Product Name",
  "format": "text",
  "sortable": true,
  "dataPath": "name",
  "width": "200px",
  "showColumnSuppressMenu": true,
  "linkTarget": {
    "screenId": "product_detail_screen_id",
    "query": { "__transform": "{ \"id\": rowData.id }" }
  }
}

Audit Columns

Always place audit fields at the far right with timezone set to "setting":

// Created At
{
  "label": "Created At",
  "format": "datetime",
  "sortable": true,
  "dataPath": "createdAt",
  "timeZone": "setting"
}

// Created By (with transform for full name)
{
  "label": "Created By",
  "format": "text",
  "sortable": true,
  "dataPath": "createdByUser.id",
  "query": { 
    "fields": ["createdByUser.id", "createdByUser.firstName", "createdByUser.lastName"] 
  },
  "data": { 
    "__transform": "data.createdByUser.firstName & \" \" & data.createdByUser.lastName" 
  }
}

Action Patterns

Table Header Actions for Master Data

Row Actions Menu

{
  "label": " ",
  "format": "menu",
  "sortable": false,
  "dataPath": "actions",
  "width": "40px",
  "menuIcon": "ellipsis-v",
  "iconSize": "small",
  "showColumnSuppressMenu": false,
  "actions": [
    { "text": "View Details", "icon": { "icon": "circle-info", "color": "info" } },
    { "text": "Edit", "icon": { "icon": "pencil", "color": "warning" } },
    { "text": "Copy/Clone", "icon": { "icon": "copy", "color": "info" } },
    { "text": "Delete", "icon": { "icon": "trash", "color": "error" } }
  ]
}

Mass Update Restrictions

5. Technical Details

Master-Detail Pattern for Hierarchical Master Data

When to Use Master-Detail

Use Master-Detail For:

• Clear 1:many hierarchical relationships (Locations with Sub-Locations, Equipment with Components)
• Child data is simple with few columns (Name, Type, Status)
• Users frequently need to see children in context (Product with Variants, Customer with Contacts)
• Children don't require complex editing (view-only or simple inline edits)

Avoid Master-Detail For:

• Many:many relationships (use separate junction screen)
• Complex child data with many fields (create dedicated child management screen)
• Children require complex forms (workflows, validations, multiple tabs)
• Performance concerns (hundreds of children per parent)

Master-Detail Configuration

{
  "masterDetail": true,
  "detailCellRendererParams": {
    "detailGridOptions": {
      "columnDefs": [
        { "field": "childName", "headerName": "Name" },
        { "field": "childType", "headerName": "Type" },
        { "field": "childStatus", "headerName": "Status" }
      ]
    },
    "getDetailRowData": {
      "__transform": "function($params) { $params.successCallback(rowData.children) }"
    }
  }
}

Performance Considerations

Large Master Data Volume Guidelines

Optimization Strategies

1. Create Report Screens: For view-only browsing of large master catalogs, create separate copy without action buttons. Remove all row-level actions to reduce transform overhead on page load.
2. Move Calculations to Custom Fields: Calculate derived values (availability status, inventory quantity, customer lifetime value) ahead of time in the data model and return them via API. Eliminates client-side transform overhead.
3. Limit Initial Columns: Load essential identification columns only (image, name, code, status); let users add detailed attribute columns via tool panel as needed.
4. Implement Server-Side Pagination: For Master Data tables with 10,000+ records, use server-side pagination with page size options (25, 50, 100).
5. Image Optimization: Ensure master data images are properly sized thumbnails (not full-resolution photos) to reduce rendering time.

Naming Conventions

6. Resources

• Fuuz Industrial Operations Platform
• Form Screen Design Standard - Master Data Detail Screens
• Application Designer Documentation
• Data Model Best Practices
• Table_Screen_Design_Template_0_0_2.json

7. Troubleshooting

• Issue: Filter panel doesn't collapse fully • Cause: minSize not set to 0 or filter inputs have fixed width • Fix: Set ResizableFilterPanel minSize: 0; ensure ContainerFilterOuter has no minimum width constraints; set filter inputs width: 100% not fixed pixels
• Issue: Table doesn't fill vertical space • Cause: flexGrow not configured properly • Fix: Set Table height: "0px" with flexGrow: true; set ContainerOuter height: "0px" with flexGrow: true; set ContainerBody width: "0px" with flexGrow: true
• Issue: Search doesn't work • Cause: Action transformation incorrect or table name mismatch • Fix: Verify Search button action: $components.Table1.fn.search(); check table element name matches (Table1); verify filter dataPath matches query parameter structure
• Issue: Selection checkboxes don't appear • Cause: Table selectable not configured or selection column missing • Fix: Set Table selectable: "single" or "multiple"; add selection column as first column; set selection column dataPath: "na"
• Issue: Images don't display in table • Cause: Image format incorrect or dataPath wrong • Fix: Verify image column format: "image"; check dataPath points to image URL or base64 field; ensure image data exists in query fields
• Issue: Date columns show UTC instead of local time • Cause: timeZone not set to "setting" • Fix: Set date/datetime columns timeZone: "setting"; verify date format includes time if needed
• Issue: Table loads slowly with large Master Data set • Cause: Too many transforms, action buttons, or calculations • Fix: Create separate report screen without action buttons; move calculations to custom fields in data model; limit initial columns and let users add via tool panel; implement server-side pagination for 10,000+ records
• Issue: Auto-load enabled causes performance issues • Cause: Auto-loading hundreds/thousands of Master Data records • Fix: Disable autoLoad (set to false); require manual search with filters; only enable autoLoad if Master Data table has fewer than 250 records
• Issue: Link to detail screen doesn't work • Cause: linkTarget configuration incorrect • Fix: Verify linkTarget screenId matches detail screen; check query transform passes correct record ID; ensure detail screen accepts id query parameter
• Issue: Master-Detail expandable rows not working • Cause: masterDetail not enabled or getDetailRowData transform incorrect • Fix: Set table masterDetail: true; verify getDetailRowData transformation returns child records array; check child data exists in parent record query
• Issue: Mass delete affecting transactions • Cause: Master Data records referenced by transaction records • Fix: Implement referential integrity checks before delete; show warning if Master Data has dependent transactions; consider soft delete (status: inactive) instead of hard delete for Master Data

8. Revision History