Email in/out & Notifications
WP-PFManagement can send and receive email natively — no external automation needed. There are three pieces: Email Accounts (configuration), the Outbox/Inbox entities (the record of every message), and Notifications (the rule that composes and sends one).
Email Accounts
Under Administration → Email Accounts you configure any number of:
- Outbox accounts (SMTP) — used to send mail. Host, port, encryption (STARTTLS/TLS, SSL, or none), optional auth, and a From address/name.
- Inbox accounts (IMAP/POP) — polled for incoming mail.
Each account has an active toggle; only active accounts are used. A credential is stored encrypted and is never shown again once saved (the form only tells you whether one is set).
The Outbox — the single outbound path
Every outgoing message, from any source, is a row in the native pfm_email_outbox entity. A producer creates a row in status ready (to/cc/bcc, subject, body, which outbox account to use); a background sender picks it up, moves it to sending, delivers it over SMTP, and leaves it sent or error (with the error message and attempt count). A transient failure retries with backoff before giving up.
Two things create outbox rows: the Notifications engine below, and WP-PFWorkflow's email node (a workflow can send mail through any configured outbox account).
The Inbox — captured as records
When at least one inbox account is active, incoming mail is polled and stored as a pfm_email_inbox record (from/to/subject/body/date/account/ attachments/Message-ID). Because it is a normal record, it fires the entity's native record.created event — a Business Rule or a WP-PFWorkflow workflow can react to new mail with no special wiring. Duplicate polls of the same message are recognised by Message-ID and never create a second row.
Notifications — "a Business Rule that sends an email"
Administration → Notifications works like a Business Rule: you pick an entity, an EQL condition, and when it applies (create, update, or both). Instead of "what it does", a Notification defines what it contains:
| Property | Description |
|---|---|
| Entity + condition | Same model as a Business Rule filter — when a saved record matches, the notification fires |
| Subject | One line, with {{field}} tokens |
| Body | Multi-line, with {{field}} tokens |
| Recipients | A loose list of email addresses, plus a picker of specific users |
| Outbox account | Which configured outbox account sends it |
The editor for Subject/Body is a full code editor (Monaco) that knows the fields of the entity you picked and offers them as you type {{ — no need to remember exact field names.
Example: notify on a new high-priority ticket
- Entity:
ticket, applies on create - Condition:
priority=high - Subject:
New high-priority ticket: {{subject}} - Body:
{{customer_name}} reported: {{description}} - Recipients:
[email protected]+ the on-call user - Outbox account: the team's main SMTP account
When a matching ticket record is created, the tokens are substituted with that record's values and a pfm_email_outbox row is created in ready — from there it follows the same delivery path as any other outbound email.