Build the integration on a canvas. Not in a codebase.
Drag-and-drop the whole workflow — triggers, mapping, branching, retries, and the path to production. The logic stays visible to everyone who has to read it, and the people who own the process can build it without waiting on a developer.
- Triggers
- Data mapping
- Decision tables
- Testing
- Promotion
- Receive webhookorder-created · Shopify
- Validate schemaOrder v2 · registry
- Map to NetSuite18 fields · 2 conversionsRunning
- Post transactionSales orderQueued
2 of 4 steps complete
Work rarely starts on a schedule alone
A file lands, a queue receives a message, a system calls an endpoint, someone emails an invoice. Each of those is a first-class way to start a workflow — not a workaround built on top of a timer.
REST Service
Expose a workflow as an HTTP endpoint with request and response schemas, so another system starts it by calling it.
Webhook
Receive inbound events in real time, with endpoint paths, authentication, and payload parsing configured up front.
Schedule
Run on cron or interval expressions — periodic syncs, overnight reconciliation, scheduled reporting.
File Trigger
Start when a file lands in object storage. The drop is the event; nothing polls and nothing waits.
Receive Message
Consume from a channel or queue for publish-subscribe and event-driven work across systems.
Email Receiver
Start from an inbound message, for the processes that still begin with someone sending an attachment.
Batch Event Trigger
Fire when a batch job reaches a defined state — completion or failure — for post-processing and notification.
The part of integration that actually takes the time
Connecting two systems is rarely the hard part. Agreeing what a field means on both sides is. Koodisi treats mapping as its own surface — visual, source to target, with the conversions and conditions attached to the fields they belong to.
- Field mapping
- Draw source to target once. The mapping is part of the workflow, not a script someone has to maintain beside it.
- Type conversion
- Cents to currency, string to date, code to label — handled in the mapping rather than in a transform step bolted on afterwards.
- Conditional logic
- Map a field one way or another depending on the record. The branching lives with the mapping it affects.
- Expression-based transforms
- When a field needs real logic, build the expression inline against the mapping — no separate transformation layer to maintain.
customer.first_namedirectContact.FirstNamecustomer.last_namedirectContact.LastNameacct.balance_cents÷ 100Account.Balancecreated_atISO 8601CreatedDateregion_codelookupTerritory
Business rules belong outside the workflow
Approval thresholds, routing rules, tier logic — the things that change most often are usually buried deepest in a flow. A Decision Table lifts them out: match input fields against a configured rule set, return the matching output, and change the rule without editing the workflow around it.
Included in the platform, not a separately priced add-on.
The shapes real integrations take
Enterprise integration has a small vocabulary of proven patterns. Koodisi ships them as building blocks rather than leaving each team to rebuild them.
Routing
Send each record down the path its content calls for, rather than running everything through one branch.
Publish–subscribe
Send and receive across channels and queues, so systems react to events instead of polling for them.
Aggregation
Collect related records and act on the set — the shape most reconciliation and reporting work actually takes.
Pipes and filters
Compose small steps into a pipeline where each does one thing, and the sequence stays legible months later.
Branching and parallel tasks
Fan work out where order does not matter, and hold it where it does.
Batch processing
Initialise a batch, add records, iterate, and trigger downstream work when it completes or fails.
From canvas to production, without a separate toolchain
Most platforms stop at build. The work that decides whether an integration survives contact with production — testing, promotion, versioning, recovery — happens here too.
- 01
Build
Design on the canvas, map the fields, and set the rules. Variables and reusable activities keep the same logic from being rebuilt per workflow.
- 02
Test
Unit and regression tests run inside the platform, not in a separate harness. Step through a workflow and inspect it activity by activity, with load and security testing available on higher plans.
- 03
Deploy
Deployment Profiles carry environment-aware configuration, so the same workflow points at Dev, UAT, or Production without being edited for each. Promotion is versioned and approved.
- 04
Operate
Retry policies and fallback paths absorb transient failures. What they cannot absorb becomes tracked fallout in Koodisi Engage.
Retry policies and fallback paths
Configure how a step behaves when the far end is slow, rate-limited, or briefly unavailable — rather than letting one timeout end the run.
Error handling in the flow
Failure is a branch you design, not an exception that halts the workflow silently and leaves nothing behind.
Rollback on promotion
Versioned deployments mean a bad release is reversed, not hot-fixed under pressure.
From the blog
FAQ
Questions about building workflows
How workflows start, map, branch, and reach production.
Still have a question? Talk to an expert.
No. Workflows are built on a drag-and-drop canvas with visual data mapping, and the people who own the process build them without a developer. Transformations, branching, and business rules are all configured rather than coded.
Seven ways, all first-class: an HTTP call to a REST Service endpoint, an inbound webhook, a cron or interval Schedule, a file landing in storage, a message arriving on a channel or queue, an inbound email, or a batch job reaching a defined state.
In the Data Mapper, as its own surface. You map source to target visually, with type conversion, conditional logic, and expression-based transformations attached to the fields they apply to — rather than scattered across a separate transformation layer.
A rule set held outside the workflow. Input fields are matched against configured rules and the matching output is returned for routing or transformation. It means approval thresholds and routing rules can change without editing the flow around them. Included in the platform, not a separately priced add-on.
Configurable retry policies and fallback paths handle transient failures such as timeouts and rate limits. Failures that will not clear on another attempt become tracked fallout in Koodisi Engage, where a person can resolve them.
Yes. Unit and regression tests run inside the platform rather than in a separate harness, and you can step through a workflow to inspect it activity by activity while you build. Load and security test suites are available on higher plans.
With Deployment Profiles, which hold environment-aware configuration for Dev, UAT, and Production. The same workflow moves between them without being edited for each — the endpoints and credentials come from the profile.
Through a Dev, Test, Deploy, Promote pipeline with approvals and versioning on each promotion, so a release can be reviewed before it ships and rolled back after. Git integration and environment-aware Deployment Profiles are available on higher plans.
Bring the integration you have been putting off.
We will build it on the canvas with you — triggers, mapping, rules, and the promotion path to production.
Book a demo