Action Triggers Runtime and API

The Action Triggers module now enhances Automations with WordPress / Plugin Action workflows. Previous option-backed trigger rows in brm_action_triggers are migration input only. The live runtime owner is src/Services/AutomationWpActionRuntimeService.php, and the migration owner is src/Services/ActionTriggerWorkflowMigrationService.php.

Module Gate and Entry Points

• Module flag: brm_enable_action_triggers
• Bootstrap path: src/Core/Plugin.php → ActionTriggerWorkflowMigrationService::maybe_start_or_resume_migration() and AutomationWpActionRuntimeService::boot()
• Live admin surface: admin.php?page=brm_automations
• Migration visibility: admin.php?page=brm_automations&tab=migration
• Retry AJAX action: brm_retry_action_trigger_migration

Stored Trigger Shape

Triggers are stored in the brm_action_triggers option and normalized through ActionTriggersService. The normalized row keeps:

• uuid
• hook_name
• action_type = level, post_enrollment, or group_membership
• action = add, remove, enroll, or cancel depending on type
• level_id, post_id, or group_id depending on type
• group_role for group membership triggers
• use_current_user
• priority
• enabled

Runtime Binding

AutomationWpActionRuntimeService registers active workflow-owned hooks on init after Action Trigger cutover completes. Previous option-backed rows do not stay live as a second runtime path.

use BaselMedia\BricksMembers\Core\ModuleRegistry;
use BaselMedia\BricksMembers\Services\ActionTriggerWorkflowMigrationService;
use BaselMedia\BricksMembers\Services\AutomationWpActionRuntimeService;

if ( ModuleRegistry::is_active( 'action_triggers' ) ) {
    ActionTriggerWorkflowMigrationService::get_instance()->maybe_start_or_resume_migration();
    AutomationWpActionRuntimeService::get_instance()->boot();
}

User Resolution

The workflow runtime can either use the current logged-in user or resolve a user from hook arguments through the shared automation context resolver. Curated hook definitions resolve known payload shapes first, then the general fallback heuristics apply.

Supported Mutation Types

• Level actions: add or remove a BRM level for the resolved user
• Post enrollment actions: enroll or cancel enrollment for one configured post
• group membership actions: add or remove the user from a configured group and role

Migration and Admin Surface

Previous trigger rows are migrated into workflow rows in batches. The Automations upgrade tab can run another batch through the retry AJAX action when cutover is still incomplete.

• brm_retry_action_trigger_migration

Live create, edit, pause, delete, and duplicate flows stay on the shared Automations AJAX owner. There is no separate Action Triggers CRUD adapter anymore.

Edit Guidance

• Start in ActionTriggerWorkflowMigrationService when you need to change migration, verification, or cutover behavior.
• Start in AutomationWpActionRuntimeService when you need to change live hook binding.
• Start in ActionTriggersService only when you need to change how the previous option-backed rows are read for migration.