A form submission is rarely the end of a workflow. A demo request needs an owner. A support escalation needs a task. A job application needs review. A new lead may need a confirmation email, a CRM record, and a follow-up deadline.

Aamu.app can keep that whole chain in one workspace. Forms collect structured input. Databases keep the source record. Automations turn matching row events into Tasks or Emails. Outbound webhooks notify external systems. CRM tables keep the relationship and its history visible after the first response.

This article shows how those parts fit together and how to design workflows that remain understandable after the first successful test.

The workflow model

A practical Aamu workflow has five layers:

  1. Input: a public form, Forms API request, GraphQL mutation, or manual database entry.

  2. Structured state: a database row containing the submitted fields and the current workflow status.

  3. Trigger: a row being inserted or a selected field changing to a configured value.

  4. Action: create an Aamu task, send an email, or call an external system through a webhook.

  5. Ongoing work: update the CRM row, complete the task, continue the email conversation, or move the row to its next stage.

The database row is the durable center of the workflow. Notifications and tasks can change over time, but the original structured input and its status remain available for search, reporting, activity history, and later automation.

Workflow 1: form submission to follow-up task

Consider a demo request form with these fields:

  • Name

  • Email

  • Company

  • What the team wants to solve

  • Preferred follow-up date

Publishing the form gives the team a browser-friendly input surface. Every submission becomes a row in the form’s database table. The row can also include internal fields that the public form does not expose, such as owner, status, qualification notes, next action, and related tasks.

Trigger on the inserted row

Create a Row inserted automation for the response table. A single automation can contain more than one action:

  • send a confirmation or internal notification email, and

  • create a follow-up task in the sales or customer project.

Map the company or request field to the task title and the longer request description to the task body. Assign the task to the person or team responsible for reviewing new requests.

The result is a useful separation of concerns: the database row stores the lead, while the task represents the work someone must do next.

The same workflow through the API

An authenticated integration can submit an existing form through:

POST /api/v1/forms/FORM_ID/submissions
x-api-key: YOUR_API_KEY
x-project-id: YOUR_PROJECT_ID
Content-Type: application/json

{
  "fields": {
    "name": "Ada Lovelace",
    "email": "ada@example.com",
    "company": "Analytical Engines Ltd",
    "request": "We need a shared workflow for customer onboarding."
  }
}

The Forms API creates the same kind of database row as a browser submission, so the same public row-inserted automation runs afterward.

Workflow 2: CRM stage change to handoff

Some workflows should not run immediately when a row is created. A new deal may need qualification before delivery or onboarding work begins.

In a CRM table, use a status field such as:

new → qualified → proposal → won → onboarding

Create a Row updated automation that watches the Stage field and runs when the new value becomes won. The automation can then create a handoff task in the delivery project. It runs only when the value actually changes to the configured value, not when the same value is written again.

This gives the CRM row two jobs:

  • it records the current commercial state, and

  • it starts the next operational workflow at the correct transition.

The new task can use the deal name as its title, copy implementation notes into the body, assign delivery users, and map database values into custom task fields.

Automations or webhooks?

Database automations and outbound webhooks solve related but different problems.

Use

Choose

Create an Aamu task from a row

Database automation

Send through a configured Aamu project email

Database automation

Notify another application about the submission

Outbound webhook

Start custom code, a queue, or an external integration

Outbound webhook

Fetch more context or write back into Aamu

Webhook followed by an Aamu API call

A simple rule is: use an automation when the next action belongs inside Aamu, and use a webhook when another system needs to react.

The two can coexist. A form submission can create an internal task and also send a signed form.submitted webhook to an external service. The external service can verify the signature, store the delivery id for idempotency, and call the Aamu API when it needs more detail or wants to write a result back.

Provision the workflow through APIs

The workflow can be assembled programmatically when an integration needs repeatable setup. The Forms API can now create and update the Form itself instead of requiring the Form builder UI for initial provisioning.

POST  /api/v1/forms/
PATCH /api/v1/forms/FORM_ID
POST  /api/v1/databases/DB_ID/automations
POST  /api/v1/forms/FORM_ID/submissions
POST  /api/v1/graphql/
GET   /api/v1/tasks/

A Form created with publish: true receives its backing database and table automatically. Forms write scope controls Form creation, updates, publishing, and authenticated submissions. Automation definitions use the separate Automations scope. A task action additionally requires Tasks write scope for its target project, while an email action requires Emails write scope.

For example, an integration can create a Contact Form with name, email, and message fields, publish it, attach a row-inserted automation to its generated table, and then accept responses either through the public Form or authenticated submissions. GraphQL row inserts and Forms submissions run the same row-inserted automation path.

Aamu's internal AI uses the same OpenAPI operations, so natural-language setup can follow the same validated provisioning path without an internal API key.

Design the database for the workflow

Good automation starts with understandable data. Useful workflow columns often include:

  • Status or stage for explicit transitions.

  • Owner for responsibility.

  • Next action and due date for follow-up.

  • Source to distinguish public form, API, import, or manual entry.

  • Related task, email, meeting, or Doc fields for connected work.

  • External id when another system must correlate or deduplicate records.

Do not make automation depend on ambiguous free-form notes when a status field can express the decision directly. A field changing to approved is a safer trigger than trying to infer approval from a comment.

Keep humans in the loop where it matters

Not every action should happen automatically. Creating an internal review task is low risk. Sending a customer email, changing a CRM stage, or starting an external process may deserve a deliberate state transition or human approval.

A useful pattern is:

  1. The form creates a row and an internal review task.

  2. A person reviews the information and changes Status to Approved.

  3. A row-updated automation creates the operational handoff task or sends the approved email.

That keeps automation fast without letting raw public input immediately trigger every downstream side effect.

Test the whole chain

A workflow is not tested when its individual settings look correct. Test the complete path:

  1. Submit a realistic form response or GraphQL mutation.

  2. Confirm that the database row contains the expected values.

  3. Confirm that the automation trigger matches the correct table and event.

  4. Confirm that the task appears in the correct project and task list.

  5. Confirm that email bindings produced the intended recipient, subject, and body.

  6. If using webhooks, verify the signature and inspect the delivery log.

  7. Repeat the update with the same value and confirm that a row-updated automation does not run twice.

Use clearly named test records and clean up temporary automations afterward. Keep test database rows when they are useful as examples, or mark them so they do not affect real reporting.

A practical architecture

For many small teams, the complete workflow can stay pleasantly simple:

Form or API
    ↓
Database row
    ↓
Automation ──→ Task or Email inside Aamu
    │
    └────────→ Signed webhook to an external system
                    ↓
               Optional Aamu API call
                    ↓
              CRM row or follow-up update

The strength of this model is not that every step is automatic. It is that input, structured state, internal work, customer communication, and external integrations share clear boundaries.

Related guides

The bottom line

Forms collect the input. Databases keep the truth. Automations create the next piece of internal work. Webhooks connect external systems. Tasks, Emails, and CRM tables keep the workflow visible after the first event.

That is enough to build useful lead handling, onboarding, support escalation, recruiting, approvals, and internal request workflows without turning every process into a separate application.