> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Project data model
> Define reusable data types at the project level to ensure consistency across processes
## What is a project data model?
The Project Data Model (PDM) lets you define reusable data types at the project level. These data types propagate to the process data models, ensuring data consistency across your FlowX.AI applications, including in Reusable Functions, Persistence Layer schemas, and other components.
With PDM, you create a centralized data structure that serves as the foundation for all processes within your project. This ensures that core data types like Customer, Product, or Document maintain consistent definitions throughout your application.
## Key concepts
> [tab] Data Model Types
>
> FlowX.AI supports several data model layers, each serving different purposes:
>
> | Data Model Layer | Description |
> | - | - |
> | Process Data Model | Can use data types defined in the Project Data Model or Library Data Model. |
> | Project Data Model (PDM) | Defines data types that can be reused across processes and other resources within the project |
> | Library Data Model | Defined within a library. Allows data types to be reused across multiple projects, promoting standardization. |
>
> 
> [tab] Data Types & Attributes
>
> A **data type** defines the structure of a particular set of data. For example, a `Customer` data type might contain attributes like `name`, `email`, and `address`.
>
> An **attribute** is an individual property of a data type that specifies its data structure.
>
> Data types and attributes can be categorized based on their usage:
>
> * **Used/Unused**: A data type or attribute is considered "used" when it's incorporated into the structure of another data type.
> * **Referenced/Unreferenced**: Refers to data types or attributes from the Project Data Model being used within a Process Data Model or a UI Template.
>
> 
## Benefits of project data model
> [card] Consistency
>
> Ensures data structure consistency across multiple processes and resources
> [card] Reusability
>
> Define once, use many times across processes, business rules, and other components
> [card] Efficiency
>
> Reduces development time by eliminating duplicate definitions
> [card] Maintainability
>
> Centralized management of data structures
> [card] Standardization
>
> Promotes the use of common data structures across projects
## How to use the project data model
### Access the project data model
**1. Open FlowX.AI Designer**
Open FlowX.AI Designer.
**2. Navigate to your project**
Select the project where you want to configure the Project Data Model.
**3. Select Data Model**
Select "Project Data Model" from the project menu.
### Define a project data model
**1. Add a new data type**
In the Project Data Model view, click **+** to add a new data type. A confirmation toast notifies you when the data type is created.
**2. Name the data type**
Provide a name for the data type.
**3. Add attributes**
Each data type displays an **Add attribute** button for creating the first attribute. After the first attribute exists, the button appears only on hover over the data type.
When you select an attribute, a **settings side panel** opens on the right where you can configure:
* Attribute name and type (string, number, boolean, object, array, enum)
* Validations, sensitive data, and reporting settings
* Example values for data mapping
### Manage data types
#### Add a data type
1. Click **+** in the Data Types panel.
2. Enter the name and properties of the data type.
3. Use the inline **Add attribute** button on the data type to add attributes.
4. Save changes.
### Edit a data type
**1. Select the data type**
Select the data type in the Project Data Model.
**2. Select an attribute**
Click an attribute to open the **settings side panel** on the right with all configuration options.
**3. Edit the attribute**
Edit the attribute settings as needed. Changes are saved automatically.
## Attribute validations
You can attach validation rules to a data model attribute so that the values held by that attribute follow the constraints you define. Validators are set per attribute from the attribute **settings side panel**, and they travel with the data model wherever it is used, including process data models, reusable functions, and reusable UI templates.
> [!NOTE]
>
> These validators are defined on the **data model attribute** itself. They are different from the [UI Designer validators](https://docs.flowx.ai/6.x/docs/building-blocks/ui-designer/validators.md), which are configured on individual form components inside a UI template.
### Add a validator
**1. Select an attribute**
In the Project Data Model, select an attribute to open the **settings side panel** on the right.
**2. Open the Validations section**
In the side panel, expand the **Validations** section and click **Add validator**.
**3. Choose a validator type**
Select a validator type. Only the validator types that apply to the attribute's type are listed (see [Available validators by attribute type](#available-validators-by-attribute-type)).
**4. Enter a value**
Enter the value the validator checks against. Required field and Email Format take no value; every other validator type takes one. For a date attribute, the Min Date and Max Date values are picked from a date picker.
**5. Save the validator**
Save the validator. It appears in the Validations list for the attribute. Changes to the data model are saved automatically.
> [!NOTE]
>
> You can add at most one validator of each type to an attribute. A type that is already applied no longer appears in the validator list.
### Available validators by attribute type
The validator types offered depend on the attribute's type. Required field is available for every type.
| Attribute type | Available validators |
| - | - |
| String | Required field, Min Length, Max Length, Pattern, Email Format |
| Number | Required field, Min Value, Max Value |
| Boolean | Required field |
| Date | Required field, Min Date, Max Date |
| Enum | Required field |
| Array | Required field, Min Items, Max Items |
| Object | Required field |
| Currency | Required field, Min Amount Value, Max Amount Value, Min Code Length, Max Code Length, Code Pattern (regex) |
> [!NOTE]
>
> For a currency attribute, the Min Amount Value and Max Amount Value validators apply to the amount, while Min Code Length, Max Code Length, and Code Pattern (regex) apply to the currency code.
### What each validator checks
> [accordion] Required field
>
> Requires the attribute to hold a value. Takes no value of its own.
> [accordion] Min Length / Max Length
>
> Sets the minimum or maximum number of characters for a string value. For a currency attribute these apply to the currency code and are labeled **Min Code Length** and **Max Code Length**. The configured limit is shown as a number of characters, for example `3 characters`.
> [accordion] Min Value / Max Value
>
> Sets the lower or upper bound for a numeric value. For a date attribute these are labeled **Min Date** and **Max Date** and the bound is entered as a date. For a currency attribute these are labeled **Min Amount Value** and **Max Amount Value** and the bound is displayed together with the attribute's currency code, for example `100 EUR`.
> [accordion] Pattern
>
> Checks a string value against a regular expression. For a currency attribute this is labeled **Code Pattern (regex)** and validates the currency code.
> [accordion] Email Format
>
> Checks that a string value is a valid email address. Takes no value of its own.
> [accordion] Min Items / Max Items
>
> Sets the minimum or maximum number of items for an array attribute.
> [!WARNING]
>
> When you change an attribute's type, every validator except **Required field** is removed automatically, because the other validators may no longer apply to the new type. Re-add the validators you need after changing the type.
***
### Attribute path
Each attribute displays a **path button** next to its name. Click it to view the full key path and copy it to your clipboard. This is useful when referencing keys in business rules, UI component bindings, or integration mappings.
> [!NOTE]
>
> Changes to data types propagate to all processes referencing them. If a process is using this data type, it will automatically get the updated structure.
>
> > [!WARNING]
> >
> > However, changes do NOT propagate to UI Designer paths, which will need to be adjusted manually.
>
>
### Remove a data type
**1. Select the data type**
Select the data type to remove.
> [!NOTE]
>
> You can either delete an entire object or just a single attribute.
**2. Click remove**
Click the remove button.
**3. Confirm deletion**
You can delete the data type even if it's in use. The system will show you a warning message indicating which processes reference the data type.
> [!WARNING]
>
> If the data type is in use by processes, you will receive a warning message showing which processes reference it. You can still proceed with the deletion, but this may affect the referenced processes.
>
> 
### Working with referenced data types
When a data type from the Project Data Model is used in a Process Data Model:
1. The Process Data Model will display the referenced data type.
2. The referenced data type cannot be modified at the process level.
3. Changes to the data type in the Project Data Model will propagate to all referencing processes.
## Common scenarios
> [tab] Edit a Key
>
> **1. Access PDM**
>
> Navigate to the Project Data Model.
>
> **2. Make changes**
>
> Make changes to an existing key or attribute.
>
> **3. Propagation**
>
> The changes automatically propagate to all processes using that key.
>
> **4. Updates**
>
> Referenced components in processes will be updated to reflect the changes, but UI Designer paths require manual adjustment.
> [tab] Remove a Key
>
> **1. Access PDM**
>
> Navigate to the Project Data Model.
>
> **2. Remove key**
>
> Attempt to remove a key or object.
>
> **3. System check**
>
> System checks if the key is in use by any process.
>
> **4. Result**
>
> A warning modal shows references but allows deletion.
> [tab] Change Type
>
> **1. Access PDM**
>
> Navigate to the Project Data Model.
>
> **2. Change type**
>
> Change the type of an attribute (e.g., from string to boolean).
>
> **3. Confirmation**
>
> System will prompt for confirmation as this might break processes.
>
> **4. Result**
>
> **Incompatible change**: References will be broken and removed from UI templates.
>
> **Compatible change**: No changes to references are required.
### Use the Project Data Model in processes
1. Navigate to a process within your project.
2. Open the Process Data Model.
3. Project data types are available for selection.
4. Select the desired project data type to use in your process.
5. The data type is added to your Process Data Model, maintaining reference to the Project Data Model.
### Work with libraries
#### Integrate Library Data Models
1. Navigate to your project dependencies.
2. Add a library as a dependency. The library must have a build created.
3. Library data types become available in your Project Data Model.
> [!WARNING]
>
> Library data types are not visible by default! You must select the library source in the filter to display them.
> [!TIP]
>
> To filter by library types you can use the "Filter by source" feature.
>
> 
4. You can now use the library data types in your data model.
#### Handle duplicate types from libraries
When multiple libraries contain data types with the same name:
1. Both types will be visible in the Project Data Model with visual indicators.
2. Namespacing functionality will prevent technical issues.
## Configure reporting and sensitive data settings
You can configure reporting and sensitive data settings directly from the attribute settings side panel:
1. Go to the Project Data Model.
2. Select an attribute to open the **settings side panel**.
3. Toggle **Sensitive data** or **Use in Reporting** as needed.
> [!NOTE]
>
> These settings apply to all instances of the attribute across processes.
> [!TIP]
>
> You can also access these settings from the three-dots menu in the upper right corner of the side panel → **Show details**.
## Project Data Model after version commitment
After committing a project version:
1. The Project Data Model becomes read-only.
2. You can still view the diagram and monitor usage.
3. This read-only configuration is available for any configuration on committed versions and applies also to resource data models.
3. To make changes to the data model, you will require a new project version.
## Search and filter
The Project Data Model interface provides tools to help you find and work with your data types:
1. Navigate to the Project Data Model.
2. By default, only project-level types are displayed.
3. Use filters to view library types as well.
4. Use the search function to find specific types by name.
## Update library dependencies
When updating library dependencies:
1. Navigate to the dependencies section.
2. Select the new library version.
3. The system will inform you of any breaking changes to data types.
4. You can decide whether to proceed with the update.
5. If you proceed, changes will propagate to processes according to compatibility rules.
## Real-world example: Insurance claims processing
> [!NOTE]
>
> This example demonstrates how an insurance company uses project data model for their claims processing system.
> [accordion] Core data types in PDM
>
> The insurance company created these data types in their Project Data Model:
>
> 
>
> 1. **Customer**
> * `customerId`: string
> * `firstName`: string
> * `lastName`: string
> * `dateOfBirth`: date
> * `contactInformation`: ContactInfo (reference)
> * `policyNumbers`: array of string
> * `customerSince`: date
> * `riskProfile`: RiskProfile (reference)
> * *Settings*: Sensitive data = True, Used in reporting = True
> 2. **ContactInfo**
> * `email`: string
> * `phone`: string
> * `address`: Address (reference)
> * *Settings*: Sensitive data = True, Used in reporting = False
> 3. **Claim**
> * `claimId`: string
> * `policyNumber`: string (reference to Policy)
> * `claimType`: enum \["Auto", "Property", "Medical", "Liability"]
> * `incidentDate`: date
> * `reportedDate`: date
> * `status`: enum \["New", "Under Review", "Pending Documents", "Approved", "Denied", "Closed"]
> * `estimatedAmount`: number
> * `approvedAmount`: number
> * `documents`: array of Document (reference)
> * *Settings*: Sensitive data = False, Used in reporting = True
> 4. **Document**
> * `documentId`: string
> * `documentType`: string
> * `fileName`: string
> * `fileUrl`: string
> * `uploadDate`: date
> * *Settings*: Sensitive data = False, Used in reporting = False
> [accordion] Process-specific data models
>
> The company created multiple processes using the PDM:
>
> > [tab] Auto Claim Processing
> >
> > **Root**: ClaimProcess
> >
> > 
> >
> > **Data Structure**:
> >
> > * **ClaimProcess** (Process-specific type)
> > * `claim`: Claim (reference from PDM)
> > * `assignedAdjuster`: string
> > * `vehicleInfo`: AutoClaimDetails (reference)
> > * `processingStage`: enum \["Initial Review", "Damage Assessment", "Liability Determination", "Settlement Negotiation", "Payment Processing"]
> > * **AutoClaimDetails** (Process-specific type)
> > * `vehicleMake`: string
> > * `vehicleModel`: string
> > * `vehicleYear`: number
> > * `vin`: string
> > * `accidentLocation`: Address (reference from PDM)
> > * `damageDescription`: string
>
> > [tab] Policy Renewal Process
> >
> > **Root**: RenewalProcess
> >
> > 
> >
> > **Data Structure**:
> >
> > * **RenewalProcess** (Process-specific type)
> > * `customer`: Customer (reference from PDM)
> > * `renewalDate`: date
> > * `premiumChange`: number
> > * `renewalStatus`: enum \["Pending Review", "Offer Generated", "Offer Sent", "Accepted", "Declined", "Expired"]
> [accordion] Example use cases
>
> > [tab] Add an attribute
> >
> >
> >
> > 1. A configurator adds a new attribute `loyaltyTier` to the Customer data type in the PDM.
> > 2. This attribute is an enum \["Bronze", "Silver", "Gold", "Platinum"].
> > 3. The new attribute automatically propagates to all processes using the Customer data type.
> > 4. The Policy Renewal Process now has access to the customer's loyalty tier without any process-level changes.
>
> > [tab] Remove a field
> >
> > 
> >
> > Warning when trying to remove a field in use
> >
> > 1. A configurator tries to remove the `contactInformation` attribute from the Customer data type.
> > 2. The system displays a warning that the attribute is in use by multiple processes.
> > 3. The configurator is prevented from making the change until the references are resolved.
>
> > [tab] Library integration
> >
> > 
> >
> > Using a library-defined Vehicle data type
> >
> > 1. The company uses a "Common Insurance Standards" library with standardized data types.
> > 2. After setting the library as a dependency, they can use the library's "Vehicle" data type in their PDM.
> > 3. When the library updates, the configurator can choose to adopt the changes.
> [accordion] Benefits demonstrated
>
> > [card]
> >
> > This example shows how the Project Data Model:
> >
> > * **Ensures data consistency**: Core entities like Customer and Policy maintain consistent structures across all processes and resources.
> > * **Promotes reusability**: Common data types are defined once and reused in in multiple processes, business rules, and other resources.
> > * **Simplifies changes**: Updates to data types are propagated automatically to all processes.
> > * **Enforces governance**: Sensitive data is marked at the project level for consistent handling.
> > * **Allows flexibility**: Process-specific data can extend the PDM while maintaining core data integrity.
## Export and import
You can export and import project data types to transfer them between projects or environments.
### Exporting
To export project data types:
1. Open the context menu on the Project Data Model page
2. Select **Export**
3. The data types are downloaded as a ZIP file
### Importing
To import project data types:
1. Open the context menu on the Project Data Model page
2. Select **Import**
3. Select the ZIP file exported from another project or environment
4. If data types with the same identifiers already exist, a **Review Resource Identifiers Conflicts** modal appears
5. Choose a strategy for each conflicting data type (or use **Apply to all**):
* **Keep both** - imports the data type as a new copy alongside the existing one
* **Replace** - overwrites the existing data type with the imported version
* **Skip this one** - keeps the existing data type unchanged
6. Click **Continue** to complete the import
> [!NOTE]
>
> Importing is only available for work-in-progress (WIP) project versions. You cannot import into a committed version.
***
## Best practices
> [!TIP]
>
> **Plan before implementation**: Design your Project Data Model before creating processes to ensure consistency.
> [!TIP]
>
> **Always provide example values**: Example values will be used in data mapping and other operations.
> [!TIP]
>
> **Use descriptive names**: Choose clear, descriptive names for data types and attributes.
> [!TIP]
>
> **Document your model**: Add descriptions to data types and attributes for better understanding and for AI agents.
> [!TIP]
>
> **Consider reusability**: Design data types with reusability in mind across processes and resources.
> [!TIP]
>
> **Review impact of changes**: Before modifying data types, check their usage across processes.
> [!TIP]
>
> **Use libraries for cross-project standards**: For data types needed across multiple projects, define them in libraries.
> [!TIP]
>
> **Maintain regularly**: Periodically review and clean up unused data types.
## Limitations
**Current limitations of the Project Data Model**
> [!WARNING]
>
> Custom Data Types from the Project or Library Data Model level cannot be modified at the resource level.
> [!WARNING]
>
> Removing or changing Data Types in use may break resources using it.
> [!WARNING]
>
> Project Data Model becomes read-only after version commitment. This is available for any configuration on commited versions; it applies also for resources data models.
> [!WARNING]
>
> Library builds with breaking changes to Data Types require usage review.
> [!NOTE]
>
> Data Types defined at the Project or Library level can be referenced in the data models of Processes, Reusable Functions, and Reusable UI Templates.
## Troubleshooting
> [accordion] Cannot modify a referenced data type in process
>
> **1. Problem**
>
> You're trying to edit a data type from the PDM within a process, but the fields are read-only.
>
> **2. Solution**
>
> Make changes at the project level instead:
>
> 1. Navigate to the Project Data Model
> 2. Locate and edit the data type
> 3. Save changes
> 4. The changes will propagate to all processes
> [accordion] Cannot delete a data type that is in use
>
> **1. Problem**
>
> You're trying to delete a data type, but receive an error that it's in use.
>
> **2. Solution**
>
> Either:
>
> * Remove all references to the data type first
> * Create a new version of your project to make the change
> [accordion] References broken after type change
>
> **1. Problem**
>
> After changing a data type (e.g., from string to number), references are broken in processes.
>
> **2. Solution**
>
> Review affected processes and update references manually:
>
> 1. Check the warning message that lists affected processes
> 2. Open each process
> 3. Update UI templates or other components that referenced the changed attribute
> [accordion] Library update warning about breaking changes
>
> **1. Problem**
>
> When updating a library dependency, you receive warnings about breaking changes to data types.
>
> **2. Solution**
>
> Carefully review the changes and their impact before proceeding:
>
> 1. Check which data types are affected
> 2. Review how these types are used in your processes
> 3. Decide whether to proceed with the update or maintain the current version
***
## Academy courses
> [card] [Data Model 101 course](https://academy.flowx.ai/explore/data-model-101-0)
>
> Learn attribute types, JSON format, and data modeling fundamentals
> [card] [Handle Dynamic Data course](https://academy.flowx.ai/explore/handle-dynamic-data-flowxai)
>
> Configure dynamic dropdowns and data-driven UI from process data
> [!TIP]
>
> **Academy playground** — explore the [**DataModel101**](https://designer-workshop-51x.playground.flowxai.dev/workspace/00000000-0000-0000-0000-000000000001/projects/248681ec-3ba4-40e1-95ce-60a0856280ff/config/a38b8942-8eaf-41aa-8e80-e32d74bc9273/processes) project for hands-on data modeling examples.
## Related topics
- [Data mappers](https://docs.flowx.ai/6.x/docs/building-blocks/process/data-mappers.md)
- [FlowX.AI 5.1.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.1.x-lts/v5.1.0-october-2025/v5.1.0-october-2025.md)
- [FlowX.AI 5.0.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.0.0-july-2025/v5.0.0-july-2025.md)
- [Reusable UI Templates](https://docs.flowx.ai/6.x/docs/building-blocks/reusable-resources/reusable-ui.md)
- [FlowX.AI 5.7.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.7.0-april-2026/v5.7.0-april-2026.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.