Scheduled Jobs
Work your ERP.net data does on its own — every night, every Monday, or at the top of the hour — without anyone pressing a button.
Every ERP.net company has a handful of tasks that must happen on a schedule: a stock snapshot saved every evening, a report emailed to the management team on Monday morning, balances recalculated at the end of each month. Traditionally these need a developer to write a job and somewhere to run it. In Operator you describe the task, say when it should run, and a small app with a trigger does the rest — reliably, at the time you chose, in your timezone.
What you get
- A recurring job that runs on its own at the schedule you define — at a fixed time, or repeatedly every N minutes.
- Your chosen output each run: numbers stored as data, a PDF report, an email with the report attached, records created or updated in your ERP.net instance.
- A live view of each run in the app's Triggers tab — when it last ran, what it did, and whether it succeeded.
- A schedule that follows your timezone, so "19:00" means 19:00 where you are.
Example
You say: "every weekday at 19:00, save the current stock levels for our warehouse and email me a PDF summary." Operator builds a small app with a trigger, sets the schedule, and writes the task itself. From then on the report appears in your inbox at 19:00 each weekday — you can watch each run in the app's Triggers tab.
How to ask for one
Describe the task and when it should happen, in your own words:
every night at midnight, take a snapshot of product balances and store it
send the sales report as a PDF to sales@company.com every Monday at 8:00
at the end of each month, recalculate the running balances for all customers
Useful things to mention:
- What to do — which numbers to collect, which report to build, which records to create or update.
- When to do it — a fixed time ("every day at 19:00"), or an interval ("every 15 minutes").
- The output — save it as data, produce a PDF, send an email — or several of these together.
- Recipients, if the job emails anyone: addresses, subject line, who it should look like it comes from.
Operator asks only what it genuinely needs, builds the app with the trigger, and shows you the schedule before switching it on.
What to check before approving
- The time and timezone. Schedules run in the timezone shown on the trigger — check that 19:00 is 19:00 where the work should happen.
- The task's rules. For a stock snapshot: which warehouse, which products, which numbers (available quantity, reserved, ordered). A run is only as good as its instructions.
- Email details. The sender address, the recipients, and the attached file name are set once and reused every run.
- The first run. You don't have to wait for the schedule: ask Operator to run the trigger once right away and check the result in the Triggers tab.
Changing it later
- Change only the time — "move it to 18:30" or "run it every 30 minutes instead" — and the schedule updates without touching the task.
- Pause it — "pause the stock report" — and it stops running but keeps its instructions; "resume it" brings it back.
- Rename it so it is easy to find among your triggers.
- Change what it does — "also include slow movers in the report" — and the task is rewritten for the next run.
Good to know
- Each run is recorded with its outcome, so a missed or failed run is visible — not silent. If a run fails, the error is shown, not hidden.
- Reports are produced with clean tables, headings, and support Cyrillic, so Bulgarian names and product descriptions print correctly.
- Email sending has everyday limits — up to ten recipients per email and a daily cap per app — sized for routine business reports, not bulk campaigns.
- When several people work with the same ERP.net instance, each app sees its own data separate from other apps', unless you deliberately connect it to shared storage.
- A trigger can also react to events, not just the clock — for example, when a record changes or a webhook arrives. See React to Schedules and Events.