Aamu.app database automations let a database row start follow-up work automatically. They are especially useful with forms: a public form collects the data, the response becomes a database row, and an automation can send an email or create a task when that row is inserted or later reaches a selected value.

This article uses the contact form idea as an example, but the same pattern works for survey responses, onboarding requests, bug reports, event registrations, lead forms, and internal request queues.

The current automation model

A database automation belongs to one Aamu database. Inside the automation you choose:

  • the automation name,

  • the triggering type,

  • the triggering table,

  • one or more actions, and

  • whether the automation is draft or public.

The current database triggers are:

  • Row inserted — runs when a new row is added to the selected table.

  • Row updated — runs when a selected field changes to a configured value.

A row can be inserted through a published Aamu form, the Forms API, a GraphQL database mutation, or a manual database entry. Row-updated automations are useful for stage transitions such as a deal changing to won, a request changing to approved, or a support item changing to ready.

The current actions are:

  • Send an email

  • Create a task

You can add more than one action to the same automation. Actions can be inserted before, between, or after existing actions, and removed when they are no longer needed. For example, one new contact-form submission can send a confirmation email and create a follow-up task for the sales team.

Open automations from the database

Open the database that contains the table you want to automate. From the database menu, open Automations, then create a new automation.

If you are coming from a form, remember that form responses are stored in a database table. The form's Responses view links back to that database. That is usually the easiest place to find the right database and table.

Choose the trigger table

Give the automation a descriptive name, such as:

Notify us about new contact form submissions
Create follow-up task from onboarding requests
Send survey thank-you email

Choose Row inserted when every new row should start the workflow. Choose Row updated when the workflow should wait for a specific field to change to a selected value. Then choose the table and, for an update trigger, the field and target value.

After you select the table, Aamu shows the available template bindings. These are placeholders based on the database fields. A field might be shown as something like:

{{email}}
{{name}}
{{message}}

You can use these bindings in email templates and, depending on the action, map database fields into task data.

Action: send an email

The email action sends through an Aamu email account configured for a project. That means email needs to be set up before this action can run.

When configuring the action, choose the email address to use for sending. Then create a new email template or select a previously created template. Existing templates can also be edited from the automation. The template can use database bindings in the recipient, subject, and body.

For a contact form, the template might use:

To: support@example.com
Subject: New contact form message from {{name}}

Message:
{{message}}

Reply to:
{{email}}

If a field may be empty, templates can use a default value form for bindings:

{{company|No company provided}}

Use the email action for notifications, confirmations, and lightweight handoffs. For real work that needs ownership and status, create a task too.

Action: create a task

The task action creates an Aamu task when the automation trigger matches. Choose the project where the task should be created, then choose the user who should be assigned.

You can map database fields into the task:

  • a database field for the task title,

  • a database field for the task body, and

  • database fields for custom task fields when the target project has them.

This is useful when a submitted form needs a real workflow. For example:

  • a demo request creates a sales task,

  • a bug report creates a triage task,

  • a job application creates a recruiting task, or

  • an onboarding request creates an implementation task.

The database row remains the source data. The task is the follow-up work.

Draft vs public

New automations start as draft. A draft automation does not run. This is deliberate: you can configure the trigger, actions, templates, and mappings without affecting live data.

Set the automation to Public when it is ready. Only public automations run when matching rows are inserted or updated.

If you need to pause the workflow, switch the automation back to draft. This is a simple way to turn the automation off without deleting its configuration.

The user who creates the automation owns its configuration. Other users can view the automation, but editing controls are available to the owner.

Test the automation

When an automation is public and has actions, Aamu shows a test action control. Use it before relying on the workflow.

For a form-based workflow, also test the real path:

  1. Open the public form.

  2. Submit a realistic test response.

  3. Confirm that a new row appears in the database table.

  4. Confirm that the email was sent, if the automation sends email.

  5. Confirm that the task was created in the correct project, if the automation creates a task.

  6. Check that the field bindings produced readable text.

Testing with a real submission catches the full chain: public form, database row creation, automation trigger, email configuration, and task mapping.

Troubleshooting checklist

If the automation does not run, check these:

  • The automation status is Public, not Draft.

  • The trigger table is the same table receiving the new row.

  • The operation matches the trigger: a new row for Row inserted, or a real field transition to the configured value for Row updated.

  • The action has all required settings.

  • The sending email account is configured for the selected project.

  • The email domain is attached to the project if email sending depends on it.

  • The task action points to the right project.

  • The selected assignee still has access to that project.

  • The template bindings match the fields in the triggering table.

Manage automations through the API

Automations can also be listed, created, read, updated, and deleted through the Aamu API. This is useful when an integration provisions a complete workflow: create a database, add its columns, add an automation, and then write rows through GraphQL or the Forms API.

Automation management uses a separate project-level Automations scope. It does not come implicitly with Database access. Use read permission for listing and fetching automations, and write permission for creating, changing, or deleting them.

GET    /api/v1/databases/DB_ID/automations
POST   /api/v1/databases/DB_ID/automations
GET    /api/v1/automations/AUTOMATION_ID
PATCH  /api/v1/automations/AUTOMATION_ID
DELETE /api/v1/automations/AUTOMATION_ID

All requests send the Team API key in x-api-key. The database identifies its project, so these routes do not require x-project-id.

Create a row-inserted task automation

POST /api/v1/databases/DB_ID/automations
x-api-key: YOUR_API_KEY
Content-Type: application/json

{
  "name": "Create onboarding task",
  "status": "public",
  "trigger": {
    "type": "row_inserted",
    "tableId": "TABLE_ID"
  },
  "actions": [
    {
      "type": "create_task",
      "pid": "PROJECT_ID",
      "users": ["USER_ID"],
      "dbFieldTitle": "TITLE_COLUMN_ID",
      "dbFieldBody": "DETAILS_COLUMN_ID"
    }
  ]
}

The key needs Automations write scope for the database project and Tasks write scope for the target task project. A send_email action similarly requires Emails write scope for its target project.

Create a row-updated automation

POST /api/v1/databases/DB_ID/automations
x-api-key: YOUR_API_KEY
Content-Type: application/json

{
  "name": "Create handoff task when deal is won",
  "status": "public",
  "trigger": {
    "type": "row_updated",
    "tableId": "DEALS_TABLE_ID",
    "columnId": "STAGE_COLUMN_ID",
    "value": "won"
  },
  "actions": [
    {
      "type": "create_task",
      "pid": "DELIVERY_PROJECT_ID",
      "dbFieldTitle": "DEAL_NAME_COLUMN_ID"
    }
  ]
}

The update trigger runs only when the selected field actually changes and its new value equals the configured value. Rewriting the same value does not run the automation again.

A complete API workflow

  1. Create a database and columns with the Database REST API.

  2. Create a public automation with the Automations API.

  3. Insert a row through GraphQL or submit an Aamu form through the Forms API.

  4. Aamu stores the row and runs the matching automation.

  5. The action creates the task or sends the email through the same internal workflow used by Aamu.

For the broader authentication, database, Forms, GraphQL, and Tasks examples, see Building with the Aamu API.

Database automations and outbound webhooks

Database automations are designed for internal follow-up after a row is inserted: send an email, create a task, or do both. If another system needs to react to Aamu events, use outbound webhooks. Webhooks cover a broader range of workspace events and send signed event data to an external HTTPS endpoint.

A simple rule of thumb is: use a database automation when the next action should happen inside Aamu, and use an outbound webhook when the next action belongs in another system.

A practical pattern

A good Aamu automation usually has this shape:

  1. A form or API call creates a database row.

  2. The database row stores the structured data.

  3. A database automation sends a notification or creates a task.

  4. The team handles the actual work in Tasks, Emails, Helpdesk, or the database.

That is the strength of keeping forms, databases, email, and tasks in the same workspace. The submitted data does not disappear into a notification. It stays available as a row, and the automation turns it into the next action.