Connecting a system to a workflow
Turn any REST API into workflow steps, map the fields, park on long-running calls, and stream run events back to your own systems.
If it has an API, it can be a step
You do not wait for a connector to be built. Register the service, point at its API description, and choose which of its operations become steps you can use in a workflow.
The ready-made catalog is a starting point, not a boundary — it covers mail, calendar, documents, spreadsheets, storage, translation and language models, plus built-in document and image actions such as convert, merge, split, rotate, stamp and reading text from a scan.
Step 1 — Register the external system
An external system carries the base URL, the authentication, the retry policy and the throttling for one service. You configure that once and reuse it everywhere.
Step 2 — Import its operations
Point the system at its own API description and import. Three ways in, depending on what the service gives you:
- Fetch a URL to the description
- Upload the file if it is not published
- Probe the service, which tries the usual locations
You preview what would be imported and pick only the operations you want — importing a 200-operation API wholesale makes the step picker unusable.
If there is no description to import, hand-author the action instead: method, path, input and output contracts, and whether it is synchronous.
Step 3 — Map the fields
A step's inputs are mapped from a source. The available sources:
| Source | Use for |
|---|---|
| The triggering event | Values that arrived with the trigger |
| An earlier step's output | Chaining one call into the next |
| A signal | Values delivered into a waiting run |
| A fixed value | Constants |
| A template | Composing a string from several values |
| A computed value | Something derived |
Outputs map back onto the record.
Mappings resolve in three layers — catalog defaults, then per-record-type overrides, then per-workflow overrides — and a panel shows you the result of all three combined. Use it: reasoning about which layer won from memory is how mapping bugs happen.
Mappings compile when the trigger is armed. What runs is exactly what the arming check validated, not a fresh interpretation at run time.
Working with records
If you are using SynaptaGrid Data, every record type you publish arrives automatically as create, read, update, delete and list actions. Nobody wires them up.
The behaviour worth designing around: a step can read the record fresh, mid-run. A decision late in a long-running process uses what is true now, not what was true when the run started. That is the difference between a workflow that can check stock before fulfilling and one that cannot.
If your records live elsewhere, the same workflow works against your own systems through the actions you imported.
Long-running calls
For a service that takes minutes or hours, a step can hand off work and park until that service calls back. The run waits with a deadline so it cannot hang forever, and the callback is authenticated with a token issued for that run.
Use this rather than polling in a loop.
Getting events back out
Subscribe to what happens inside a workflow and have it delivered to your own systems:
- Runs — started, completed, failed, cancelled, timed out, moving between steps
- Steps — entered, completed, failed, and the branch taken
- Tasks — created, assigned, completed, signed
- External calls — completed
Destinations are an HTTPS endpoint, Amazon SQS, Amazon SNS or Kafka, signed, with retries and a delivery log.
Same direction note as elsewhere: those queues and streams are outbound. To start a workflow from an external system, use the signed HTTPS trigger or the client API.
Triggering from your own code
Two ways in:
- A signed HTTPS call to the public inbound endpoint, with a per-source secret you can rotate. Idempotent on the event identifier, so a retry on your side does not start a second run.
- The client API with a tenant API key scoped to particular workflows, which you rotate yourself.
Embedding the human step in your own app
If your users should approve inside your product rather than being sent elsewhere, the task inbox, decision panel, run timeline, state badge, follow toggle and start button are all available as components you drop into your own interface.
Things that do not exist
Stated plainly so you do not design around them:
- No parallel branching, fan-out or wait-all joins. One path per step.
- No sub-workflows or nested workflows.
- No dead-letter queue viewer or event replay for workflow events. Run-level restart, rewind and replay are real — use those.
- No built-in scripting step. Scripting-shaped work is a connector action or an assistant tool.
- No workflow import/export as files. Templates are the shipped equivalent.
Where to go next
- Build your first workflow — the process itself.
- Getting changes out — record events, as distinct from workflow events.