BricksMembers now has a shared Automations hub, and that changes the way the plugin feels in day-to-day use. Instead of spreading event-based logic across different screens, you now have one place where you decide what should happen when access changes, payments fail, a learner completes something, a group invitation is created, or another important event happens on your site.
Just as importantly, that shared hub connects BricksMembers to the tools most membership businesses already use. You can send a BRM email, update Mailchimp, update MailerLite, update Kit, or send a webhook to Zapier, Make, n8n, or your own endpoint from the same workflow.
What the Automations Hub Is For
The Automations hub is built for real membership and course workflows. It is not just a technical rules engine. It is the place where business actions happen after real events on your site.
- Send a welcome email when a member gets access
- Add a subscriber to a Mailchimp audience when a payment succeeds
- Add or remove tags in Kit based on progress, billing, or access changes
- Add someone to a MailerLite group after they join a course or team
- Send a webhook into Zapier, Make, or n8n when something happens in BRM
Why This Is Better Than the Old Setup
Before this change, email automations were tied too closely to the Emails module. That worked for pure email sending, but it did not scale well once you wanted one event to trigger several different things. Now the logic is shared, which means a single workflow can mix email actions, provider actions, and webhook actions without feeling bolted together.
The result is simpler for site owners too. You no longer have to wonder whether an automation belongs in Emails, somewhere inside an integration screen, or in a different tool. It belongs in BricksMembers → Automations.
What You See on the Automations Page
The shared Automations page is organized around the jobs site owners actually need to do, not around internal implementation details.
- Workflows shows the automations you already created, their trigger, status, and action summary.
- Connections is where you connect Mailchimp, MailerLite, Kit, or an outbound webhook destination.
- Builder is where you choose the trigger, timing, and actions for one automation.
- Jobs is where you run the queue, retry failures, and inspect redacted workflow logs.
- Email Upgrade only appears when BRM needs help finishing the migration from older email automations.
The Builder Is Now a Visual Flow
The Builder tab is no longer just a flat settings form. It is now a visual flow where you see your trigger, timing, condition, and action steps as cards in order, with a sidebar that opens when you click the step you want to configure.
That makes it much easier to understand what happens first, what happens later, and which checks must pass before a specific action runs. It also means you can reorder actions by dragging them instead of rebuilding the whole workflow manually.
The builder is also much easier to use than the old “advanced config” style. Longer explanations now live behind small eye-icon tooltips, trigger setup is focused on the event you want plus repeat protection, and normal condition setup uses dropdowns for the workflow value, operator, and comparison value instead of asking you to understand raw JSON.
Smart WordPress and Plugin Triggers
Since 0.9.94, you do not have to start every WordPress-hook workflow by typing a raw hook name. The builder includes smart presets for common WordPress events, WooCommerce order events, FluentCRM tag/list events, Bricks form actions, and BricksMembers events.
Examples include user registered, user role changed, content published or updated, term created, comment submitted, WooCommerce order completed, FluentCRM contact added to a tag or list, Bricks quiz submit, Bricks profile update, BRM access granted, progress completed, quiz passed, submission reviewed, and group member added or removed.
Those presets also expose guided filters. For example, a role-change workflow can filter by previous role and new role, a content workflow can filter by post type or post, WooCommerce workflows can filter by products or offers, and FluentCRM workflows can filter by tags or lists. If a required BRM module or third-party plugin is not active, BRM does not register that smart preset at runtime.
Timing and Conditions Can Happen Between Actions
This matters because timing and conditions are no longer treated like one global setting for the entire workflow. You can now delay a later step or add checks before a later action without pretending the whole automation shares the same timing or the same condition block.
In practice, that means a workflow can send a BRM email right away, wait before the next step, and then only continue if a selected field or context value still matches the condition you set.
Those condition checks are not just “on or off” either. You can choose whether a value should equal something, not equal it, exist at all, not exist, match one of several values, or match array-style values with contains-any, contains-all, and contains-none checks. That makes multi-select data such as roles, tags, groups, and lists easier to handle without leaving the builder.
Normal Setup No Longer Feels Like Raw Config
The current builder also tries much harder to keep normal setup visual. You choose templates, audiences, tags, groups, fields, and context values from selectors instead of pasting IDs or writing raw JSON just to make a common action work.
And if you only want to send a native BRM email, that action does not need an external connection at all. External connections only matter for actions that actually use Mailchimp, MailerLite, Kit, or a webhook destination.
Native BRM email actions can send to one resolved recipient or to a resolved audience. Use audience mode when the workflow should email a selected group of users instead of only the user from the triggering event.
The Setup Experience Is Meant to Be Easy
When you connect Mailchimp, MailerLite, or Kit, the goal is not to make you paste random IDs and internal values into a long form. BricksMembers asks for the credential it needs to connect, verifies that connection, and then loads the data that already exists in your account.
So instead of manually typing audience IDs, group IDs, tag IDs, or field IDs, you connect the provider once and then choose from what BricksMembers fetched for you. That makes setup faster, reduces errors, and feels much closer to the way the built-in payment integrations work.
This is one of the biggest quality-of-life improvements in the shared Automations platform. The connection step is now clearly separated from the workflow step, which means you can verify the provider first and then build automations against real provider data instead of hoping a copied ID was correct.
What You Can Connect Right Now
- Mailchimp for audiences, tags, and merge-field based workflows
- MailerLite for subscribers, groups, and custom-field based workflows
- Kit for subscriber updates, tags, and custom fields
- Outbound Webhooks for Zapier, Make, n8n, or your own automation endpoint
A Typical Workflow in Practice
Imagine a user buys access to a course. The workflow could look like this:
- The access-granted event triggers the workflow
- BricksMembers sends your branded welcome email
- Kit adds an “Active Student” tag
- A webhook is sent to Make or n8n so you can continue the workflow outside WordPress if needed
That all happens from one workflow instead of three separate systems that barely know about each other.
How Emails Fit Into This
The Emails module still matters. It is where you design the actual emails that members receive. The shared Automations hub simply decides when those emails should be sent and what other actions should happen with them.
That means the easiest path is usually:
- Create the email template in BricksMembers → Emails
- Open BricksMembers → Automations and connect the provider you want in the Connections tab
- Create the workflow in BricksMembers → Automations
How Analytics Fits Into This
The newer analytics integrations for AnalyticsWP and Independent Analytics are related to this platform, but they are not managed as workflow actions inside the Automations hub. Instead, BRM uses the same semantic event language for both systems.
That means one important BRM event can now serve two jobs at once: it can trigger a workflow in Automations, and it can also be measured in the new native analytics layer. The benefit for site owners is consistency. You are no longer inventing one set of event names for automations and another for reporting.
What Happens to Older Email Automations
If you already used older BRM email automations, BricksMembers imports them into the shared platform for you. In most cases that stays quiet in the background. If BRM cannot verify the upgrade automatically, the Emails screen shows an Upgrade Issue tab and the Automations page exposes an Email Upgrade section so you can inspect the problem and continue from there.
That also means the Emails screen no longer keeps a permanent automation-management tab. The long-term home for workflow management is the shared Automations hub.
Why This Matters for Real Sites
Membership businesses rarely need “just email” or “just tagging” anymore. They need onboarding, billing recovery, progression logic, team invitations, learning milestones, and external automation tools to work together. The new Automations hub is built around that reality.
So if you have been waiting for a more connected workflow system inside BricksMembers, this is the release where the plugin starts feeling much more complete. Your site events can now drive the rest of your stack in a much cleaner and more practical way.