Review and approvals

Mankomail gives you several ways to keep a person in control of what workflows do, from the lightest to the strictest:

• Drafts and the Morning review. A workflow prepares replies as drafts; someone reads them, corrects them if needed, and sends them.
• Approval requests. An Approval node pauses the run until someone approves or rejects, then the run continues on the matching branch.
• The Activity page. It shows what is waiting for a decision, what ran, what is waiting, what came in and what went out.
• Sending safeguards. A switch that holds every real send, and an hourly cap.

Draft or send

The Send node is the only mail node that makes a message exist. Its What to do with it setting decides how much control you keep:

• Save as draft (the default): nothing leaves. The draft is saved in the real mailbox and appears in the Morning review, waiting for a person.
• Send: the message leaves for real, through the sending chain and its safeguards.

Writing a message (Compose or Compose (AI)) and making it exist (Send) are two separate nodes. This is what lets you place an Approval node between them, or keep Send on draft and review in the morning.

The Morning review

Review in the main navigation opens the Morning review: the drafts your workflows prepared, to read before they leave. A counter next to Review shows how many are waiting.

Each draft shows the mailbox it was written from, its recipients, its subject and the workflow that produced it. Open it to read the preview: the body rendered like a received email, its attachments, and Open the execution to see the run that produced it. Remote images are blocked until you click Show images.

Action	Effect
Send	The draft leaves as it is, through the same sending chain as the webmail.
Edit before sending	Opens the webmail composer pre-filled with the draft (recipients, subject, body, attachments). Sending from it sends the corrected version.
Reject	Removes the draft from the queue, with an optional reason. The draft stays in your mailbox.
Snooze until tomorrow	Removes the draft from the queue for 24 hours.
Send selection	Sends the selected drafts at once, up to 50. Those that cannot leave are counted apart.

Keyboard shortcuts: j and k move to the next and previous draft, Enter sends the current one, # rejects it. Shortcuts are inactive while you type in a field.

Filter the queue by mailbox to review one mailbox at a time.

What you did elsewhere counts. If you sent or deleted the draft from Gmail, Outlook or another tab, the Review notices it and the draft leaves the queue; acting on it again shows that it was already handled. A draft is never sent twice.

Only drafts saved by workflows appear in the Review. A draft you write yourself in the webmail does not.

Approval requests

The Approval node suspends a run and asks a person to decide. The action to validate (sending the reply, writing to a CRM) goes on its approved branch, and the refusal is a branch of its own (rejected), so you can handle it.

• Who decides. The request goes to the member the run belongs to, that is the owner of the workflow, as an email sent from their mailbox to themselves. Its subject starts with [Approval], followed by the question.
• What they see. The question (title) and the details (details) set on the node, both of which accept expressions: quote the client, the amount and the draft so the decision can be made from the email alone. The request also carries the workflow name and an extract of the triggering email (sender, subject, date).
• Deciding from the email. The email has two buttons, Approve and Reject. Each is a single-use link: clicking records the decision and shows a confirmation page, without signing in. A second click shows the decision that already stands.
• Deciding in the app. Pending requests appear in Activity › To do with Approve and Reject buttons, and a notification is posted when a request arrives.
• One decision. The first decision recorded wins, whichever channel it came from.
• Reminder and timeout. A reminder email is sent halfway through the time limit by default. When nobody answers in time, the product decides alone according to the node's "Without an answer" setting: Reject by default, so a forgotten request never turns into a send. The time limit is set on each node, 48 hours by default and 30 days at most.

While it waits, the run has the status Waiting; nothing is held in memory, so a server restart loses nothing. In a test run, the node does not wait: it takes approved at once and sends no request.

Links opened automatically

Some security gateways open the links of incoming emails automatically, which could record a decision. If this is the case in your organisation, decide in the app and keep "Without an answer" on Reject.

Review or approval: which one

	Draft + Morning review	Approval node
The run	ends after saving the draft	waits for the decision, then continues
What can follow	nothing: the person sends by hand	any step on approved or rejected (update a table, notify, send)
Correcting the text	yes, in the composer	no: the decision is approve or reject
Deciding from a phone	from the Review	from the email, in one tap
Without an answer	the draft waits in the queue	the node decides after its time limit

Use the Review for replies a person will reread and adjust. Use an Approval when what happens after the decision must be automated, for example writing the sent date to a table.

The Activity page

Activity gathers what your workflows did and what they wait for. A counter next to Activity shows how many items need your action.

Tab	What it shows
To do	The approval requests waiting for you, and the failures of the last 24 hours nobody has seen yet.
Runs	Every run of your workflows, filtered by status, workflow, period and type (live, test runs or both), with Replay and Cancel run. See Runs.
Waiting	Runs paused by a Wait node, and when they will resume.
Received	What happened to each received email: excluded by scope, stopped by a guardrail, received with no matching workflow, or dispatched, and what decided it.
Sent	The sending journal, described below.

Every list is limited to your own scope: you see your mailboxes, your workflows and your requests.

The sending journal

Activity › Sent answers "who received what, when, and through which workflow". It lists every message that left or was saved as a draft: by a workflow, by hand in the webmail, or as an approval request.

• Columns: date, mailbox, recipients, subject, mode (Draft or Sent), status, and the workflow (or "Written by hand", "Approval request").
• Statuses: Pending, Held (sending suspended), Running, Delivered, Failed, Cancelled, Unknown.
• Filters: mailbox, mode, and a search on subject or recipient. The API (GET /api/v1/sending/journal) also filters by workflow and period.
• Export as CSV exports the whole filtered result, not only the page on screen, up to 50,000 rows. When the limit is reached, the last line of the file says that the export is truncated.

The journal never stores the body of messages. It is kept as long as live runs (180 days).

Sending safeguards

Two switches decide whether real sends leave. A message only leaves if both are open:

• Instance: the SEND_ENABLED setting of the server. It can only be changed in the configuration, followed by a restart.
• Organisation: in Administration › Sending, an administrator clicks Stop sending or Resume sending. It applies right away, with no restart.

When sending is stopped, real sends (replies, forwards, new messages, approval request emails) are held, not lost: they show as Held in the journal and leave when sending resumes, without being sent twice. Everything that never leaves the instance keeps working: drafts, filing, labels, flags, analyses.

An hourly cap (SEND_MAX_PER_HOUR, 100 by default) limits real sends. Beyond it, sends from workflows wait their turn rather than being dropped. See Environment variables.

Drafts are never held by the switches or the cap.

Related pages

• Approval and Send
• Runs: statuses, replay and resume
• Wait: waiting for time or an event instead of a person
• Governance: node policy and organisation safeguards