02.03.2026
19:34
Hi,
Current Situation:
Data Sources are typically static and context-independent. Each Data Source is bound to a fixed query or API call, with no native mechanism to pass parameters dynamically. As a result, any variation in use (such as retrieving different columns, filtering by different criteria, or adapting to different workflow contexts) requires creating multiple Data Sources or embedding logic elsewhere.
Disadvantages:
- Redundancy: The same underlying query or lookup often needs to be duplicated for each variation.
- Tightly coupled to specific processes: A Data Source is hardwired to a specific e.g. form field, Item List, or workflow use case.
- Lack of flexibility: Dynamic adaptation to different inputs or contexts is cumbersome or impossible without workarounds.
Proposed Improvement:
Introduce parameter support for Data Sources, similar to how Business Rules allow input parameters. Parameters could include:
- Filter values (e.g., a specific cost center, OU, or status)
- Context values (e.g., current user, workflow field, or system variable)
This would allow a single Data Source to be reused dynamically across multiple fields, Item Lists, and Business Rules, drastically reducing redundancy and improving maintainability.
Example Use Case:
Consider a recursive SQL query on a dictionary representing the organizational model. The goal is to retrieve information about parent OUs starting from a base OU.
- Current approach: For each column you want to return (e.g., OU Name, Manager, Submanager, Location), you would need to create a separate Business Rule or Data Source, leading to multiple duplicates of the same recursive logic.
- With parameterized Data Source: One Data Source could accept the base OU as a parameter and return all columns dynamically. Using a simple Data Source Value binding, a form field or Item List and so on could then select which column to display. This enables flexible reuse and keeps the query centralized, maintainable, and consistent.
Another Use Case could be a Rest Api Data Source that uses e.g. the email address of a user as a parameter in the suffix of the url. The Api would then dynamically reply the response only for this email address instead of giving back a large collection that has to be filtered.
Benefits:
- Reduce duplication of queries and logic
- Enable dynamic and context-aware data retrieval
- Centralize complex lookups in one Data Source instead of multiple Business Rules
- Improve maintainability and adaptability across workflows
Requirements:
- Definitions of Data Sources need a GUI element to create, edit and delete parameters as it is already possible with a swagger usage. The parameters need to be displayed in the Data Source editors (url suffix, sql query, …) too.
- All objects that provide the selection of a Data Source would need a GUI element to pass values to the parameter(s) of the Data Source as you can see in the attaches screenshot
Kind regards
Sébastien
