> ## 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/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

***

If you work in financial services, these challenges are probably familiar:

* **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

These are common integration and compliance concerns for financial engineering teams.

## How Flowker changes this

***

Flowker provides one orchestration platform for workflow routing, provider configuration, mappings, and execution records. Here is the operating model:

|                          | 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, and they need to do it under audit pressure with tight deadlines.

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. There is nothing to enable or configure.
</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/flowker/use-cases">
    See how Flowker applies to transaction validation, onboarding, payments, and more.
  </Card>

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