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.

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 trigger is Row inserted. In other words, the automation runs when a new row is added to the selected table. That can happen through a published Aamu form, the Forms API, a database API write, or a manual database entry.

The current actions are:

  • Send an email

  • Create a task

You can add more than one action to the same automation. 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

Set the triggering type to Row inserted, then choose the table that receives new rows.

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 or select an email template. 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 a new database row is inserted. Choose the project where the task should be created, then configure 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 rows are inserted.

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.

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 row is actually being inserted, not only edited.

  • 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 assignees still have access to that project.

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

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.