Article Type: Configuration / How-To
Audience: Application Designers, Developers, Partners
Module: Screen Designer
Applies to Versions: 2024.1+
Estimated Time: 15-20 minutes
JSON Form Fields provide a quick and efficient way to create simple modal popup forms without designing a full screen. By defining form inputs using JSON configuration within action steps, you can rapidly build create and edit dialogs for your end users. This approach is ideal for straightforward data entry scenarios requiring only basic inputs in a single-column layout.
JSON Form Fields are typically used in action button configurations and table column menu features, allowing you to define popup forms directly within the action definition rather than creating separate screen designs.
Fuuz offers multiple ways to present forms to users. Understanding when to use each approach ensures optimal user experience and maintainability.
| Aspect | JSON Form Fields (Form Action) | Screen Dialogue |
|---|---|---|
| Best For | Quick, simple forms with few fields | Complex workflows, advanced layouts, multi-step processes |
| Layout | Single column only | Full canvas control (multi-column, sections, tabs) |
| Input Types | Text, number, date, datetime, time, select, multiline, markdown | All input types plus charts, tables, visualizations, custom components |
| Data Operations | Simple mutations (single record create, edit, delete) | Complex mutations, nested records, mass creates, web flows |
| Workflow Integration | Limited to simple action steps | Full web flow integration, conditional logic, multi-step approvals |
| Setup Time | Minutes (JSON configuration) | Longer (full screen design) |
| Reusability | Embedded in action (less reusable) | Separate screen (highly reusable across multiple actions) |
| Action Type | Form |
Screen Dialogue |
Select or add an element that will trigger the popup form:
Basic Text Input Example:
[
{
"name": "name",
"description": "Enter the item name",
"label": "Name",
"type": "text",
"dataPath": "name",
"disabled": false,
"validation": {
"required": true
},
"defaultValue": "",
"query": {
"fields": ["name"]
}
}
]
Add additional field objects to the array, separated by commas:
[
{
"name": "name",
"label": "Name",
"type": "text",
"dataPath": "name",
"validation": { "required": true }
},
{
"name": "description",
"label": "Description",
"type": "multiline",
"dataPath": "description",
"validation": { "required": false }
},
{
"name": "quantity",
"label": "Quantity",
"type": "number",
"dataPath": "quantity",
"defaultValue": 1,
"validation": { "required": true }
},
{
"name": "dueDate",
"label": "Due Date",
"type": "date",
"dataPath": "dueDate",
"validation": { "required": false }
}
]
| Property | Required | Description |
|---|---|---|
name |
Yes | Unique identifier for the field; should match your data model field name |
label |
Yes | Display label shown to the user |
type |
Yes | Input type (see Available Field Types below) |
dataPath |
Yes | Path to the data model field to update |
description |
No | Help text displayed to users (often shown on hover or in help mode) |
disabled |
No | Set to true to make field read-only; default is false |
defaultValue |
No | Initial value for the field; user can change unless disabled |
validation |
No | Validation rules object (e.g., { "required": true }) |
query |
No | Query configuration specifying which data model fields to include |
| Type | Description | Use Case |
|---|---|---|
text |
Single-line text input | Names, titles, short text |
multiline |
Multi-line text area | Descriptions, notes, comments |
markdown |
Markdown-enabled text editor | Rich text content, formatted documentation |
number |
Numeric input | Quantities, amounts, counts |
date |
Date picker (date only) | Due dates, effective dates, birthdays |
datetime |
Date and time picker | Scheduled events, timestamps, appointments |
time |
Time picker (time only) | Shift times, daily schedules |
select |
Dropdown selection | Status, category, predefined options |
color |
Color picker with color wheel | Status colors, category colors, UI display colors |
The color input type provides a color wheel picker for users to select hex color values. This is useful for allowing end users to configure display colors for statuses, categories, or other UI elements.
{
"name": "color",
"description": "Color to be used in UI for display purposes",
"label": "Color",
"type": "color",
"disabled": false,
"dataPath": "color",
"validation": {
"required": false
},
"defaultValue": "#cccccc",
"query": {
"fields": ["color"]
}
}#FF5733). You can use these values directly in conditional formatting for table cells, status indicators, or any UI element that supports color styling. See the Table Column Conditional Formatting article for usage examples.
You can incorporate dynamic behavior into JSON form fields using stringified transforms:
Scenario: Add a "Create New Task" button to a task list table that opens a simple form with name, description, and due date.
Why JSON Form: Only 3 fields, single record creation, no complex workflow, no conditional logic.
[
{
"name": "name",
"label": "Task Name",
"type": "text",
"dataPath": "name",
"validation": { "required": true }
},
{
"name": "description",
"label": "Description",
"type": "multiline",
"dataPath": "description"
},
{
"name": "dueDate",
"label": "Due Date",
"type": "date",
"dataPath": "dueDate"
}
]
Scenario: Column menu action to quickly edit a record's status and notes directly from the table.
Why JSON Form: Simple edit operation, 2 fields, no workflow integration needed.
Scenario: An approval workflow that requires supervisor signature, comments, displays related documents, and triggers notifications.
Why Screen Dialogue: Requires web flow integration, displays additional data (documents), has conditional logic based on approval outcome, involves multiple related records.
Scenario: Import or create multiple inventory items at once with validation against existing records.
Why Screen Dialogue/Separate Screen: Mass create operations, nested mutations, complex validation requirements exceed modal scope.
Scenario: Order entry requiring customer selection, multiple line items, shipping configuration, and payment processing.
Why Separate Screen: Complexity exceeds what a modal should handle; requires tables for line items, multiple sections, and extensive workflow logic.
| Issue | Cause | Solution |
|---|---|---|
| Form doesn't display | JSON syntax error in form fields configuration | Validate JSON structure; check for missing commas, brackets, or quotes |
| Data not saving | Incorrect dataPath or name doesn't match data model |
Verify field names match your data model exactly (case-sensitive) |
| Field type not rendering correctly | Invalid or unsupported type value | Use supported types: text, multiline, markdown, number, date, datetime, time, select |
| Validation not working | Incorrect validation object structure | Ensure validation is an object: "validation": { "required": true } |
| Default value not appearing | Existing record data overrides default | Default values apply to new records; existing records use their current values |
| Need more complex layout | JSON Form Fields only support single-column layout | Use Screen Dialogue action type to open a fully designed screen as a modal |
| Version | Date | Editor | Description |
|---|---|---|---|
| 1.0 | 2023-10-09 | Craig Scott | Initial Release - Text input example |
| 2.0 | 2025-01-11 | Craig Scott | Added comparison guide, field types reference, use cases, and Screen Dialogue guidance |