> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Flowker?

> How Flowker centralizes provider configuration, workflow routing, and execution records for financial operations.

export const GDSL = ({children}) => <Tooltip headline="DSL (Domain-Specific Language)" tip="A simplified language designed for a specific purpose — in Flowker's case, for defining workflow steps and rules without writing general-purpose code." cta="See glossary" href="/en/start-here/glossary">
    {children}
  </Tooltip>;

Financial institutions need to integrate providers, validate transactions, and preserve evidence for compliance. Flowker centralizes workflow routing, provider configuration, and execution records. The controls and outcomes still depend on the systems and integration boundaries you configure.

## The problem

***

Financial services teams face these challenges:

* **Variable provider-integration effort**: each provider has its own API contract, authentication, error handling, security review, and test scope
* **Scattered validation evidence**: validation data is spread across multiple systems, making it difficult to reconstruct what happened during audits
* **Compliance gaps**: when validation happens after the ledger write, invalid transactions create regulatory exposure
* **Provider migration complexity**: changing provider, executor, or provider-configuration reference can require updates to draft workflow nodes
* **Costly rollbacks**: invalid ledger writes require expensive manual remediation and damage data integrity

## How Flowker changes this

***

Flowker provides one orchestration platform for workflow routing, provider configuration, mappings, and execution records.

|                          | Before Flowker                       | With Flowker                                                                        |
| ------------------------ | ------------------------------------ | ----------------------------------------------------------------------------------- |
| **Provider integration** | Provider-specific integration work   | Centralize provider configuration and node mappings                                 |
| **Step traceability**    | Partial, scattered across systems    | Every executed processing node recorded automatically                               |
| **Provider flexibility** | Changes can require integration work | Update settings; update draft nodes when references change                          |
| **Validation model**     | Depends on the integration boundary  | Orchestrate checks before a configured posting step; enforce at the ledger boundary |
| **Failure handling**     | Custom retry logic per integration   | Built-in retries and circuit breakers                                               |
| **Workflow visibility**  | Limited, requires log aggregation    | Full execution tracking with step-level detail                                      |

## For compliance teams

***

Compliance teams need to prove that every transaction was validated correctly.

Flowker gives compliance teams:

* **Step-level traceability**: every execution records each executed processing node with its status, duration, output, and error message
* **Queryable execution history**: filter executions by workflow and status, then read the step detail of any execution through the API
* **Integration-owned posting control**: use Flowker to orchestrate checks before a ledger-posting step, then enforce them at the ledger boundary

<Note>
  Flowker records execution steps automatically. You do not need to enable or configure anything.
</Note>

## For engineering teams

***

Engineering teams need to integrate providers quickly, handle failures gracefully, and stop rebuilding the same integration plumbing for every new service.

Flowker gives engineering teams:

* **Configure once, reuse everywhere**: set up a service instance's base URL and credentials once as a provider configuration, then reference it from any workflow node
* **Built-in resilience**: circuit breakers prevent cascading failures when providers go down. Retries with exponential backoff handle transient errors automatically
* **Configuration and mappings**: centralize connection settings and node mappings in their workflow surfaces
* **Configuration validation**: catalog configurations use the provider JSON Schema. `external_openapi` configurations use dedicated external OpenAPI and configuration validation
* **Field mapping and data transformation**: map workflow fields to provider-specific formats without writing transformation code

## For product teams

***

Product teams need to ship faster, respond to market changes, and measure what's working, without waiting months for engineering to build or modify validation flows.

Flowker gives product teams:

* **Faster time to market**: new validation workflows can be defined and deployed without waiting for custom integration work
* **Flexibility without code changes**: add, remove, or reorder validation steps by updating workflow definitions, not by requesting engineering sprints
* **Observable and measurable operations**: execution records and deployment telemetry provide evidence for workflow investigation

## What's next

***

<CardGroup cols={2}>
  <Card title="Use cases" icon="lightbulb" href="/en/products/flowker/use-cases">
    See how Flowker applies to transaction validation, onboarding, payments, and more.
  </Card>

  <Card title="Getting started" icon="rocket" href="/en/products/flowker/flowker-getting-started">
    Set up Flowker and run your first workflow end to end.
  </Card>
</CardGroup>