FlowX Database

What is FlowX Database?

FlowX Database (FlowX DB) is a persistence layer that allows you to store structured data independently of process instances. This enables you to:

Share data between different process instances
Store and retrieve data across multiple processes
Create a persistent data store within the FlowX ecosystem
Access structured data without directly interacting with external systems

FlowX Database is powered by the nosql-db-runner microservice, which provides MongoDB functionality within the FlowX ecosystem. This service supports both native MongoDB and Azure Cosmos DB (MongoDB API), enabling you to choose the database backend that best fits your infrastructure needs while maintaining FlowX’s workflow integration capabilities.For more information about the nosql-db-runner service and CosmosDB considerations, see the NoSQL DB Runner documentation.

Key concepts

Data Sources
Collections
Operations

In the FlowX platform, Data Sources represent connections to different data repositories. With the introduction of FlowX Database, there are now two types of data sources available in the Integration Designer:

Data Source Type	Description
RESTful System	Traditional integration with external REST APIs
FlowX Database	Connection to the internal FlowX Database for data persistence

Each FlowX Database data source represents a collection in the underlying MongoDB database.

Operations define the actions you can perform on a collection. FlowX Database supports the full range of essential MongoDB operations:

Operation	Description	MongoDB Docs
`find`	Retrieve multiple documents based on criteria	MongoDB find()
`findOne`	Retrieve a single document	MongoDB findOne()
`insertOne`	Add a single document	MongoDB insertOne()
`insertMany`	Add multiple documents at once	MongoDB insertMany()
`updateOne`	Modify a single document	MongoDB updateOne()
`updateMany`	Modify multiple documents at once	MongoDB updateMany()
`deleteOne`	Remove a single document	MongoDB deleteOne()
`deleteMany`	Remove multiple documents at once	MongoDB deleteMany()

Each operation is configured with specific parameters that determine how it interacts with the data.

Prerequisites

Before working with FlowX Database, you should have a solid understanding of:

MongoDB Fundamentals

Basic knowledge of MongoDB operations, document structure, and query syntax

JSON Structure

Understanding of JSON payloads and data formatting

CRUD Operations

Familiarity with Create, Read, Update, and Delete operations in database systems

Query Modifiers

Knowledge of query parameters like filters, sorting, projection, and pagination

If you’re new to MongoDB, we recommend reviewing the MongoDB Manual before working with FlowX Database operations.

Benefits of FlowX Database

Data Sharing

Share data between different process instances, enabling more complex workflows and business scenarios

Independence

Store data structured according to your needs, independent of external systems

Extended Use Cases

Enable new business cases that require persistent data across multiple processes

Simplified Integration

Reduce the need for creating custom connectors to external systems for basic data persistence

Native Integration

Integrate with workflows through the existing workflow designer

Complete CRUD Operations

Perform all standard Create, Read, Update, and Delete operations on your data

Bulk Operations

Handle multiple documents efficiently with insertMany, updateMany, and deleteMany operations

Flexible Querying

Use MongoDB’s powerful query syntax to filter, sort, and project your data

How to use FlowX Database

Creating a collection

Access Data Sources

Navigate to the ‘Integrations’ section in the left sidebar of FlowX Designer, then click on ‘Data Sources’.

Accessing Data Sources in the navigation menu

Add a new Data Source

Click the ”+” button to add a new Data Source. In the “Add Data Source” dialog, select “FlowX Database” from the dropdown list.

Adding a new FlowX Database data source

Configure the collection

Provide a name and description for your collection. The name will be used to identify this database collection in your workflows.

Data Model Required: You must have a data model defined before creating a FlowX Database collection. The data model becomes the schema for your database collection and defines the structure of documents that will be stored.

Configuring the collection

Schema Definition: Define the schema for your collection (the selected schema enhances auto-completion but does not enforce validation during insert or update)
Partitioning Key: The attribute used to partition data in your collection. By default, this is set to the id attribute, but you can specify a different field based on your data model.

Create the collection

Click “Create” to save the collection in FlowX Database. Your new collection will appear in the Data Sources list with the type “FlowX Database”.

Each FlowX Database data source represents a collection in the underlying MongoDB database. When you create a new data source with the FlowX Database type, you’re essentially creating a new collection where your documents will be stored.

Viewing collection data

Navigate to collection

Go to the collection you want to view in the ‘Data Sources’ section.

Access Documents tab

Click the ‘Documents’ section within the collection.

Browse documents

You’ll see a listing of currently saved documents in the collection.

Viewing documents in a FlowX Database collection

Search and filter

Use the search functionality to find specific documents in the collection. You can add queries to filter documents, sort them, and use projections to choose what content from each entry you want to see.

Searching and filtering documents in a FlowX Database collection

FlowX Database currently relies on MongoDB’s native sorting behavior for query results. All sorting is performed using MongoDB’s default binary comparison rules.

Managing collection settings

Each FlowX Database collection has a Settings tab where you can configure performance optimizations:

Access Settings tab

Navigate to your collection and click on the ‘Settings’ tab.

Define indexes

Create indexes for your collection to improve query performance. Indexes are particularly important for large collections as they significantly reduce query execution time.

Create indexes on fields that you frequently use in filter conditions, sort operations, or queries to optimize performance.

Defining indexes for a FlowX Database collection

For large collections with thousands of documents, proper indexing is crucial for maintaining good query performance. Consider indexing frequently queried fields before your collection grows large.

Creating database operations

Create operation
Update operation
Delete operation

Access operations list

Navigate to your FlowX Database collection in the Data Sources section.

Create new operation

Click the ”+” button to create a new operation.

Creating a new operation for a FlowX Database collection

Select operation type

Choose the operation type from the dropdown (find, findOne, insertOne, insertMany, etc.).

Selecting the operation type

Name the operation

Give your operation a meaningful name and description that indicates its purpose.

Define the operation parameters

Configure the parameters for your operation based on its type. For example, for a find operation:

Configuring operation parameters

Filter: Define the criteria to match documents
Projection: Select which fields to include in the results
Sort: Specify the sorting order
Skip: For find operations, specify the number of documents to skip
Limit: Set the maximum number of documents to return

Parameter Syntax: When defining operation parameters, remember:

Parameters defined in the operation are referenced using ${parameterName} syntax
Database field names must be in quotes (e.g., "firstName", "customerId")
Parameters don’t need to match your data model exactly - they’re placeholders that get replaced with actual values
Field names in quotes must match exactly what’s stored in the database (same as your data model)

Test the operation

Use the test functionality to verify your operation works correctly.

Testing an operation

Testing Delete Operations: Be extremely careful when testing delete operations (deleteOne and deleteMany) as they will actually remove documents from your collection. Always use test data or ensure you have backups before testing deletion operations in collections with important data.

Save the operation

Click “Save” to add the operation to your collection. It will now be available for use in workflows.

Working with FlowX Database in workflows

Database node in a workflow

FlowX Database integrates directly with the workflow designer through the “Data Source” node type:

Add Data Source node

In your workflow, add a new node and select the ‘DATA_SOURCE’ type.

Configure data source

In the node properties panel:

Data Source node configuration

Choose “FlowX Database” as the system type from the dropdown
Select your collection from the available options
Choose the operation you want to perform (find, findOne, insertOne, insertMany, updateOne, updateMany, deleteOne, deleteMany)

Configure operation parameters

Set the parameters for your selected operation. The available parameters will depend on the operation type:

filter - For find operations, define the criteria to match documents
sort - For find operations, specify the sorting order for results
document - For insert operations, define the document to insert
update - For update operations, define the document to update
delete - For delete operations, define the criteria to match documents
skip - For find operations, specify the number of documents to skip
limit - For find operations, specify the maximum number of documents to return
projection - For find operations, specify the fields to include or exclude in the results

Configuring operation parameters

You can use static JSON or reference process variables using the expression syntax.

Set response key

Specify where the operation result should be stored in the process instance. This makes the data available to subsequent nodes in your workflow.

Example: Using filter parameter in find operation

{
  "age": { "$gt": 30 },
  "status": "active"
}

This filter will return all documents where the age is greater than 30 and the status is “active”.

For more information about MongoDB comparison operators like $gt, see Comparison Query Operators.

Example: Using process variables in parameters

{
  "customerId": "${processInstance.customerData.id}"
}

This filter uses a value from the process instance to find documents matching a specific customer ID.

Learn more about MongoDB query syntax in the Query Documents Tutorial.

MongoDB operations supported

FlowX Database leverages MongoDB’s powerful query capabilities through the nosql-db-runner service, providing pure MongoDB functionality. For detailed information about MongoDB query operators, filters, and syntax, refer to the MongoDB Query and Projection Operators documentation. The following MongoDB operations are supported in FlowX Database. Each tab includes practical examples that you can use as a starting point for your own operations.

Parameters:For complete documentation on find operations and query syntax, see MongoDB db.collection.find().

filter (document, optional): Criteria to match documents. See Query Filter Documents
sort (document, optional): Document specifying the sorting order. See Sort Query Results
skip (integer, optional): Number of documents to skip. See Limit Query Results
limit (integer, optional): Maximum number of documents to return. See Limit Query Results
projection (document, optional): Fields to include or exclude. See Project Fields

Example: List active customers

This example finds all active customers, sorts them by registration date (newest first), limits to 10 results, and returns only specific fields.Operation name: listActiveCustomers

filter
sort
projection
skip
limit

{
  "status": "active"
}

{
  "customerSince": -1
}

{
  "customerId": 1,
  "firstName": 1,
  "lastName": 1,
  "email": 1,
  "status": 1,
  "_id": 0
}

This operation will return up to 10 active customers, with the most recently registered customers first.

Example: Find products by category and price

This example finds products in a specific category within a price range.Operation name: findAffordableElectronics

filter
sort
projection
limit

{
  "category": "electronics",
  "price": { "$gte": 10, "$lte": 100 }
}

{
  "price": 1
}

{
  "productName": 1,
  "price": 1,
  "rating": 1,
  "inStock": 1,
  "_id": 0
}

This operation will return up to 20 electronics products with prices between

10 and

100, sorted from lowest to highest price.

Parameters:For complete documentation on findOne operations, see MongoDB db.collection.findOne().

filter (document, optional): Criteria to match the document. See Query Filter Documents
projection (document, optional): Fields to include or exclude. See Project Fields
sort (document, optional): Document specifying the sorting order. See Sort Query Results

Example: Find customer by ID

This example retrieves a single customer by their unique customer ID.Operation name: findCustomerById

filter
projection

{
  "customerId": "${processInstance.customerId}"
}

{
  "firstName": 1,
  "lastName": 1,
  "email": 1,
  "phone": 1,
  "status": 1,
  "customerSince": 1,
  "address": 1,
  "_id": 0
}

This operation uses a process variable for the customer ID and returns specific customer fields. Since findOne only returns one document, sort is usually unnecessary unless you need the first document matching certain criteria.

Example: Find latest order

This example finds the most recent order for a customer.Operation name: findLatestOrder

filter
sort
projection

{
  "customerId": "${processInstance.customerId}"
}

{
  "orderDate": -1
}

{
  "orderId": 1,
  "orderDate": 1,
  "totalAmount": 1,
  "status": 1,
  "items": 1,
  "_id": 0
}

This operation will find the most recent order for a specific customer by sorting by orderDate in descending order and returning only the first match.

Parameters:For complete documentation on insertOne operations, see MongoDB db.collection.insertOne().

document (document, required): The document to insert. See Insert Documents

Example: Create a new customer

This example inserts a new customer record using data from a process instance.Operation name: createCustomer

document

{
  "customerId": "${processInstance.customerData.id}",
  "firstName": "${processInstance.customerData.firstName}",
  "lastName": "${processInstance.customerData.lastName}",
  "email": "${processInstance.customerData.email}",
  "phone": "${processInstance.customerData.phone}",
  "status": "active",
  "customerSince": "${processInstance.customerData.registrationDate}",
  "address": {
    "street": "${processInstance.customerData.address.street}",
    "city": "${processInstance.customerData.address.city}",
    "state": "${processInstance.customerData.address.state}",
    "zipCode": "${processInstance.customerData.address.zipCode}"
  }
}

This operation creates a new customer document with nested address data, using values from the process instance.

Example: Log a system event

This example logs a system event with static and dynamic data.Operation name: logSystemEvent

document

{
  "eventType": "user_action",
  "action": "${processInstance.actionType}",
  "timestamp": "${processInstance.currentDateTime}",
  "userId": "${processInstance.userId}",
  "details": "${processInstance.actionDetails}",
  "source": "workflow",
  "processId": "${processInstance.id}"
}

This operation creates an event log entry with information about user actions in the system.

Parameters:For complete documentation on insertMany operations, see MongoDB db.collection.insertMany().

documents (array, required): Array of documents to insert. See Insert Documents

Example: Import multiple customers

This example inserts multiple customer records at once, typically from an imported data source.Operation name: importCustomers

documents

[
  {
    "customerId": "CUST001",
    "firstName": "John",
    "lastName": "Doe",
    "email": "[email protected]",
    "status": "active",
    "customerSince": "2025-01-15"
  },
  {
    "customerId": "CUST002",
    "firstName": "Jane",
    "lastName": "Smith",
    "email": "[email protected]",
    "status": "active",
    "customerSince": "2025-01-20"
  },
  {
    "customerId": "CUST003",
    "firstName": "Robert",
    "lastName": "Johnson",
    "email": "[email protected]",
    "status": "inactive",
    "customerSince": "2024-11-05"
  }
]

This operation inserts multiple customer records at once. In a real scenario, you would typically reference a process variable containing the array: {processInstance.importedCustomers}

Example: Create order items

This example creates multiple order items for a single order.Operation name: createOrderItems

documents

[
  {
    "orderId": "${processInstance.orderId}",
    "productId": "${processInstance.items[0].productId}",
    "quantity": "${processInstance.items[0].quantity}",
    "unitPrice": "${processInstance.items[0].price}",
    "subtotal": "${processInstance.items[0].subtotal}"
  },
  {
    "orderId": "${processInstance.orderId}",
    "productId": "${processInstance.items[1].productId}",
    "quantity": "${processInstance.items[1].quantity}",
    "unitPrice": "${processInstance.items[1].price}",
    "subtotal": "${processInstance.items[1].subtotal}"
  }
]

This operation creates multiple order item records for a single order. In practice, you would use {processInstance.items} directly if your process data model matches the database structure.

Parameters:For complete documentation on updateOne operations, see MongoDB db.collection.updateOne().

filter (document, required): Criteria to match the document to update. See Query Filter Documents
update (document, required): Update operations to apply. See Update Operators

Example: Update customer status

This example updates a customer’s status and records when the change occurred.Operation name: updateCustomerStatus

filter
update

{
  "customerId": "${processInstance.customerId}"
}

{
  "$set": {
    "status": "${processInstance.newStatus}",
    "lastUpdated": "${processInstance.currentDate}",
    "statusReason": "${processInstance.statusChangeReason}"
  }
}

This operation updates a customer’s status along with the reason and timestamp.

Example: Update order with tracking information

This example updates an order with shipping details and increments a counter.Operation name: updateOrderShipping

filter
update

{
  "orderId": "${processInstance.orderId}"
}

{
  "$set": {
    "status": "shipped",
    "shippingDetails": {
      "carrier": "${processInstance.shippingData.carrier}",
      "trackingNumber": "${processInstance.shippingData.trackingNumber}",
      "estimatedDelivery": "${processInstance.shippingData.estimatedDelivery}"
    },
    "lastUpdated": "${processInstance.currentDateTime}"
  },
  "$inc": {
    "statusUpdates": 1
  }
}

This operation updates an order with shipping information, sets the status to “shipped”, and increments a counter tracking the number of status updates.

Parameters:For complete documentation on updateMany operations, see MongoDB db.collection.updateMany().

filter (document, required): Criteria to match documents to update. See Query Filter Documents
update (document, required): Update operations to apply. See Update Operators

Important Update Behavior: When using update operations without the $set operator, the entire document will be replaced with the new data. This means any fields not included in your update payload will be removed from the document.For example, if a document has id, name, and email, and you update only the name field without using $set, the email field will be deleted. Always use the $set operator to update specific fields while preserving others.

Example: Deactivate inactive customers

This example updates the status of multiple customers based on their last activity date.Operation name: deactivateInactiveCustomers

filter
update

{
  "lastActivityDate": { "$lt": "${processInstance.thresholdDate}" },
  "status": "active"
}

{
  "$set": {
    "status": "inactive",
    "deactivationDate": "${processInstance.currentDate}",
    "deactivationReason": "inactivity"
  }
}

This operation identifies all active customers whose last activity date is older than a threshold date and marks them as inactive.

Key MongoDB Operators: This example uses $lt (less than) for date comparison and $set to update specific fields without affecting other customer data. The $set operator is essential for partial document updates.

Example: Update multiple customers by ID list

This example demonstrates updating multiple specific customers using the $in operator.Operation name: updateCustomersByIdList

filter
update

{
  "customerId": { "$in": ["${processInstance.customerIds}"] }
}

{
  "$set": {
    "lastContactedDate": "${processInstance.currentDate}",
    "contactMethod": "${processInstance.contactMethod}",
    "notes": "${processInstance.contactNotes}"
  }
}

This operation updates all customers whose IDs are in the provided list, setting contact information for multiple customers at once.

Standard MongoDB Pattern: The combination of $in for filtering and $set for updating is a standard pattern in MongoDB. Use $in when you need to match against a list of values, and always use $set to avoid replacing the entire document.

Example: Apply discount to products

This example applies a discount to all products in a specific category.Operation name: applySeasonalDiscount

filter
update

{
  "category": "${processInstance.discountCategory}",
  "onSale": false
}

{
  "$mul": {
    "price": ${processInstance.discountFactor}
  },
  "$set": {
    "onSale": true,
    "discountPercent": "${processInstance.discountPercent}",
    "saleEndDate": "${processInstance.saleEndDate}"
  }
}

This operation applies a discount to all products in a specific category by multiplying the price by a discount factor (e.g., 0.8 for 20% off) and setting sale-related fields.

MongoDB Operators in Action: This example demonstrates essential MongoDB operators:

$mul multiplies the price by the discount factor
$set updates specific fields without affecting others
In the filter, you could use $in to target multiple categories: "category": {"$in": ["electronics", "clothing"]}

Parameters:For complete documentation on deleteOne operations, see MongoDB db.collection.deleteOne().

filter (document, required): Criteria to match the document to delete. See Query Filter Documents

Example: Delete a customer record

This example removes a single customer record by ID.Operation name: deleteCustomer

filter

{
  "customerId": "${processInstance.customerIdToDelete}"
}

This operation deletes a customer record with the specified ID. Make sure to implement proper validation and confirmation before executing deletion operations.

Example: Remove abandoned cart

This example removes an abandoned shopping cart after confirmation.Operation name: removeAbandonedCart

filter

{
  "cartId": "${processInstance.cartId}",
  "status": "abandoned",
  "lastUpdated": { "$lt": "${processInstance.thresholdDate}" }
}

This operation deletes a shopping cart that’s been marked as abandoned and hasn’t been updated since a specific date.

Parameters:For complete documentation on deleteMany operations, see MongoDB db.collection.deleteMany().

filter (document, required): Criteria to match documents to delete. See Query Filter Documents

Example: Purge temporary records

This example removes all temporary records older than a specified date.Operation name: purgeTemporaryRecords

filter

{
  "status": "temporary",
  "createdDate": { "$lt": "${processInstance.purgeThresholdDate}" }
}

This operation removes all documents marked as “temporary” that were created before a specific date. Use with caution as this will delete all matching records.

Example: Clear completed tasks

This example removes all completed tasks for a specific user.Operation name: clearCompletedTasks

filter

{
  "assignedTo": "${processInstance.userId}",
  "status": "completed",
  "completedDate": { "$lt": "${processInstance.olderThanDate}" }
}

This operation removes all tasks that are marked as completed, were assigned to a specific user, and were completed before a certain date.

Always use caution with update and delete operations, especially those that affect multiple documents (updateMany, deleteMany). Always include specific filter criteria to avoid unintended changes to your data.

Real-world example: Customer management system

This example demonstrates how a customer management system could use FlowX Database to persist and share customer data across different processes.

Setup

Create Customer collection

Create a new FlowX Database data source named “Customers”.

Define operations

Create the following operations:

findCustomer
createCustomer
updateCustomerStatus
listActiveCustomers

Operation Type: findOne

Parameters:

{
  "filter": {
    "customerId": "${processInstance.customerId}"
  },
  "projection": {
    "firstName": 1,
    "lastName": 1,
    "email": 1,
    "phone": 1,
    "status": 1,
    "customerSince": 1,
    "_id": 0
  }
}

This operation retrieves a single customer by their customerId, returning only selected fields.

Operation Type: insertOne

Parameters:

{
  "document": {
    "customerId": "${processInstance.customerData.id}",
    "firstName": "${processInstance.customerData.firstName}",
    "lastName": "${processInstance.customerData.lastName}",
    "email": "${processInstance.customerData.email}",
    "phone": "${processInstance.customerData.phone}",
    "status": "active",
    "customerSince": "${processInstance.customerData.registrationDate}",
    "address": {
      "street": "${processInstance.customerData.address.street}",
      "city": "${processInstance.customerData.address.city}",
      "state": "${processInstance.customerData.address.state}",
      "zipCode": "${processInstance.customerData.address.zipCode}"
    }
  }
}

This operation inserts a new customer document using data from the process instance.

Operation Type: updateOne

Parameters:

{
  "filter": {
    "customerId": "${processInstance.customerId}"
  },
  "update": {
    "$set": {
      "status": "${processInstance.newStatus}",
      "lastUpdated": "${processInstance.currentDate}"
    }
  }
}

This operation updates a customer’s status and sets the lastUpdated timestamp.

Operation Type: find()

Parameters:

{
  "filter": {
    "status": "active"
  },
  "sort": {
    "customerSince": -1
  },
  "limit": 50,
  "projection": {
    "customerId": 1,
    "firstName": 1,
    "lastName": 1,
    "email": 1,
    "status": 1,
    "_id": 0
  }
}

This operation retrieves a list of active customers, sorted by registration date (newest first), limited to 50 results.

Customer support process

In this process:

Support agent enters the customer ID
A Data Source node retrieves the customer details from the Customers collection
Customer information is displayed to the agent
After resolving the issue, the support agent updates the customer status
Another Data Source node updates the customer record in the database

Benefits demonstrated

This example shows how FlowX Database:

Enables data persistence across multiple processes
Provides a single source of truth for customer data
Simplifies data retrieval and updates
Eliminates the need for external systems to store basic customer information

Limitations and considerations

Show Current limitations of FlowX Database

Multiple versions of documents are stored in the collection. Upon retrieval, all data that fits the filter conditions will be retrieved regardless of version.

No automatic migration capabilities are available. Any migration will need to be done manually by the DevOps team.

In the initial release, FlowX Database does not support transactions across multiple collections.

Data validation based on a schema is not yet supported.

Best practices

Design before implementation: Plan your collections and operations carefully before implementation.

Keep document structure simple: Avoid deeply nested structures for better performance and easier querying.

Use meaningful names: Choose clear names for collections and operations.

Limit document size: Keep individual documents under 16MB for optimal performance.

Test operations thoroughly: Use the testing functionality to ensure operations work as expected.

Consider indexing: For large collections, consider indexing frequently queried fields.

Provide default values: Ensure all data types have default values (e.g., empty string for null, 0 for integers).

Troubleshooting

Operation fails with filter error

Problem

Find operation fails with an error related to the filter syntax.

Solution

Check your filter syntax to ensure it follows MongoDB query syntax. Common issues:

Missing quotes around string values
Incorrect operator syntax (e.g., using > instead of $gt)
Mismatched brackets or braces

Documents not appearing in results

Problem

Your query doesn’t return expected documents.

Solution

Verify your filter conditions are correct
Check if documents actually exist in the collection
Try a more general query to see if documents are returned
Check if field names in your filter match exactly with the document structure

Performance issues with large result sets

Problem

Queries returning large amounts of data are slow.

Solution

Add pagination using skip and limit parameters
Add more specific filter conditions
Use projection to return only needed fields
Consider indexing frequently queried fields

Insert operation fails

Problem

Insert operation fails with an error.

Solution

Check that your document JSON is valid
Ensure document size is under 16MB
Verify all required fields are present
Check for any unique constraint violations

Data Search

Learn about the Data Search service for indexing and searching process data.

Integration Management

Understand how to manage integrations with external systems.

Workflow

See how workflows can interact with data sources.

Process Data Model

Learn about data models used within processes.

Summary

FlowX Database provides a powerful persistence layer that enables you to store and share data across different processes and projects. By leveraging MongoDB’s capabilities through the nosql-db-runner service, FlowX Database offers:

Flexible data storage for any structured data
Data sharing between process instances
Integration with workflows
Independence from external systems for basic data persistence

MongoDB learning resources

To get the most out of FlowX Database, familiarize yourself with MongoDB concepts and operations:

MongoDB Manual

Complete MongoDB documentation covering all operations and concepts

Query Tutorial

Learn how to construct effective MongoDB queries

Update Operations

Master document update operations and operators

Data Modeling

Best practices for structuring your data in MongoDB

FAQs

When should I use Data Search vs. FlowX Database?

FlowX Database does not replace Data Search. Each serves different purposes in the platform.

FlowX Database
Data Search

Acts as a persistent data store
Optimized for CRUD operations
Stores structured business data
Designed for sharing data across processes
Uses MongoDB as the underlying technology (via nosql-db-runner service)

What types of data should I store in FlowX Database?

FlowX Database is designed for operational data with temporary character, including:

Dashboard data: Aggregated information for reporting and visualization. For example, create operations that gather information from multiple processes and pull all the data to calculate sums, averages, or other metrics for executive dashboards
Cached data: Frequently accessed information that changes periodically, such as:
- Daily exchange rates for financial calculations
- Product catalogs that update weekly
- Configuration data that multiple processes need to access
Internal operational comments: Information that needs to be shared between users but shouldn’t reach business systems, such as:
- Internal comments in a client’s profile for bank tellers
- Notes and annotations that support decision-making across different process instances
- Communication logs between team members working on the same case
Shared process data: Information that needs to be accessed across multiple process instances - this solves the key pain point of data sharing between different process instances
Temporary operational data: Working data that supports business processes but isn’t part of your permanent records

Important: FlowX Database should not become your primary book of records or system of record. Use it for operational data that supports your processes, not for critical business data that requires long-term retention and governance.

Can I share FlowX Database collections between different projects?

Why doesn't FlowX Database support automatic data migration?

FlowX Database intentionally does not provide automatic migration capabilities for several important reasons:

Data integrity: Many documents need to remain in their original format to maintain historical accuracy and compliance requirements
Process dependencies: Existing processes may depend on specific data structures, and automatic changes could break functionality
Business context: Data migration often requires business logic and context that automated systems cannot provide
Risk management: Manual migration allows for proper testing and validation before changes are applied

When you need to modify data structures, plan for manual migration processes with proper testing and validation procedures handled by your DevOps team.

Can I store different types of documents in the same collection?

No, this is strongly discouraged. Each collection should contain documents with the same structure and purpose.DON’T DO IT - Mixing different document types in one collection can lead to:

Query complexity: Filtering becomes more complex when documents have different schemas
Performance issues: Indexes become less effective with mixed document types
Maintenance problems: Updates and changes become harder to manage
Data consistency: Harder to ensure data quality and validation

Instead, create separate collections for each document type, even if they seem related. This follows MongoDB best practices and keeps your data organized and manageable.

How does FlowX Database solve cross-process data sharing?

What's the relationship between FlowX Database and the nosql-db-runner service?

FlowX Database is powered by the nosql-db-runner microservice, which provides:

Pure MongoDB functionality: Direct access to MongoDB operations within the FlowX ecosystem
Native integration: Connection between FlowX workflows and MongoDB operations
Scalable architecture: A dedicated service that can be scaled independently based on database operation needs

The nosql-db-runner acts as the bridge between FlowX’s workflow engine and MongoDB, enabling you to leverage MongoDB’s full power while maintaining FlowX’s process orchestration capabilities.

Getting Started

Platform overview

FlowX.AI Designer

Building projects

Building blocks

Platform deep dive

API reference

​What is FlowX Database?

​Key concepts

​Prerequisites

MongoDB Fundamentals

JSON Structure

CRUD Operations

Query Modifiers

​Benefits of FlowX Database

Data Sharing

Independence

Extended Use Cases

Simplified Integration

Native Integration

Complete CRUD Operations

Bulk Operations

Flexible Querying

​How to use FlowX Database

​Creating a collection

​Viewing collection data

​Managing collection settings

​Creating database operations

​Working with FlowX Database in workflows

​MongoDB operations supported

​Real-world example: Customer management system

​Limitations and considerations

​Best practices

​Troubleshooting

​Related features

Data Search

Integration Management

Workflow

Process Data Model

​Summary

​MongoDB learning resources

MongoDB Manual

Query Tutorial

Update Operations

Data Modeling

​FAQs

What is FlowX Database?

Key concepts

Prerequisites

Benefits of FlowX Database

How to use FlowX Database

Creating a collection

Viewing collection data

Managing collection settings

Creating database operations

Working with FlowX Database in workflows

MongoDB operations supported

Real-world example: Customer management system

Limitations and considerations

Best practices

Troubleshooting

Related features

Summary

MongoDB learning resources

FAQs