Search for specific data across process instances using Elasticsearch-powered indexing for fast, precise results.
The Data Search service enables you to find specific data across process instances within your FlowX.AI platform. It uses Elasticsearch to perform fast, indexed searches across process data.
Search by a single field and value
Search using multiple criteria simultaneously
Search across multiple applications
Filter results by process creation dates
Before using the Data Search service, ensure you have:
Elasticsearch Configuration
Kafka Topics
KAFKA_TOPIC_DATA_SEARCH_IN
configured for requestsKAFKA_TOPIC_DATA_SEARCH_OUT
configured for responsesProcess Data
Set up your data process
Create a process that stores searchable data and configure field indexing.
Create a search process
Build a process with Kafka Send/Receive actions for search functionality.
Configure search parameters
Define your search criteria using simple or advanced syntax.
Handle search results
Process the returned data and display results to users.
First, create a process that contains searchable data. Add a Service Task with a business rule:
Critical Step: After creating your data structure, you must configure field indexing in Process Settings → Data Search for the search to work.
Navigate to Process Settings → Data Search and add the field paths you want to search:
Fields that we indexed in our example:
application.client.personalInfo.firstName
application.client.personalInfo.lastName
application.client.personalInfo.email
Create a new process with a Send Message Task:
Configuration:
KAFKA_TOPIC_DATA_SEARCH_IN
Choose your search approach based on your needs:
Use when searching by a single field:
Use when searching by a single field:
Use when searching by multiple criteria (AND logic):
searchKeys
must match for a result to be returned.Search across multiple applications:
Filter by process creation dates:
Add a Receive Message Task with:
KAFKA_TOPIC_DATA_SEARCH_OUT
Success response example:
Parameter | Type | Mandatory | Description | Example |
---|---|---|---|---|
searchKey | String | Yes | Single field path to search | "application.client.personalInfo.lastName" |
value | String | Yes | Value to search for (with searchKey) | "Johnson" |
searchKeys | Array | Yes (if multiple fields) | Multiple field-value pairs (AND logic) | [{"key": "field1", "value": "val1"}] |
processDefinitionNames | Array | Yes | Limit to specific processes | ["client_onboarding"] |
applicationIds | Array | No | Search across applications | ["uuid-1", "uuid-2"] |
states | Array | No | Filter by process states | ["FINISHED", "STARTED"] |
processStartDateAfter | String | No | Include processes after date | "2024-01-01T00:00:00Z" |
processStartDateBefore | String | No | Include processes before date | "2024-12-31T23:59:59Z" |
searchKey (String)
Purpose: The field path to search in for single-field searches.
Usage: Use dot notation to specify the exact path to the field you want to search or a specific key in the payload.
Examples:
"application.client.personalInfo.firstName"
"application.client.address.city"
"application.client.business.industry"
Important: This field must be indexed in Process Settings → Data Search to work.
searchKeys
. Choose one approach.value (String)
Purpose: The exact value to search for when using searchKey
.
Usage: Must match the stored value exactly (case-sensitive).
Examples:
"Johnson"
- searches for exact lastName match"Technology"
- searches for exact industry match"Active"
- searches for exact status matchNote: Only used with searchKey
, not with searchKeys
.
searchKeys (Array)
Purpose: Array of key-value pairs for multi-field searches with AND logic.
Usage: All conditions must match for a result to be returned.
Format:
Example:
searchKey
. Choose one approach.processDefinitionNames (Array)
Purpose: Limit search to specific process definitions.
Default: Searches all processes if omitted.
Usage: Improves performance by narrowing search scope.
Examples:
["client_onboarding"]
- search only in client processes["employee_registration", "contractor_onboarding"]
- search in multiple process typesBest Practice: Always specify to improve search performance.
applicationIds (Array)
Purpose: Search across specific applications.
Default: Searches current application if omitted.
Usage: Enable cross-application searches.
Examples:
["8dd20844-2dc5-4445-83a5-bbbcc82bed5f"]
- search in specific app["app-1-uuid", "app-2-uuid", "app-3-uuid"]
- search across multiple appsUse Case: Useful for consolidated reporting across different business units.
states (Array)
Purpose: Filter results by process instance status.
Default: Returns all states if omitted.
Available States:
"CREATED"
- Process instance created but not started"STARTED"
- Process is currently running"FINISHED"
- Process completed successfully"FAILED"
- Process encountered an error and stopped"TERMINATED"
- Process was manually stopped/cancelled"ONHOLD"
- Process is paused or waiting for external inputExamples:
["FINISHED"]
- only completed processes["STARTED", "ONHOLD"]
- active or paused processes["FAILED", "TERMINATED"]
- processes that didn’t complete normallyBest Practice: Use ["FINISHED"]
for most business searches to get complete data.
processStartDateAfter (String)
Purpose: Include only processes started after the specified date.
Format: ISO 8601 timestamp (YYYY-MM-DDTHH:MM:SSZ
)
Examples:
"2024-01-01T00:00:00Z"
- processes started after Jan 1, 2024"2024-06-15T09:30:00Z"
- processes started after June 15, 2024 at 9:30 AMUse Cases:
"2024-03-01T00:00:00Z"
"2024-05-20T00:00:00Z"
processStartDateBefore (String)
Purpose: Include only processes started before the specified date.
Format: ISO 8601 timestamp (YYYY-MM-DDTHH:MM:SSZ
)
Examples:
"2024-12-31T23:59:59Z"
- processes started before end of 2024"2024-06-30T23:59:59Z"
- processes started before end of June 2024Use Cases:
"2024-01-01T00:00:00Z"
"2024-03-31T23:59:59Z"
Understanding process states is crucial for effective searching:
State | Description | When to Use |
---|---|---|
CREATED | Process instance exists but hasn’t started execution | Rarely used for business searches |
STARTED | Process is actively running | Find ongoing processes, current workload |
FINISHED | Process completed successfully | Most common for business data searches |
FAILED | Process encountered an error | Error analysis, troubleshooting |
TERMINATED | Process was manually cancelled | Audit trails, cancelled applications |
ONHOLD | Process is paused/waiting | Active cases needing attention |
Recommendation: Use ["FINISHED"]
for most business searches to ensure you’re getting complete, reliable data.
The search returns a JSON object with these fields:
result
(Array): List of matching process instances, automatically sorted by processStartDate
in descending order (newest first)
processInstanceUUID
: Unique process identifierstate
: Current process stateprocessStartDate
: When the process starteddata
: The actual process data with your searchable fieldstooManyResults
(Boolean): True if more than 50 results found (limit applied)success
(Boolean): Whether the search completed successfullyerrorMessage
(String): Error details if search failedSearch for employees by department, position, or location across HR systems.
Locate specific transactions or approvals for regulatory compliance.
Analyze process data patterns and generate reports.
Customer calls with issue
Support agent needs to find customer’s account quickly.
Search by multiple criteria
Get comprehensive results
Receive full customer profile with account details, order history, and support tickets.
Resolve customer issue
Use the retrieved data to address the customer’s concern effectively.
Performance optimization
processDefinitionNames
and states
Data Modeling
Security & Compliance
Error Handling
No Search Results
Possible Causes:
Solutions:
Search Timeout Errors
Possible Causes:
Solutions:
processDefinitionNames
, states
)Invalid Search Key Errors
Possible Causes:
Solutions:
Connection Issues
Possible Causes:
Solutions:
Configure Elasticsearch indexing for FlowX Engine
Complete deployment and configuration guide
Learn how to design processes with searchable data
Search for specific data across process instances using Elasticsearch-powered indexing for fast, precise results.
The Data Search service enables you to find specific data across process instances within your FlowX.AI platform. It uses Elasticsearch to perform fast, indexed searches across process data.
Search by a single field and value
Search using multiple criteria simultaneously
Search across multiple applications
Filter results by process creation dates
Before using the Data Search service, ensure you have:
Elasticsearch Configuration
Kafka Topics
KAFKA_TOPIC_DATA_SEARCH_IN
configured for requestsKAFKA_TOPIC_DATA_SEARCH_OUT
configured for responsesProcess Data
Set up your data process
Create a process that stores searchable data and configure field indexing.
Create a search process
Build a process with Kafka Send/Receive actions for search functionality.
Configure search parameters
Define your search criteria using simple or advanced syntax.
Handle search results
Process the returned data and display results to users.
First, create a process that contains searchable data. Add a Service Task with a business rule:
Critical Step: After creating your data structure, you must configure field indexing in Process Settings → Data Search for the search to work.
Navigate to Process Settings → Data Search and add the field paths you want to search:
Fields that we indexed in our example:
application.client.personalInfo.firstName
application.client.personalInfo.lastName
application.client.personalInfo.email
Create a new process with a Send Message Task:
Configuration:
KAFKA_TOPIC_DATA_SEARCH_IN
Choose your search approach based on your needs:
Use when searching by a single field:
Use when searching by a single field:
Use when searching by multiple criteria (AND logic):
searchKeys
must match for a result to be returned.Search across multiple applications:
Filter by process creation dates:
Add a Receive Message Task with:
KAFKA_TOPIC_DATA_SEARCH_OUT
Success response example:
Parameter | Type | Mandatory | Description | Example |
---|---|---|---|---|
searchKey | String | Yes | Single field path to search | "application.client.personalInfo.lastName" |
value | String | Yes | Value to search for (with searchKey) | "Johnson" |
searchKeys | Array | Yes (if multiple fields) | Multiple field-value pairs (AND logic) | [{"key": "field1", "value": "val1"}] |
processDefinitionNames | Array | Yes | Limit to specific processes | ["client_onboarding"] |
applicationIds | Array | No | Search across applications | ["uuid-1", "uuid-2"] |
states | Array | No | Filter by process states | ["FINISHED", "STARTED"] |
processStartDateAfter | String | No | Include processes after date | "2024-01-01T00:00:00Z" |
processStartDateBefore | String | No | Include processes before date | "2024-12-31T23:59:59Z" |
searchKey (String)
Purpose: The field path to search in for single-field searches.
Usage: Use dot notation to specify the exact path to the field you want to search or a specific key in the payload.
Examples:
"application.client.personalInfo.firstName"
"application.client.address.city"
"application.client.business.industry"
Important: This field must be indexed in Process Settings → Data Search to work.
searchKeys
. Choose one approach.value (String)
Purpose: The exact value to search for when using searchKey
.
Usage: Must match the stored value exactly (case-sensitive).
Examples:
"Johnson"
- searches for exact lastName match"Technology"
- searches for exact industry match"Active"
- searches for exact status matchNote: Only used with searchKey
, not with searchKeys
.
searchKeys (Array)
Purpose: Array of key-value pairs for multi-field searches with AND logic.
Usage: All conditions must match for a result to be returned.
Format:
Example:
searchKey
. Choose one approach.processDefinitionNames (Array)
Purpose: Limit search to specific process definitions.
Default: Searches all processes if omitted.
Usage: Improves performance by narrowing search scope.
Examples:
["client_onboarding"]
- search only in client processes["employee_registration", "contractor_onboarding"]
- search in multiple process typesBest Practice: Always specify to improve search performance.
applicationIds (Array)
Purpose: Search across specific applications.
Default: Searches current application if omitted.
Usage: Enable cross-application searches.
Examples:
["8dd20844-2dc5-4445-83a5-bbbcc82bed5f"]
- search in specific app["app-1-uuid", "app-2-uuid", "app-3-uuid"]
- search across multiple appsUse Case: Useful for consolidated reporting across different business units.
states (Array)
Purpose: Filter results by process instance status.
Default: Returns all states if omitted.
Available States:
"CREATED"
- Process instance created but not started"STARTED"
- Process is currently running"FINISHED"
- Process completed successfully"FAILED"
- Process encountered an error and stopped"TERMINATED"
- Process was manually stopped/cancelled"ONHOLD"
- Process is paused or waiting for external inputExamples:
["FINISHED"]
- only completed processes["STARTED", "ONHOLD"]
- active or paused processes["FAILED", "TERMINATED"]
- processes that didn’t complete normallyBest Practice: Use ["FINISHED"]
for most business searches to get complete data.
processStartDateAfter (String)
Purpose: Include only processes started after the specified date.
Format: ISO 8601 timestamp (YYYY-MM-DDTHH:MM:SSZ
)
Examples:
"2024-01-01T00:00:00Z"
- processes started after Jan 1, 2024"2024-06-15T09:30:00Z"
- processes started after June 15, 2024 at 9:30 AMUse Cases:
"2024-03-01T00:00:00Z"
"2024-05-20T00:00:00Z"
processStartDateBefore (String)
Purpose: Include only processes started before the specified date.
Format: ISO 8601 timestamp (YYYY-MM-DDTHH:MM:SSZ
)
Examples:
"2024-12-31T23:59:59Z"
- processes started before end of 2024"2024-06-30T23:59:59Z"
- processes started before end of June 2024Use Cases:
"2024-01-01T00:00:00Z"
"2024-03-31T23:59:59Z"
Understanding process states is crucial for effective searching:
State | Description | When to Use |
---|---|---|
CREATED | Process instance exists but hasn’t started execution | Rarely used for business searches |
STARTED | Process is actively running | Find ongoing processes, current workload |
FINISHED | Process completed successfully | Most common for business data searches |
FAILED | Process encountered an error | Error analysis, troubleshooting |
TERMINATED | Process was manually cancelled | Audit trails, cancelled applications |
ONHOLD | Process is paused/waiting | Active cases needing attention |
Recommendation: Use ["FINISHED"]
for most business searches to ensure you’re getting complete, reliable data.
The search returns a JSON object with these fields:
result
(Array): List of matching process instances, automatically sorted by processStartDate
in descending order (newest first)
processInstanceUUID
: Unique process identifierstate
: Current process stateprocessStartDate
: When the process starteddata
: The actual process data with your searchable fieldstooManyResults
(Boolean): True if more than 50 results found (limit applied)success
(Boolean): Whether the search completed successfullyerrorMessage
(String): Error details if search failedSearch for employees by department, position, or location across HR systems.
Locate specific transactions or approvals for regulatory compliance.
Analyze process data patterns and generate reports.
Customer calls with issue
Support agent needs to find customer’s account quickly.
Search by multiple criteria
Get comprehensive results
Receive full customer profile with account details, order history, and support tickets.
Resolve customer issue
Use the retrieved data to address the customer’s concern effectively.
Performance optimization
processDefinitionNames
and states
Data Modeling
Security & Compliance
Error Handling
No Search Results
Possible Causes:
Solutions:
Search Timeout Errors
Possible Causes:
Solutions:
processDefinitionNames
, states
)Invalid Search Key Errors
Possible Causes:
Solutions:
Connection Issues
Possible Causes:
Solutions:
Configure Elasticsearch indexing for FlowX Engine
Complete deployment and configuration guide
Learn how to design processes with searchable data