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.
Available on every plan, including the free tier.
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.
FAQ
Questions about building workflows
How workflows start, map, branch, and reach production.
Still have a question? Talk to an expert.
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