Chapter 1 of 8
Choose the smallest useful first outcome
Start with one record and one process a real person can recognize. A narrow first outcome proves the model, permissions and run history before the design expands.
- 01
Name the record
Choose one business object such as a supplier application, claim, inspection or purchase request.
- 02
Choose one event
Decide what should start the process: a new record, a meaningful update, a manual start, a schedule or an external event.
- 03
Choose one finish
Define the visible result: an approval recorded, a status changed, a notification sent or an external system updated.
- 04
Choose the people
Identify who models the record, who builds the workflow, who performs any human task and who may only read the result.
Chapter 2 of 8
Prepare your workspace in Portal
Portal establishes the organization, people, access and application instances that the product work will use.
- 01
Complete onboarding
Confirm organization details, plan and data region, then use the Portal checklist to see what remains.
- 02
Invite the working team
Add the smallest pilot group and use groups when access follows a team rather than one person.
- 03
Grant product roles
Give each person the narrowest Data, Automation or administrative role needed for the pilot.
- 04
Provision the application
Add Data, Automation or both from Marketplace and wait until each application instance reports ready.
- 05
Launch in the correct context
Open the ready instance from Portal so the organization and application-instance context travel with the session.
Chapter 3 of 8
Publish your first Data record type
If the outcome needs SynaptaGrid Data, model one real example before trying to design every future variation.
- 01
Bring a representative example
Use a real blank form, document or existing record whose sections, repeated items and required values are understood.
- 02
Create the record type
Define stable identity and naming, then add field groups, nested or repeating sections and typed fields.
- 03
Add only known rules
Mark required fields, validation and duplicate rules that the pilot can prove. Avoid encoding assumptions as permanent constraints.
- 04
Review impact
Use the publishing analysis to inspect the generated contract and any migration or compatibility warning.
- 05
Publish the version
Publishing makes the versioned schema, generated API and generated record screens available.
Chapter 4 of 8
Create and verify a sample record
Prove the published contract through the same surface the pilot will actually use.
| Pilot path | Verification |
|---|---|
| Generated form | Create a record, reopen it, update one value and confirm the history identifies the change. |
| REST API | Use a separately scoped API key, send one valid request, preserve the returned GUID and confirm a deliberately invalid request is rejected. |
| Bulk import | Download the sample shape, import a small bounded file and inspect successful and rejected rows independently. |
- Check that labels and presentation types make sense to the person entering data, rather than only to the model author.
- Verify search and any live choice source with realistic values before relying on them in a workflow.
- Attach a representative file through the signed upload flow when files are part of the record.
Chapter 5 of 8
Build and test your first workflow
If the outcome needs Automation, build one linear happy path first, then add decisions, waiting work and recovery.
- 01
Create the steps
Add a clear start, the work in business order and a terminal outcome. One path leaves each step.
- 02
Add transitions
Label the links, order conditional paths deliberately and provide a default path when no condition should stop the run.
- 03
Attach actions
Choose Data operations, external-system operations, notifications or a human task and map every required input.
- 04
Validate and publish
Resolve structural and mapping errors, then publish the immutable version the test will execute.
- 05
Start a manual test
Use controlled input, follow the run timeline and inspect every step’s resolved input, output and selected transition.
- 06
Exercise one failure
Make a safe step fail, then confirm the expected retry or operator recovery path before activating a live trigger.
Chapter 6 of 8
Connect Data to Automation
When both products are in the outcome, publishing the Data record type makes its operations available to Automation; you do not hand-build that connector.
- 01
Choose the record event
Bind the published workflow to created, updated, deleted or version-promoted for the intended record type.
- 02
Filter the trigger
Add the narrow condition that separates a meaningful business event from every ordinary edit.
- 03
Map the record identity
Carry the triggering record GUID through the run so a later step can read the current record or write a result back.
- 04
Arm the trigger
Arming compiles the resolved mappings and refuses incomplete required inputs.
- 05
Change one test record
Perform the exact event, confirm one run starts and compare the record history with the workflow timeline.
Chapter 7 of 8
Choose your next connection
Add only the connection required by the first outcome, using its dedicated guide and security model.
| Need | Next guide |
|---|---|
| Load or update records from your backend | Use the Integration guide for Data API keys, generated contracts and bounded retries. |
| Start a run from another application | Use the Integration guide for workflow-scoped keys or signed inbound events. |
| Call an existing API from a step | Register the external system, import selected operations, map fields and set throttle and retry behavior. |
| Send record or workflow events outward | Create a signed webhook subscription and make the receiver idempotent. |
| Build the model or workflow conversationally | Use the early-access Assistant guide, confirm grants and ask for an explanation before consequential changes. |
Chapter 8 of 8
Complete the production-readiness check
A successful demo proves the path. These checks make it safe to put real work through it.
- Replace broad pilot roles and credentials with least-privilege grants owned by named teams.
- Use separate production credentials, store secrets outside source and record rotation ownership and expiry.
- Set retention, quotas, rate limits, workflow timeouts, external-system concurrency and alert thresholds deliberately.
- Test duplicate delivery, rate limiting, an unavailable external service, a rejected human task and the documented recovery action.
- Verify the audit trail answers who published the model, activated the workflow, changed access and performed the test decision.
- Document the source id, record GUID, event id and workflow/run ids that support will need to trace one transaction.
- Keep the pilot narrow until the business owner accepts the record screens, workflow result and failure behavior.
Continue
Continue with the product guides
Data and Automation are sold separately and work independently. Use both when a workflow should read or change a versioned business record.