Flow Contexts

Understanding contexts is a fundamental concept in Conigma Connect, as they form the basis for how flows are executed and how data is handled during runtime.

A context is always represented as a JSON structure, containing standard JSON elements such as values, objects, and arrays. This design has been chosen because Conigma Connect works extensively with API calls and integrations, where JSON is the dominant format for data exchange. By using the same structure internally, flows can directly interact with incoming and outgoing API data without additional conversion steps, avoiding the constant parsing and serialization that other programming environments require. This significantly reduces complexity when building integrations and speeds up development, as data can be directly processed in the same format it is received and sent.

When a flow is triggered, whether manually, on a schedule, or through an event such as a webhook, it is assigned its own execution-specific data space called the flow context. This context is populated with relevant information from the triggering event when applicable - for example, a webhook will pass incoming payload data, whereas a manual event will start with an empty context. The flow execution operates entirely within this space, modifying and using the stored data as needed.

Typical operations include reading incoming data, requesting additional information from other APIs, processing and combining these results, and sending an appropriately formatted response or request to another service. The flow context is stored and can be reviewed under Flow Checkpoints.

Flow contexts are isolated per execution and cannot be shared or accessed between different flow executions, as each execution corresponds to a distinct event that needs to be handled separately.

In addition to the flow context, Conigma Connect supports two other context types with specific purposes.

The global context is shared across all flows and executions, intended for persistent data that must be available system-wide. This can include identifiers, service mappings, or reference data that remains valid globally. For example, if Service A identifies a user as ID 12345 and Service B identifies the same user as ID abcdef, this mapping can be stored in the global context. Since a flow often needs to convert between data formats for different services, as this is a core premise of Conigma Connect, storing the mapping in the global context allows any flow to resolve the correct identifier for each service.

The third context type is the statement context, which is used internally by Conigma Connect for certain instructions within a flow. It stores temporary, instruction-specific data that has no relevance outside the scope of that instruction. Unlike the flow or global context, the statement context is not exposed to the user in the flow editor and cannot be accessed or modified directly. Its purpose is to hold transient values required for the execution of a specific instruction, such as the $.switchValue used internally in case blocks, without writing data that has no meaning beyond that instruction to the flow context.

These three contexts form the backbone of how Conigma Connect manages and structures data during execution, organizing information into appropriate scopes and purposes.