React to Schedules and Events

Most apps only do something while somebody is looking at them. A trigger lets an app act on its own: every morning at eight, when an email arrives, when a record changes in your ERP.net instance.

You describe what should happen in plain words — the App Builder sets everything up. A trigger is not an AI run: it does exactly what it was told, every time, and it costs no AI credits.

How it works

Something happens — a set time arrives, an email comes in, a record changes — and your app's trigger starts. It can refresh the app's tables, read or update data in your ERP.net instance, prepare a PDF report, and send emails or notifications. Nobody needs to have the app open.

Adding a trigger

Just say what should happen, in plain words:

Every weekday at 07:30, refresh the "open orders" table from ERP.net.

When an email arrives in the support mailbox, add a row to the "inbox" table
with the sender, the subject and the date.

When a webhook is called, look up the order and mark it as shipped.

The builder sets up the trigger and tells you where it lives.

More things to ask for

Scheduled work:

Every night at 23:00, write today's total stock quantity into the
"daily stock snapshots" table.

Every Monday at 08:00, email last week's sales summary as a PDF
to sales@company.com.

On the first day of each month at 06:00, recalculate the customer
balances and store them in the app.

Reacting to things that happen:

When a webhook is called with a tracking number, mark the matching
order as shipped and notify me.

When an email arrives in the orders mailbox, save the sender, subject
and date, so the app can show unprocessed orders.

Small adjustments later:

Pause the nightly stock trigger until next week.

Rename the trigger to "Morning orders refresh" and move it to 06:45.

Each of these is one sentence to the builder — and the trigger appears in the Triggers tab.

Changing only when a trigger runs

To move a scheduled trigger, just say the new time. The builder changes only the schedule — the script, the instance it is tied to, and its other settings stay exactly as they were.

Move the daily stock snapshot to 07:30.

Run the order sync every 30 minutes instead of once a day.

When the trigger's name mentions the time, the builder updates the name too. You can also just rename a trigger:

Rename the trigger to "Daily stock snapshot at 19:00" and move it to 19:00.

The Triggers tab shows each scheduled trigger's next run in its own timezone, or "paused" while it is switched off. Switching a trigger back on needs nothing else; it runs at its next scheduled time.

Watching them run

Open the app in the App Builder, go to the Backend tab and choose Triggers. For each trigger you see:

• when it will run next, and when it last ran,
• whether each run succeeded, how long it took, and anything that went wrong,
• a switch to pause it and a button to delete it.

Runs are kept for 30 days.

What a trigger can do

• refresh the app's tables, so the app shows fresh data next time somebody opens it;
• read and write data in your ERP.net instance, even while nobody is connected;
• prepare a PDF report from a simple page layout and send it by email;
• send a notification to you when something needs attention;
• use what started it — the email content, the changed record, the time it ran.

PDF reports by email

The most common use of a trigger: prepare a document on a schedule and email it. Just ask:

Every working day at 07:00, make a PDF with the current stock by product
and email it to warehouse@company.com.

Every Monday, email last week's sales by customer as a PDF to me and the sales manager.

What to expect:

• The PDF has headings, paragraphs, lists and tables. Long tables continue on the next page with the column headers repeated. Bulgarian and other Cyrillic text works. Pictures and custom fonts are not included.
• A copy is kept in the app's files, so you can open earlier reports later.
• The email comes from the Operator no-reply address. Up to 10 recipients per email, 20 emails per run and 200 per app per day.
• If sending fails (a wrong address, the daily limit), the run is marked as failed with the reason, and you can see it in the Triggers tab.

These emails are for reports and notices tied to your business, not for newsletters or mailing lists.

Separate data for each ERP.net instance

Some apps keep the same kind of data separately for each instance — for example, one row of daily stock figures per instance. When the builder creates a trigger for such data, it ties the trigger to the instance you are working with. From then on, the trigger reads and writes exactly that instance's data, even though nobody has the app open.

The Triggers tab shows each trigger's instance, or "all instances" when it has none.

Live refresh

If the app happens to be open while a trigger updates its data, the page refreshes itself straight away — no manual reload needed.

Good to know

• Triggers need a Pro app and Design access.
• A paused trigger keeps its history; a deleted one removes the schedule it created.
• Failures are recorded, not retried — check the runs list when something looks stale.
• If the work needs judgement rather than a fixed recipe, use an automation with an agent instead.