EDD Conditional Emails lets store owners send different email templates based on order conditions: cart contents, customer segment, order total, payment gateway, and similar. Rules are stored as plugin config, and each rule that fires logs a delivery record that can be joined back to the originating order in edd_orders. The default admin shows rules as a list and delivery logs as a separate log view, with no easy way to ask "which rule fired for this order" or "how many times did this rule fire last month".

SleekView reads the rule configuration table and the delivery log joined with edd_orders and edd_customers, so an audit view answers both questions in one screen. Filter the log by rule name, date range, or customer to investigate delivery patterns. Sort rules by recent fire count to spot rules that are too aggressive or too quiet. A rule-rooted view shows each rule with its last-fired timestamp, fire count, and on/off status as inline-editable columns.

Inline-toggling a rule's enabled state writes through the plugin's option update path so any rule-cache invalidation happens correctly. Bulk-disabling a set of rules during a promotion that would otherwise double-fire is one filter and one bulk action away.

Conditional emails turn EDD from a transactional sender into something closer to an automation platform, and any automation platform lives or dies by its audit surface. Marketing needs to know which rules are actually firing and how often, so dead rules get retired and runaway rules get tuned. Support needs to answer "which emails did I send this customer" without piecing it together from a half-dozen logs.

Compliance needs per-customer delivery history for GDPR data-access requests, joined with timestamps and template references. The default Conditional Emails admin gives a rule list and a separate delivery log without joining them, and without exposing fire counts as a sortable column. That's fine for a handful of rules but breaks down once a store runs ten or twenty rules across customer segments, cart conditions, and gateway-specific triggers.

SleekView reads the rule config and edd_logs together so each team gets the audit view they actually need. The rule logic still runs through the plugin, so nothing about email delivery changes, just the surface for understanding what fired and why.