The pain it solves: Manual, repetitive admin tasks eat time and get forgotten when the responsible person is on vacation or just busy.

How it helps:

• A single, unified Automation engine runs quietly in the background, checking regularly for rules that need to run — across every module (Shop, Membership, Booking, and more), without needing a separate background service per feature.
• Multi-tenant aware — each organization's automations run independently and only for the rules they've enabled.
• No duplicate actions — an automation log ensures a rule that already fired won't fire again, so clients never get double reminders or double emails.
• Extensible by design — as new modules are added, they simply plug into the same automation runner rather than requiring new infrastructure.

The happy workday: The system remembers what a person might forget — automatically, safely, and only once.

Why This Matters for Your Organization

Automation reduces the operational burden on staff and reduces the risk of human error (forgotten reminders, missed renewals). Because it is a shared engine rather than one-off scripts, new automation capabilities can be added to any module without duplicating effort.

Technical Details

The engine lives in ExireNexus.Services/Services/Automation/:

• AutomationBackgroundService — a BackgroundService (hosted service) that runs on a fixed interval (TimeSpan.FromHours(1) by default), waits 60 seconds on startup to let the app fully initialize, then iterates over all tenants discovered via the Finbuckle multi-tenant store.
• For each tenant, rules are dispatched to the appropriate IAutomationProcessor implementation based on the rule's Module — for example, ShopAutomationProcessor and BookingAutomationProcessor handle shop and booking-specific logic respectively, while sharing the same rule model (AutomationRule in ExireNexus.Shared/Models/Automation).
• Each processor implements the IAutomationProcessor interface, so adding a new module's automation support means implementing one interface and registering it — no changes to the background runner itself.
• Idempotency is enforced via an AutomationLog, checked before executing an action, preventing duplicate notifications or actions if a rule is evaluated more than once.
• Errors for one tenant are caught and logged (ILogger<AutomationBackgroundService>) without stopping processing for other tenants — a fault in one organization's rules can't affect another's.

This design replaced earlier module-specific background services (e.g., a dedicated membership automation service) with a single, generic runner — reducing duplicated hosting/scheduling code while keeping each module's business logic isolated in its own processor.