How to Set Up Auto Schedules

Auto Schedules let you run an automation on a repeating clock schedule: every morning at 9am, every Monday, the first of each month, or any custom cadence you define. Unlike automations (which fire in response to an event) and auto queues (which work through contacts one by one over time), a schedule fires across your whole source at once, on a fixed recurrence.

You will find Auto Schedules at https://app.trustpager.com/auto/schedules.

How it differs from automations and auto queues

• Automations: event-driven. They fire when something happens (opportunity stage changes, form submitted, and so on).
• Auto Queues: contact-driven sequences. A contact enrols and works through a series of steps over time.
• Auto Schedules: clock-driven. At the scheduled time, TrustPager resolves your Source and fires your automation once for each row it produces.

Create a schedule

1. Go to https://app.trustpager.com/auto/schedules and click Create Schedule.
2. Give it a name and an optional description.
3. Choose the Automation to run. This is the automation that fires for each row your Source produces. Build and test the automation before wiring it to a schedule.
4. Choose the Source Data (see below).
5. Set the recurrence (see below).
6. Save. A new schedule is created paused on purpose, so nothing fires until you have finished configuring the Source. Switch it on when you are ready.

Choose your Source Data

The Source Data panel on the schedule detail page controls what feeds the attached automation each time the schedule runs. Each row the Source produces fires the automation once, with that row's fields available as {{tokens}} inside every action.

There are seven Sources. Each one is limited by the shape of its own data, so a schedule cannot quietly grow into something that fires thousands of times as your workspace fills up.

Report

Sends one email per named recipient, carrying a live count and the list of matching records. It never fires once per record, so the work is the same whether the answer is 18 records or 25,000.

This is the right Source whenever what you actually want to know is how many, and which ones. It replaces the pattern of creating a task per matching record, which produces a pile of tasks nobody works through.

• Send to: pick staff members, and add plain email addresses for shared inboxes that have no user account. Up to 20 recipients in total. Each person gets their own copy, scoped to what they are allowed to see.
• Count and list: optionally point the report at any of the other Sources below. The email then carries the exact total plus the matching records by name.
• Records listed in the email: how many to list by name, up to 200. The total is always exact; anything beyond this limit is shown as "and N more" with a link to the full report.
• Full report link: the dashboard "see the full report" points at.

Workflow Stage

The opportunities sitting in the stages you name, within one pipeline. Use it for dispatchers, follow-up sweeps, and anything that should act on each opportunity in a stage.

Archived, won and lost opportunities are always excluded, as are opportunities in an archived pipeline. You cannot switch those exclusions off.

You must name at least one stage. Choosing a whole pipeline is not allowed, because a pipeline keeps growing and a schedule pointed at all of it would keep growing with it. If you want to watch a whole workflow, use a Report instead: it gives you the count and the list in one email at any size.

Expiry Date

The records whose date field lands inside a window you set, measured in days from today. Use it for licence and certification renewals, warranty expiry, contract end dates, and any other "coming up in N days" reminder.

• Works on contacts or opportunities against any date/time custom field, or on work orders against each work order's own scheduled date (see below).
• Set both bounds to the same number for an exact day: 30 and 30 means "exactly 30 days from now".
• Use 0 and 0 for "lapses today", or a negative number for already lapsed.
• At least one bound is required, because the window is what keeps this Source bounded.
• Archived records are always excluded.
• For contacts you can also restrict by contact type, and choose whether to skip anyone who has unsubscribed. Leave that on for customer notices. Turn it off for internal compliance reminders, so a staff member's licence reminder does not stop because they once unsubscribed from a newsletter.

Remind each trade the day before their job

Choose Work orders as the records and the window applies to each work order's own scheduled date, not the opportunity's. A job with several trades on different days therefore reminds each trade on their own day, and never tells a trade booked later that their job is tomorrow.

• Set both bounds to 1 for "tomorrow", in the timezone set on the schedule.
• Work order statuses (required): pick the statuses that mean the trade is booked (for example Accepted). A reminder must name at least one, because "every status" would also remind a trade who declined, was never offered the job, or whose job was cancelled. If a status you picked is later renamed or deleted, the run fails with a clear message rather than quietly sending nothing. A Report that only counts work orders can leave this empty to count every status, since it reaches no trade.
• Only work orders with a trade attached is on by default, so the automation never runs with nobody to send to.
• Work orders on archived or lost opportunities are always excluded.
• Each work order runs the automation once. In a Send Email step, send to {{stakeholder_email}} and use {{stakeholder_name}}, {{schedule_date}}, {{schedule_time}}, {{work_order_status}} and your work order fields in the message. Opportunity and contact tokens such as {{deal.name}} work too.
• The repeat interval counts per work order per date: with a repeat interval of 1 day, a trade is reminded once, and if the job is moved to another day they are reminded again for the new day.

Staff Members

The people in your workspace, which means headcount is the ceiling. Leave the picker empty to include everyone, or select specific people.

Anyone who has not accepted their invite yet is always excluded, since they cannot act on anything sent to them.

There is also a task-digest mode: switch on Only staff with open tasks and each person's open tasks are attached to their row, so one email can list exactly what is on their plate.

Stakeholder Group

The members of one stakeholder group, resolved fresh every time the schedule fires, so people added to the group later are picked up automatically. Archived contacts are always excluded.

External feed

TrustPager polls a URL you provide on each fire and creates an automation run for every new record. This is the right Source when your leads or records live in an external system that can expose a JSON endpoint.

Feed URL

The feed must return a flat, top-level JSON array of objects, for example:

[
  { "id": "123", "name": "Jane Smith", "email": "jane@company.com" },
  { "id": "124", "name": "Tom Brown", "email": "tom@company.com" }
]

Nested shapes such as { "results": [...] } are not supported: the feed must be a top-level array.

Most feed URLs include a secret access token embedded directly in the URL. Do not share or screenshot your feed URL. Treat it like a password, because anyone with it can read your feed data.

Unique ID field

Set this to the field in your feed that uniquely identifies each record (for example id, enquiry_id, listingId). TrustPager uses it to deduplicate: a record whose unique ID has already been seen will not fire the automation again, even if it reappears in the feed later.

A record is only marked as seen once its automation run dispatches successfully, so a failed run is retried on the next fire.

First run

• Seed only (default): TrustPager reads the current feed, marks every record as already seen, and imports nothing. From the next fire on, only genuinely new records are imported. Use this when your feed contains history you do not want to backfill.
• Import everything now: imports all current records on the first fire, then deduplicates from the next fire on.

Conditions (optional)

Filter which rows get imported with Only import rows where... conditions, for example Email is not empty. Blank, missing and "-" all count as empty. Rows that do not match are counted as skipped and are not imported.

Token names

Token names are sanitised from your feed's field names: lowercased, with any run of non-alphanumeric characters replaced by a single underscore. EnquiryID becomes {{enquiryid}}, Listing Category becomes {{listing_category}}. Rather than guessing, use Preview source to see the exact names available.

Fixed values

The automation fires once per run with a single fixed payload you define. There is no per-record iteration. Use it for scheduled jobs that need no record data, such as a recurring internal trigger or a ping to an external system.

Sending to a large list of contacts

Auto Schedules are an operational tool, not a broadcast tool, so there is no Source that sends to an arbitrary list of contacts. For a marketing send or any large contact broadcast, use Email Blasts at https://app.trustpager.com/growth/email-blasts, which has the audience snapshot, suppression and unsubscribe handling a broadcast needs.

How often a record can fire, and how many per run

Workflow Stage, Expiry Date, Staff Members and Stakeholder Group all select records, so each of them asks two questions about pace. Report, External feed and Fixed values are self-limiting and do not ask either one.

How often can the same record fire?

This is required, and you have to answer it explicitly. A record that matches today usually still matches tomorrow, so this decides whether it fires again.

• Every run is the right answer when your automation moves the record out of the Source. A dispatcher whose automation moves the opportunity to the next stage empties its own list, so there is nothing to hold back.
• A number of days is what an alert wants. "At most once a fortnight" means each record can only be raised once every 14 days, even while it keeps matching. Without this, an alert re-raises the same records every single run, forever.

Records per run

Caps how many records one run acts on, 100 by default and 500 at most. Nothing is dropped: leftovers go first on the next run, oldest waiting first, so a large backlog works through itself across runs instead of arriving all at once.

Preview before you switch it on

Use Preview source on the schedule detail page to resolve the Source live without firing anything. It shows how many records matched, how many one run would act on, and how many runs it would take to work through the current backlog. For a Report it shows the recipients and the live count. For an external feed it shows what was fetched, what is new, what was skipped by your conditions, what has already been seen, and the exact token names available.

Set the recurrence

Schedules run on a standard cron-style recurrence. Use the friendly time picker (set a time and pick days of the week) or enter a cron expression directly for a more custom cadence.

• Daily at 9am: every day, 09:00
• Every Monday at 8am: Monday only, 08:00
• Weekdays at 5pm: Mon to Fri, 17:00
• Monthly on the 1st at 9am: cron expression 0 9 1 * *

All times are interpreted in the timezone set on the schedule (Australia/Sydney by default). Set it deliberately, because it is not taken from your browser.

The detail page lists the next several planned fire times, so you can confirm the cadence before switching anything on.

Optional limits

• End date: the schedule stops firing after this date.
• Max runs: the schedule pauses itself after this many fires.

Leave both blank for an ongoing schedule.

Activate and monitor

Switch the schedule on from https://app.trustpager.com/auto/schedules. The next fire time is shown on the schedule card.

Every fire creates a run record. The detail page shows the full run history: when it fired, how many rows the Source produced, and whether anything failed.

To fire immediately without waiting for the next scheduled time, use Fire now on the detail page. This ignores the end date and max runs limits.

Troubleshooting

• Schedule not firing: confirm it is switched on, and that the attached automation is also enabled. Remember new schedules are created paused.
• It will not save, and asks for a repeat interval: the Source selects records, so you have to answer how often the same record can fire again. Pick "Every run" if your automation moves the record out of the Source, otherwise pick a number of days.
• It will not save, and asks for work order statuses: a work order reminder has to name the statuses that mean the trade is booked, for example Accepted. Pick at least one.
• It will not save, and says a whole pipeline is not allowed: name at least one stage. A pipeline keeps growing, so a schedule pointed at all of it would too. To watch the whole workflow, switch the Source to Report.
• A run was refused for matching too many records: the Source matched more than a single run will consider, so nothing was dispatched rather than acting on an arbitrary slice of it. Narrow it (fewer stages, a tighter window, a specific assignee), or switch the Source to Report, which handles any size in one email.
• Source is empty: use Preview source to check. An empty Source fires nothing and raises no error.
• A report reaches nobody: check the staff you picked are still in the workspace, or add a plain email address directly.
• Wrong timezone: times are evaluated in the timezone set on the schedule, not your browser timezone. Edit the schedule to change it.
• Automation errored: individual failures appear at https://app.trustpager.com/auto/errors. The schedule keeps firing on later runs.
• Feed returning zero new records: open Preview source and check the already-seen count. If everything is already seen, the feed has no new data. If nothing was fetched, the URL may be unreachable or returning an empty array; test it in your browser.
• Feed shape not supported: the feed must return a flat top-level JSON array. A nested object such as { "results": [...] } will not parse.
• Token names not matching: token names are sanitised. Use Preview source to see the exact names before wiring them into actions.