Using Data and Automation

The two products SynaptaGrid ships - what each one is for, the vocabulary, and which page you want next.

Two products, one account

Most of this documentation site is about building an app on the SynaptaGrid Platform. This section is different: it is about using the two products SynaptaGrid ships — Data and Automation — whether you are setting one up or integrating with it from your own code.

SynaptaGrid Data holds business records whose shape keeps changing. You define a record type once, and you get its storage, its REST API and its working screens together. When the shape changes later, you change the model rather than running a migration.

SynaptaGrid Automation runs the work that happens to those records. You draw a process, decide what triggers it, and let it stop for a human decision where a human decision belongs. Every run is recorded step by step.

They are sold separately and each works on its own. Together, a workflow can read and write the records Data holds — including reading a record fresh, mid-run, before it decides what to do next. If you are not using Data, Automation works against your own systems instead.

Which page do you want

If you are setting things up:

Model your first record type — record types, sections, fields, and publishing a version.
Build your first workflow — steps, conditional links, human decisions, and arming a trigger.

If you are integrating from your own code:

The generated API — the REST surface every record type gets, the schema endpoint, API keys and access tiers.
Getting changes out — subscribing to record events over HTTPS, Amazon SQS, Amazon SNS or Kafka.
Connecting a system to a workflow — turning any REST API into workflow steps, mapping fields, and streaming run events back.

Vocabulary

The interface and this documentation use these words consistently. It is worth two minutes now.

Term	What it means
Record type	A kind of thing you keep: an invoice, a claim, a supplier.
Schema	A named shape for a record type. A record type can have more than one.
Section	A group of fields inside a schema. Sections nest, and can repeat.
Field	One typed value, with its rules and how it should be presented.
Version	A published snapshot of a schema. Records and running workflows pin to one.
Draft	The one editable copy of a schema that is not yet published.
Workflow	A process: steps connected by conditional links.
Step	One unit of work in a workflow — call a service, ask a person, or wait.
Run	One execution of a workflow against one subject.
Binding	The rule connecting a trigger to a workflow. It must be armed before it fires.
Action	Something a step can do. Imported from a service's API description, or built in.

Two things that will save you time

Publishing is the boundary. A draft is yours to change freely. A published version is immutable, and anything already using it — records, in-flight runs, integrations reading the schema — keeps working against the version it started on. Nothing you do to a draft can disturb them.

Nothing is generated at deploy time. A record type gets its API and screens the moment you publish it. There is no code generation step, no redeploy, and no waiting for an engineer to expose the new thing.