Mankomail

Schedule ​

Starts the workflow on a schedule, with no triggering email. The planned time, the actual time and the time zone land in data.schedule.

The Schedule trigger starts the workflow at regular intervals, with no triggering email: every N minutes, or following a cron expression ("every Monday at 8am"). Use it for daily digests, periodic exports, follow-ups, or to poll a service that has no webhook.

The run has no triggering email: nodes that act on the triggering email (reply in the thread, Move, Flag) cannot be used after this trigger, and the editor reports them as a blocking error. Send still works when you choose the sending mailbox on the node.

At a glance ​

  • Type: trigger.schedule · version 1
  • Category: Triggers
  • Kind: Trigger — starts a run
  • Effect: No external effect (none) — nothing is written outside Mankomail; safe to replay
  • Needs a carrier email: No
  • Connection: None
  • Outputs: main

Parameters ​

mode ​

Cadence

  • Type: One choice (options)
  • Required: Yes
  • Default: interval
  • Options:
    • interval — Every N minutes: The simplest: one run at a fixed interval.
    • cron — Cron expression: For "every Monday at 8am" and cadences N minutes cannot express.

everyMinutes ​

Every (minutes)

  • Type: Number (number)
  • Required: No
  • Default: 60
  • Whole number, from 5 to 44640
  • Shown when: mode is interval

cron ​

Cron expression — Five fields: minute, hour, day of month, month, day of week. 0 8 * * 1 = every Monday at 8am. An expression firing more often than every 5 minutes is refused.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 120 characters at most
  • Example: 0 8 * * 1
  • Shown when: mode is cron
  • Expressions: {{ }} not accepted

timezone ​

Time zone — IANA name (Europe/Paris). Empty = UTC.

  • Type: Text (string)
  • Required: No
  • Default: "" (empty)
  • 64 characters at most
  • Example: Europe/Paris
  • Expressions: {{ }} not accepted

Outputs ​

  • main — Taken by every run started by an occurrence of the schedule.

Data produced ​

What this node adds to the run data, and how to read it in an expression. <step> stands for the step key: the node name turned into an identifier (see Data and expressions).

  • {{ data.schedule.plannedFor }} — string. The scheduled time of this occurrence (the round time you asked for, such as 08:00), ISO 8601 in UTC.
  • {{ data.schedule.firedAt }} — string. The time the run was actually created, ISO 8601 in UTC. A few seconds after plannedFor, or more after a catch-up.
  • {{ data.schedule.timezone }} — string. The time zone used to compute the occurrences: the IANA name set on the node, or UTC when the field is empty.

Example ​

Send a summary every weekday morning. Add a Schedule trigger with:

mode       cron
cron       0 8 * * 1-5
timezone   Europe/Paris

Each weekday at 08:00 Paris time, one run starts on the main port with data.schedule.plannedFor set to that 08:00 (written in UTC). A downstream node can title its email Summary for {{ data.schedule.plannedFor }}.

To fetch what changed in Notion since the previous run, pass {{ data.schedule.plannedFor }} to the "Entries created or edited since…" operation of the Notion node, or use the dedicated Notion entry changed trigger, which keeps its own position.

Tips ​

  • The shortest cadence is every 5 minutes, in both modes: a cron expression that would fire more often is refused. In interval mode the maximum is 44,640 minutes (31 days).
  • Cron has five fields: minute, hour, day of month, month, day of week. With a time zone, daylight saving changes are taken into account. The node panel lists the next occurrences, computed exactly as publishing will arm them.
  • The schedule is armed on publication and lives in the database: a restart loses nothing, and the same occurrence never starts two runs.
  • After an outage, only the last missed occurrence is caught up, within a few minutes; earlier missed occurrences are not replayed.
  • A paused workflow keeps its schedule but starts nothing; resuming does not require publishing again. Unpublishing, archiving or removing the node stops the schedule.
  • When you test from this trigger in the editor, no time is supplied: data.schedule is absent from a test run, so expressions that read it render empty, with a warning.