Mankomail

Move ​

Adds or removes folders/labels on the triggering email, through the mirror (immediately visible in the mailbox).

Move adds or removes folders and labels on the triggering email. The change goes through the mailbox mirror and shows up in the member's real mailbox. Use it to file sorted mail, archive what has been handled, or tag emails for a colleague.

Move acts on the email that triggered the run, so it needs one: it fits under an email trigger, not under a schedule or a webhook. To change the read or flagged state instead, use Flag.

At a glance ​

  • Type: mail.move · version 1
  • Category: Actions
  • Kind: Step — one stage of a run
  • Effect: Writes outside (external_write) — writes outside Mankomail; described instead of performed during a test run
  • Needs a carrier email: Yes — it acts on the email that started the run
  • Connection: None
  • Inputs: main
  • Outputs: main

Parameters ​

addLabels ​

Labels to add — Folders or labels added to the email. Exact names depend on the mailbox provider.

  • Type: List of items (collection)
  • Required: No
  • At most 20 items
  • Each item has:
    • folder — Folder or label. Picked from the mailbox list, or typed by identifier — an expression such as {{ data.categorize_1.category }} is accepted there.
      • Type: Remote resource (resourceLocator)
      • Required: Yes
      • Ways to choose: pick from a list, type an ID (mail.folder)

removeLabels ​

Labels to remove — Folders or labels removed from the email (for instance "INBOX" to archive).

  • Type: List of items (collection)
  • Required: No
  • At most 20 items
  • Each item has:
    • folder — Folder or label. Picked from the mailbox list, or typed by identifier — an expression such as {{ data.categorize_1.category }} is accepted there.
      • Type: Remote resource (resourceLocator)
      • Required: Yes
      • Ways to choose: pick from a list, type an ID (mail.folder)

Outputs ​

  • main

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.<step>.opId }} — string. The identifier of the recorded outbound operation. Stable when the step is retried. In a test run it is simulated:mail.move.
  • {{ data.<step>.simulated }} — boolean. true in a test run: the email was not touched, the run detail describes what would have happened.
  • {{ data.<step>.addLabels }} — array of string. The identifiers of the folders or labels added, as resolved for this run.
  • {{ data.<step>.removeLabels }} — array of string. The identifiers of the folders or labels removed, as resolved for this run.

Example ​

After a Categorize branch cat:Invoice, file supplier invoices and take them out of the inbox. Add a Move node:

addLabels:
  - folder: "Invoices"   (picked from the mailbox list)
removeLabels:
  - folder: "INBOX"

The step data reads:

json
{
  "opId": "9a40…",
  "simulated": false,
  "addLabels": ["Label_3"],
  "removeLabels": ["INBOX"]
}

Label_3 is the provider identifier behind the "Invoices" label picked in the list.

Folders and labels ​

Each entry is picked from the list of the mailbox's folders, or typed by identifier. What is stored is the provider's identifier, not the displayed name: the label identifier at Gmail, the folder identifier at Microsoft, the folder path for IMAP. At Gmail and Microsoft, renaming a folder therefore does not break the workflow; in IMAP, the path changes with the name.

The identifier field accepts an expression, for instance a value computed by an earlier step. The value must be an identifier the provider recognises, not a display name.

What happens depends on the provider, because an email sits in a single folder at Microsoft and in IMAP, but can carry several labels at Gmail:

  • Gmail: labels are added and removed as listed. Removing INBOX archives the email.
  • Microsoft: the first added value that is a known folder becomes the destination and the email is moved there. Removing INBOX with no destination moves the email to the Archive folder. Any other added value becomes a category.
  • IMAP: the first added value that is a known folder path becomes the destination. Removing INBOX with no destination moves the email to the archive folder. Any other added value becomes a keyword on the message.

In every case, removing INBOX archives: it never deletes.

Tips ​

  • Nothing to do is an error. With both lists empty, the step fails with node_nothing_to_do rather than doing nothing silently. Each list holds at most 20 entries.
  • No triggering email. Workflows whose trigger brings no email are refused at validation; at run time the step fails with node_missing_email.
  • Retries are safe. The operation is keyed on the step: retrying the step does not apply it twice. A failure to record the operation is retried (node_service_failed).
  • Test runs. In test runs the email is not touched; the run detail says which labels would have been added or removed. See Mailboxes for how the mirror applies changes.