Scope

The scope answers one question for every email that arrives: may this email enter the workflows? It is decided when the email is received, before any workflow runs and before any AI model sees it. An email out of scope is processed by no workflow, but it stays in the mirror and remains visible in the webmail: nothing is deleted or hidden.

The scope looks at the sender only — its address and its domain. Routing by recipient, subject, content or attachment is the job of trigger conditions, not of the scope.

Two layers of rules

	Organisation rules	My rules
Who sets them	an administrator, in Administration → Scope	each member for themselves, in Settings → My scope
Applies to	every member, every mailbox	the member's own mailboxes
Modes	exclusions only	"Process everything, except…" or "Process only…"
Lists	Domains, Addresses	Domains, Addresses
Can be bypassed	no: neither a member nor a workflow can lift them	—

The organisation decides first. Its rules apply to everyone and cannot be bypassed. Each member's rules apply next, and can only narrow things further, never widen them: a member in "Process only…" mode who lists a domain the organisation excluded does not bring it back.

Typical uses:

• organisation: exclude the company's own domain, so internal mail never enters workflows; exclude sensitive addresses (management, HR, the data protection officer);
• member: exclude a personal contact or a sensitive client; or, in "Process only…" mode, let workflows see only mail from two client domains.

Organisation rules

1. Open Administration → Scope (administrators only).
2. Under "Organisation rules" — "The senders workflows will never process, for everyone." — add entries to Domains and Addresses.
3. Save. The page confirms "Organisation scope saved."

The organisation layer has no "process only" mode, by design: it could otherwise open what a member's rules would then widen.

My rules

1. Open Settings → My scope.
2. Under "My rules", choose the Mode:
   • Process everything, except… (default) — "Your workflows see all your mail, apart from the senders listed below.";
   • Process only… — "Your workflows only see mail from the senders listed below, and nothing else."
3. Fill in Domains and Addresses, then save ("Scope saved.").

Process only… with empty lists

In "Process only…" mode with empty lists, no mail at all is processed by your workflows. The page shows a warning in that case.

The default — "Process everything, except…" with empty lists — processes everything. A member can only edit their own rules; an administrator cannot edit another member's.

How entries match

Entry	Matches	Example
A domain (client.example or @client.example)	the sender's domain and its subdomains	client.example matches anna@client.example and anna@mail.client.example, but not anna@otherclient.example
A full address (ceo@company.example)	that exact address	—

• Case is ignored, in the whole address: Ceo@Company.example and ceo@company.example are the same entry.
• Entries are normalised on save: lower case, leading @ removed, trailing dot removed. "The list shown after saving is the one that applies."
• No wildcards or patterns: a domain entry already covers its subdomains.
• Lists hold at most 500 entries each ("List full: 500 entries maximum.").
• An email with no readable sender is never excluded by an exclusion, and is excluded in "Process only…" mode.

The order of evaluation

For each new email, the checks run in this order, and the first that applies decides:

1. Organisation addresses, then organisation domains → "Excluded — organisation scope".
2. Member rules:
   • "Process everything, except…": a listed address or domain → "Excluded — member scope";
   • "Process only…": an email whose sender is not listed → "Excluded — member scope".
3. Guardrails → "Excluded — guardrail" (see below).
4. Otherwise the email is in scope, and the trigger conditions of your published workflows are evaluated: "Received, unmatched" if none matches, "Dispatched" if at least one workflow starts.

The outcome of each email, and the rule that decided it, are shown under Activity → Received, in the "Decided by" column. The dashboard counts excluded emails ("By scope rules or a guardrail").

Only emails that can start a workflow are evaluated: new emails delivered after the mailbox was connected, outside Sent, Spam, Trash and Drafts. See Mailboxes and the mirror.

Guardrails

After the scope rules, four guardrails stop emails that should never start an automation. They are always on and cannot be turned off.

Guardrail	Shown as	Detects
sent by self	"Guardrail: sent by self"	a message produced by Mankomail itself (by a workflow or the webmail) that comes back through sync — this prevents a workflow from answering its own messages
auto-reply	"Guardrail: auto-reply"	automatic replies: out-of-office and similar, detected by their headers (Auto-Submitted, X-Autoreply…) and typical subjects
mailing list	"Guardrail: mailing list"	mailing-list and newsletter emails, detected by their headers (List-Id, List-Unsubscribe, bulk precedence…)
no-reply sender	"Guardrail: no-reply sender"	senders whose address before the @ reads like a no-reply address (noreply, donotreply…)

Because of the guardrails, a trigger condition such as signals.isMailingList equals true never matches in practice. The signal fields remain useful to exclude, for example signals.isAutoReply equals false.

What an out-of-scope email still does

	In scope	Out of scope
Stored in the mirror	yes	yes
Visible in the webmail, searchable	yes	yes
Starts workflows	if a trigger matches	never
Analysed by the analyzer and sent to its AI	yes	no — counted only ("emails excluded by the scope, neither grouped nor sent to AI")
Used to suggest address-book profiles	yes	no
Read by the workflow assistant's tools	yes	no
Used for a test run, a manual run or a replay	yes	no — refused (workflow.message_out_of_scope)
Used to evaluate a prompt (sample, few-shot examples)	yes	no — left out

One case to know about:

• Thread context. When an in-scope email arrives in a thread, earlier messages of the same thread can be given to an AI node as context, even if their sender is out of scope.

When rules change

A change of scope applies to emails that arrive afterwards. Emails already received are not evaluated again: widening your scope does not process the emails it excluded before, and narrowing it does not cancel runs already started. What you start by hand, however, follows the scope of the moment: once a sender is excluded, a test run, a replay or the assistant no longer processes their emails, even those received before.

My trigger policy

The My scope tab also holds "My trigger policy": what happens when several of your workflows match the same email.

• Every workflow that matches (default): each matching workflow gets its own run.
• The first match, and only that one: workflows are tried in priority order and the first match is the only one that runs, the way Outlook rules work. The order is the Rank in each workflow's Settings tab, from 0 to 9999, lowest first; workflows with no rank come after, in creation order.

Whatever the policy, a workflow runs at most once per email, even when several of its email triggers match. The policy is described with the other trigger rules in Triggers and conditions.

What the scope is not

• Not a mailbox selector. A published workflow listens to every mailbox of its owner that is not disconnected. To limit a workflow to one mailbox, use a trigger condition on the recipients (for example recipients.emails equals the mailbox address).
• Not a storage filter. There is no option to keep emails of certain senders out of the mirror.
• Not about other members. Each member's mailboxes, workflows and runs belong to them; another member's mailboxes are never processed by your workflows.

Through the API

Route	Who	What
GET / PUT /api/v1/admin/scope	administrators	the organisation rules: { "excludedDomains": […], "excludedEmails": […] }
GET / PUT /api/v1/scope	the signed-in member	their own rules: { "mode": "exclude" | "include", "domains": […], "emails": […] }
GET / PUT /api/v1/dispatch-policy	the signed-in member	the trigger policy: { "mode": "all" | "priority" }

PUT replaces the whole object, and the response returns the lists as normalised. The rank of a workflow is set with PATCH /api/v1/workflows/:id and { "dispatchPriority": 0 } (or null).

Related pages

• Mailboxes and the mirror
• Triggers and conditions
• Governance
• Analyzer