70.3 Using Lookup Tables
70.3.1 Overview ¶
Lookup tables and global placeholders are configured in the program options (see chapter 40.23 and chapter 40.24) - this chapter describes their use as placeholders in tasks. Lookup tables resolve a value (e.g. client name) based on email properties (e.g. sender domain); global placeholders are fixed constants.
In all input fields that support placeholders, you can insert these mappings directly - typical applications: dynamic path construction, client routing, code-to-plain-text conversion.
70.3.2 Syntax ¶
| Placeholder |
Meaning |
<CSVMapping{Clients}> |
Searches the table “Clients” for a match and returns the result column |
<SimpleMapping{ArchivePath}> |
Returns the global placeholder “ArchivePath” (fixed value) |
Selection is made in the placeholder menu under “Tables” - one entry appears for each defined table and each global placeholder.
70.3.3 How a Lookup Table Query Works ¶
When an email is processed with placeholder <CSVMapping{Clients}>:
- The program reads the match columns configured in the table from the email (e.g. sender domain)
- Searches the table for a row whose values all match the email values (AND combination of the match columns)
- On match: returns the value of the result column
- On multiple matches: takes the first and writes a warning to the error log
- On no match: returns an empty string or the configured default value
The comparison can, depending on the column configuration, be exact, a substring match, or a regex match.
70.3.4 Example: Client Routing ¶
Table “Clients”:
| Sender domain |
Client name |
| mueller-gmbh.de |
Mueller GmbH |
| schulze-kg.de |
Schulze KG |
| meier-ag.de |
Meier AG |
In the Save Attachments task:
| Field |
Value |
| Path |
D:\IncomingInvoices\<CSVMapping{Clients}>\<EmailYear4>\<EmailMonth> |
Incoming email from info@mueller-gmbh.de on 2026-05-07:
- The table is searched with sender domain
mueller-gmbh.de
- Match in row 1: client name =
Mueller GmbH
- Path becomes:
D:\IncomingInvoices\Mueller GmbH\2026\05
For an email from kontakt@unknown-firm.de:
- No match -> path would become
D:\IncomingInvoices\\2026\05 (with a double backslash because the value is empty) - therefore a default value in the table is usually a good idea (see 70.3.5)
70.3.5 Behavior on No Match ¶
In the table definitions (see chapter 40.23), you can define per table what happens when there is no match:
| Configuration |
Behavior |
| Default |
Empty string |
| Default value |
Configured default value (e.g. “Unknown”) |
| Set status flag |
Set profile status to “Error” or “Skipped” - the task is aborted |
This avoids the situation that emails without a match land in an unintentionally named path - instead, they can be collected in a dedicated “Unknown” folder, or the entire processing can be skipped.
70.3.6 Global Placeholders ¶
Global placeholders (see chapter 40.24) are simpler: no matching, just a fixed value. Example:
- Global placeholder “ArchivePath” with value
D:\IncomingInvoices
- Usage:
<SimpleMapping{ArchivePath}>\<EmailYear4>\<EmailMonth>
- Result:
D:\IncomingInvoices\2026\05
When the path changes (e.g. switching the archive drive), the value is changed once in the program options - all profiles that use the placeholder pick up the change automatically.
70.3.7 Use case ¶
Client directory structure
Lookup table “Clients” with 50 rows. Path in Save Attachments: <SimpleMapping{ArchivePath}>\<CSVMapping{Clients}>\<EmailYear4>\<EmailMonth>. Incoming emails automatically land in the correct client folder - for a new client, simply adding a row to the table is enough.
70.3.8 Multi-Column Matching ¶
A lookup table can have multiple match columns - a match then requires all values to coincide. Example:
Table “Suppliers”:
| Sender domain |
Subject contains |
Supplier category |
| mueller-gmbh.de |
Order |
Main supplier Order |
| mueller-gmbh.de |
Invoice |
Main supplier Accounting |
| schulze-kg.de |
Order |
Secondary supplier Order |
An email from info@mueller-gmbh.de with subject “Order 12345” -> match in row 1 -> category Main supplier Order.
This way, finer classifications can be modeled without maintaining separate tables for each key combination.
70.3.9 Tips ¶
- Use the default value for unknown keys - otherwise emails will land in unintended paths
- On multiple matches the program takes the first - the order in the table is relevant. In case of conflicts, the table configuration should be refined