WordPress automation across multiple sites is solved fastest by building each workflow once, exporting it as a JSON file, and importing it into every subsequent site. With Krom Automation, that export-import cycle takes under two minutes per site.

What changes per site is minimal: the sender email address, any site-specific merge tags, and the API credentials for third-party integrations. The workflow logic, branching conditions, and action sequence stay identical.

If you manage 10 or more client sites, rebuilding automation from scratch each time is the single most expensive configuration habit in an agency. A five-action welcome sequence that takes 45 minutes to build manually takes 3 minutes to deploy via import. Across 20 sites, that is 14 hours recovered from a single workflow type.

This guide covers the full operational picture: what transfers automatically, what needs changing per site, how to version-control your workflow library, and what the real cost looks like across a client portfolio. We have also written a broader piece on the automation stack we deploy on every client build if you want the full picture beyond just workflow reuse.

Browse the full feature list to see every trigger, action and integration available before diving into the deployment mechanics.

The Real Cost of Rebuilding Automation Per Site

Most agencies undercount configuration time because it happens in small increments across a project. A welcome email here, an order notification there.

Each one feels like 20 minutes. The actual number, once you count trigger setup, action configuration, merge tag wiring, condition logic and test runs, is closer to 45 minutes per workflow on a clean install.

At 6 workflows per client site and 20 clients, that is 90 hours of configuration work annually at current scale. Double the client count and you do not double the revenue if the configuration hours scale with it.

The automation that took 45 minutes to build the first time should cost 3 minutes to deploy the second time. Anything more is a process failure, not a complexity problem.

The table below shows what that looks like at three portfolio sizes, comparing manual rebuild against a template-and-import approach.

Portfolio size	Workflows per site	Manual build time	Import time	Annual hours saved
10 sites	6	45 min each	3 min each	42 hours
20 sites	6	45 min each	3 min each	84 hours
50 sites	8	45 min each	3 min each	280 hours

At a conservative $75 per hour for a developer or senior VA, the 50-site scenario represents $21,000 in recoverable labor annually. That number is why the workflow portability question matters to the person signing the budget, not just the person doing the configuration.

How Krom Automation Export and Import Works

Every workflow in Krom Automation can be exported as a portable JSON file from the Workflow Settings panel. The export captures the complete workflow definition: every node on the canvas, the trigger configuration, all action settings, branching conditions, delay rules, and the notes field. Nothing is stored server-side by wpRigel, so the file moves wherever you take it.

Importing on a new site is a single file upload in the same panel. The workflow appears on the canvas immediately in a paused state, which is intentional. Paused means you review and adjust the site-specific fields before it touches a live user or order.

What the import preserves exactly:

• The full canvas layout, node positions, and connection paths
• Every trigger type and its configuration fields
• All action types, field mappings, and conditional logic
• Delay scheduling rules, including unit types (minutes, hours, days)
• Merge tag placements in every action field
• The run-once-per-entity setting, preventing duplicate executions
• Workflow notes, useful for leaving deployment instructions for your team

What the import does not carry across, because it cannot:

• Third-party API credentials (Mailchimp API keys, Slack tokens, webhook URLs)
• The sender name and email address for outbound emails
• Site-specific post IDs or user role names that differ between installs
• Active or paused state, every import arrives paused

That second list is short on purpose. A well-built workflow template uses merge tags and generic role references rather than hard-coded IDs. If you build templates correctly once, the per-site adjustment time stays under 5 minutes for most workflow types.

Building a Reusable Workflow Library

The agencies that benefit most from workflow portability are the ones that treat their workflow files the way they treat their starter theme or their deployment checklist. Versioned, documented, and stored somewhere accessible to the whole team.

A practical library structure looks like this:

• Core workflows that run on every site regardless of client type: user registration welcome email, failed login alert, media upload notification
• WooCommerce workflows for every commerce client: order confirmation, order status change notification, low stock alert
• LMS workflows for education clients: course enrollment confirmation, quiz completion trigger, LearnDash or TutorLMS completion sequences
• Membership workflows for subscription sites: signup confirmation, renewal reminder, expiry handling via MemberPress triggers
• Form response workflows wired to the client’s form plugin: lead follow-up, internal notification, CRM sync

Store each file with a version number in the filename and a changelog in the workflow notes field. When you update a workflow type (because a client request reveals a better approach), bump the version and re-export. Sites still on the old version get upgraded on the next maintenance visit.

A workflow library is worth nothing if the person deploying it does not know which version to use. Filename discipline and notes fields are not optional extras.

Krom Automation’s workflow notes field is the right place to leave deployment instructions: which fields need updating, what credentials are required, and whether the workflow depends on a specific plugin being active. Future you, or the junior on your team, will thank present you.

Per-Site Configuration: What Actually Changes

The fastest way to make imports painful is to build workflows with hard-coded values. The fastest way to make imports fast is to build with merge tags and abstract references everywhere a value might differ between sites.

Here is a concrete breakdown of what typically needs adjusting after an import, ordered by how often it comes up:

What needs changing	How often	Time cost	Prevention
Third-party API credentials	Every site	2 to 5 min	Cannot be avoided; document which are needed
Sender email and name	Every site	30 seconds	Use a placeholder, note it in workflow notes
Webhook URLs	Every site with webhook actions	1 to 2 min	Note the endpoint pattern in the workflow notes
Post or page IDs	Only if hard-coded	1 to 3 min	Use merge tags or post slug references instead
User role names	Only on custom role installs	1 min	Match role names across your client installs
Email body copy	Client-specific branding	5 to 15 min	Keep logic in the workflow, copy in a variable field

The workflows that import cleanest are the ones built with the assumption that they will be deployed elsewhere. That means no hard-coded post IDs, no literal email addresses in action fields, and every piece of site-specific text in a field that is clearly labelled as such. The workflow builder documentation covers how to structure nodes cleanly from the start.

The Form Plugin Variable

One practical complication in multi-site deployment is that clients use different form plugins. A workflow that fires on a Gravity Forms submission does not transfer to a site running WPForms, because the trigger type is different even if the downstream logic is identical.

The fix is to maintain parallel versions of form-triggered workflows, one per form plugin you commonly deploy. Krom Automation supports Gravity Forms, WPForms, Fluent Forms, Contact Form 7, Elementor Forms, and Ninja Forms.

If you standardise on two or three form plugins across your client portfolio, you maintain two or three trigger variants of each workflow. The action chain after the trigger is identical and reusable.

The same applies to email marketing integrations. A lead follow-up workflow that syncs to Mailchimp needs a parallel version for clients using MailerLite or ActiveCampaign. Building this library of trigger-variant files upfront is a one-time cost that pays back across every future deployment.

Multisite vs. Separate Installs: The Workflow Angle

The Multisite versus separate installs debate usually centres on updates, hosting costs and user management. Rarely does it account for automation workflow behaviour, which is worth addressing directly.

On a WordPress Multisite network, each sub-site is a separate WordPress environment. Krom Automation installed network-wide means each sub-site gets its own workflow list, its own execution logs, and its own trigger scope.

Triggers fire per sub-site, not network-wide. That is almost always the right behaviour for client sites, since a user registering on one sub-site should not trigger a workflow on another.

On separate installs, each site is fully independent. There is no cross-site coordination by default, which is fine for most agency client work where clients are different businesses with no relationship to each other.

Where Multisite genuinely helps is when you need shared user accounts across sub-sites, or when you want to push a workflow update to all sub-sites simultaneously through a single plugin update. Where it hurts is when one client’s heavy traffic or misconfigured workflow affects performance for every other sub-site on the network.

Multisite is not a scalability solution. It is a shared-destiny architecture. Every client on that network inherits every other client’s problems.

For most agency portfolios where clients are independent businesses, separate installs with a standardised workflow library is the lower-risk, lower-drama approach. Multisite is worth it when the clients are genuinely related, such as a franchisor and their franchisee network, or a publisher with multiple regional editions of the same site.

Licensing Across a Client Portfolio

Workflow portability only saves time if you can actually activate the plugin across your full portfolio. Licensing is the constraint most agencies hit second, right after building their first solid workflow library.

Krom Automation Pro pricing by site count:

Plan	Sites	Annual	Lifetime	Annual cost per site (annual plan, 20 sites)
Basic	1	$119/year	$299	Not applicable
Standard	5	$199/year	$499	$39.80
Enterprise	Unlimited	$369/year	$799	$18.45 at 20 sites, $7.38 at 50

For any agency managing more than 5 client sites, the Enterprise plan is the only one that makes financial sense. At 20 sites on the annual plan, the per-site cost is $18.45 per year.

At 50 sites, it drops to $7.38. The lifetime option at $799 eliminates the renewal calculation entirely, which is worth considering if you expect the portfolio to grow.

The free version is available with no run caps, no trial period, and no features behind a paywall. For clients with simpler automation needs, the free tier covers 16 triggers and 21 actions, which is enough for most standard notification and user management workflows. Download the free plugin from the WordPress.org plugin directory and test the import workflow on your own site before rolling it out to clients.

We have also written a detailed breakdown of what client automation costs per site and what it should, which covers how to structure your own pricing when passing automation costs to clients.

Execution Monitoring at Scale

Deploying workflows across 20 sites creates a new problem: knowing when something breaks without logging into each site to check. A workflow failing silently on a client site is a support ticket waiting to happen, usually arriving from the client rather than from your monitoring.

Krom Automation handles failure notification by email with automatic retry and configurable backoff. That means the first failure triggers a retry, and if the retry fails, an email goes to the address configured in the plugin settings. Set that to your agency’s monitoring inbox, not the client’s email address, and you get first notice before the client does.

The execution log gives you a full per-step audit trail for every workflow run. When a client reports that their order confirmation email did not arrive, you can check exactly which step failed, what the trigger data contained, and whether the retry succeeded.

That is the difference between a 10-minute support call and a 2-hour investigation. We wrote a detailed piece on what happens when automation fails silently on WordPress and how to catch it before clients do.

The analytics dashboard shows total executions, active workflow count, estimated time saved, and failed execution count. Per-workflow success rate is visible without clicking into individual logs, which is the right level of detail for a weekly portfolio review. The reports page adds date range filtering and CSV export, useful if you want to include automation performance in a monthly client report.

Also from wpRigel

Pollify is our Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the editor, with no shortcodes to configure and no separate admin interface to learn. If any of your clients publish editorial content or run community sites, it is worth adding to your standard deployment stack.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K from anywhere in the dashboard to search, navigate, and run admin actions without clicking through menus.

For agencies managing dozens of client sites, it is the fastest way to get around an unfamiliar admin without hunting through sidebar menus. It is the only command palette plugin with real WooCommerce order, product and customer commands built in.

Our Verdict

If you manage more than 5 client sites and are still building automation workflows from scratch on each one, you are spending 60 to 100 hours a year on configuration that should take a fraction of that. The workflow library approach, built once, exported, imported and adjusted in under 5 minutes per site, is the only version of multi-site automation that scales without hiring someone just to handle setup.

The agencies this approach does not suit are the ones where every client site is genuinely unique in its plugin stack, its trigger requirements, and its downstream integrations. If you build fully custom stacks with no standardisation, the library benefit is real but smaller, because you are maintaining more workflow variants. The answer there is not to abandon the approach but to standardise your stack first, then build the library.

The Enterprise plan at $369 per year for unlimited sites is the right entry point for any portfolio beyond 5 sites. The lifetime option at $799 removes the renewal decision permanently. Either way, the per-site cost at any meaningful scale is low enough that it should not be a line item in the client conversation at all.

Compare all three Krom Automation plans and see the full feature breakdown before making a decision.

Frequently Asked Questions

Does the Krom Automation free version support workflow export and import?

Yes. Export and import are available in the free version with no restrictions. The exported JSON file contains the complete workflow definition and can be imported to any site running Krom Automation, free or Pro.

Do I need a separate licence for each client site?

Pro features require an active licence per site. The Enterprise plan covers unlimited sites for $369 per year or $799 lifetime, making it the practical choice for any agency portfolio larger than 5 sites. The free version has no licence or site limits.

What happens to delays and scheduled actions after a workflow is imported?

Delay and scheduling configurations import correctly. However, scheduled triggers that use specific dates or times need to be reviewed on the new site, since a one-time scheduled date from the original site may already have passed. Recurring schedules (daily, weekly, monthly) import and activate without adjustment.

Can I automate across two separate WordPress sites, for example pushing a post from one to another?

Direct site-to-site automation requires an intermediate layer. The HTTP Request action can call the REST API of another WordPress site, and the incoming webhook receiver on the Pro plan can receive that call and trigger a workflow on the destination site. It is not point-and-click, but it is fully supported without any third-party service in the middle.

What is the difference between WordPress Multisite and managing separate installs for automation purposes?

On Multisite, each sub-site has its own workflow scope. Triggers fire per sub-site and do not cross sub-site boundaries by default.

Separate installs behave identically from an automation standpoint, with each site fully independent. Multisite only adds value for automation when you need shared user accounts or network-wide plugin configuration changes applied to all sub-sites simultaneously.

How do I handle clients who use different form plugins?

Maintain one workflow file per form plugin variant for each workflow type that uses a form trigger. The trigger node differs between Gravity Forms, WPForms, Fluent Forms and the others, but the action chain after the trigger is identical across variants. Build the action chain once, duplicate the workflow, and swap the trigger node for each form plugin version you support.

Is there a way to test a workflow after import before it goes live?

Yes. Krom Automation includes a workflow simulator that runs a dry-run with zero side effects.

No emails are sent, no records are created, and no external APIs are called. You can verify the complete execution path, including branching logic and merge tag resolution, before activating the workflow on a live client site.

A WordPress automation that fails silently is more dangerous than one that crashes with an error. A loud failure produces a log entry, a notification, something you can respond to. A silent failure produces nothing.

The workflow appears active, no alert fires, and the work it was supposed to do just doesn’t happen. This is the failure mode that leaves a WooCommerce order unconfirmed, a new member without a welcome email, or a course enrollment that never completes, sometimes for weeks.

Most articles about WordPress automation failures focus on the visible kind: the “automated update has failed to complete” message, the .maintenance file, the PHP memory limit error. Those are easy to write about because the site tells you something went wrong. The harder problem is the failure that gives you no signal at all. That’s what this article is about, and it’s an observability problem, not a configuration one.

We’ll cover why silent failures happen, how to detect them, how to build alerting that actually fires, and why partial failures are more operationally damaging than total ones. The framing throughout is for developers and agency owners managing automations across multiple sites, not single-site hobbyists.

See how Krom Automation handles execution logging and failure alerting

Why Silent Failure Is Worse Than a Crash

When a workflow crashes with an exception, the execution state is wrong but your awareness is correct. You know something failed. You can check the logs, find the step, and fix it.

When a workflow fails silently, both the execution state and your awareness are wrong simultaneously. You believe the automation is running. It isn’t.

The operational cost difference is significant. A loud failure detected within an hour costs you the time to diagnose and fix it.

A silent failure running undetected for 30 days costs you everything that workflow was supposed to do during that window: every welcome email that didn’t send, every Slack notification that didn’t fire, every contact that didn’t get added to your FluentCRM list. You don’t get those back.

A crash is a problem. A silent failure is a debt you don’t know you’re accumulating.

There’s also a compounding factor: silent failures erode trust in automation itself. When a team discovers that a workflow they relied on hasn’t been running for a month, the instinct is to go back to doing things manually. That’s the worst possible outcome, because manual processes don’t scale and they fail too, just more visibly.

The Most Common Causes of Silent Failure in WordPress

Understanding why automations fail silently is the first step toward detecting them. The causes generally fall into four categories.

WP-Cron Reliability on Shared Hosting

WordPress uses WP-Cron to schedule background tasks. WP-Cron is not a real cron job. It fires when a visitor loads a page, which means on low-traffic sites or during quiet periods, it can be hours late or miss entirely.

A workflow scheduled to run at 09:00 on shared hosting might run at 11:30, or not until the next day. No error is thrown. The job just sits in the queue.

This is the most common cause of silent delay failures. The automation isn’t broken, but its timing is completely unreliable, and nothing tells you that.

The fix is to disable WP-Cron in wp-config.php and configure a real server cron to hit /wp-cron.php every 60 seconds. Until that’s done, any workflow using delay scheduling is operating on a best-effort basis.

PHP Execution Limits

Shared hosting providers typically set PHP execution time between 30 and 60 seconds. A workflow running an HTTP request to a slow external API, followed by a database write and an email send, can exceed that limit mid-execution. The process dies, the remaining steps don’t run, and depending on how the workflow engine handles the interrupt, no failure record is written. From the outside, the workflow appears to have run.

Third-Party API Failures

Any workflow that touches an external service, whether that’s a Mailchimp subscriber add, a Google Sheets row write, or a Slack message, depends on that service being available and responsive. When an API returns a 500 error or a timeout, the outcome depends entirely on how the automation layer handles it. If it doesn’t retry and doesn’t log the failure, you get silence.

Conditional Branches That Route Incorrectly

A workflow with conditional branching can route every execution down the wrong path if a condition is misconfigured. Every trigger fires, every execution completes, the logs show green, and the actual outcome is wrong. This is the most insidious type of silent failure because the automation technically ran.

It just ran incorrectly. You’ll only catch it by checking outputs, not by checking whether executions completed.

Partial Failures Are More Damaging Than Total Failures

A workflow that always fails is easy to detect: the output is consistently missing. A workflow that fails 20% of the time is far harder, because 80% of executions produce the correct result.

That success rate looks acceptable in aggregate. The 20% failure rate doesn’t show up unless you’re looking at per-execution outcomes, not totals.

An 80% success rate on a critical workflow means 1 in 5 customers gets the wrong experience. That’s not a minor bug. That’s a systemic problem dressed as normal operation.

Partial failures also have a specific cause pattern. They tend to be triggered by data edge cases: a user with an unusual character in their name, an order with a product in a category the workflow wasn’t configured to handle, a form submission with an empty required field that the workflow expects to be populated. The fix isn’t the workflow itself, it’s the missing input validation before the workflow runs.

This is why per-execution logging matters more than aggregate dashboards. If you can only see “200 executions this week”, you can’t detect a 20% failure rate. If you can see each execution with its per-step result, you can spot the pattern immediately.

What Good Execution Logging Actually Looks Like

Most WordPress automation plugins offer some form of execution history. The question is what that history actually tells you. There’s a meaningful difference between these two logging levels:

Logging level	What you can detect	What you miss
Workflow-level only (pass/fail)	Total failures, complete workflow crashes	Partial step failures, branch routing errors, API errors that didn’t throw
Per-step audit trail	Which exact step failed, what data it received, what error it returned	Nothing that happened, every step is visible

Workflow-level logging is better than nothing. Per-step logging is what you need to diagnose a partial failure or a branch routing problem.

Krom Automation logs every step of every execution, so you can see the exact data each node received and what it returned. That’s the level of detail that makes silent failures visible.

The analytics dashboard shows total executions, active workflows, success rate, and failed execution count alongside an execution trend chart. The reports page adds date range filtering, per-workflow breakdown, and CSV export. Those two views together let you spot a declining success rate before the failure becomes a customer-facing problem. You can read more about how workflows are built and what data they capture in the Krom Automation overview documentation.

Setting Up Failure Alerting That Actually Fires

Detection through manual log review is not a monitoring strategy. For automation failures to be caught quickly, alerting needs to be automatic and immediate. Here’s the alerting hierarchy we recommend, ordered by how much difference each makes.

1. Email failure notifications on first failure, the minimum viable setup. Configure your automation layer to send an email when any workflow execution fails. The email should name the workflow, the trigger event, the step that failed, and the error message. A generic “something failed” email wastes diagnostic time.
2. Automatic retry with configurable backoff, a transient API error should not create a permanent failure. A retry schedule that attempts again at 5 minutes, 30 minutes, and 2 hours catches the majority of third-party service blips without intervention. Without retry, every API hiccup becomes a failed execution in your logs.
3. Success rate thresholds, not just failure counts, alerting only on failure count misses the partial failure pattern. If you had 100 executions last week and 20 this week, that’s not a failure alert, it’s a volume drop. Alert on success rate falling below a threshold, not just on failures appearing.
4. Messaging channel alerts for critical workflows, for workflows that touch revenue-critical processes, email alone is too slow. A Slack or Discord notification via the messaging integrations means the right person sees the failure within minutes, not the next time they check their inbox.

Krom Automation handles points one and two natively: failure notifications go out by email and the retry mechanism uses configurable backoff. For point four, you can build a secondary workflow that triggers on a failed execution and posts to Slack. That’s the kind of meta-automation most teams don’t think to build until after a significant failure has already happened.

The Observability Stack for WordPress Automation

Treating automation as an observability problem means asking: at any moment, do I know the current state of every workflow, and would I know within 15 minutes if that state changed? Most WordPress sites would answer no to both. Here’s what a complete observability stack looks like.

Layer	What to monitor	How to catch failure within 15 minutes
Execution health	Success rate per workflow over rolling 7 days	Alert when success rate drops below 90%
Queue health	Pending jobs older than 2x their expected interval	Alert if a scheduled workflow hasn’t fired within its window plus 10 minutes
API dependency health	Third-party service response times and error rates	HTTP request action logs will show consistent timeouts before a full outage
Data correctness	Output records in destination systems	Spot-check: query the destination (FluentCRM contact count, Google Sheets row count) and compare to expected trigger volume

The data correctness layer is the one nobody implements and the one that catches branch routing errors. If your WooCommerce Order Completed trigger should be firing roughly as often as new completed orders appear in WooCommerce, and it isn’t, something is wrong even if every execution shows as successful. Reconciling trigger volume against destination records is the only way to catch a correctly-executing but incorrectly-routing workflow.

Using the Workflow Simulator Before Production

The best time to catch a silent failure is before the workflow goes live. A dry-run simulator lets you fire a workflow against real or synthetic data without executing the actual actions, so you can verify that branch conditions route correctly, merge tags resolve to the expected values, and every step receives the data it needs.

Krom Automation’s workflow simulator runs a complete dry run with zero side effects. You see the exact data each node would receive and the path each branch would take, without sending a single email or writing a single database record. Running the simulator against edge-case inputs, not just the happy path, catches the conditional routing errors that cause partial failures in production.

The test cases worth running for any workflow are:

• The expected happy-path input that should produce the desired output
• An input where the primary condition evaluates false, to verify the No branch is configured correctly
• An input with missing or empty fields that the workflow uses in merge tags
• An input that represents a boundary case, such as a user with no assigned role, or an order with zero line items

Four test cases takes about 10 minutes. Discovering a branch routing error in production after 500 executions have silently gone to the wrong path takes considerably longer to diagnose and remediate.

What to Check When You Suspect a Silent Failure

If you suspect a workflow has been failing silently, work through these checks in order. Skipping ahead wastes time if an earlier issue is the actual cause.

1. Check execution volume against trigger volume. How many times did the trigger fire in the period you’re investigating? How many executions completed? A gap between those two numbers means some triggers didn’t produce executions at all, which points to a queue or WP-Cron problem.
2. Check per-step logs for the failing executions. If executions ran but outcomes are wrong, the per-step log will show which step received bad data or returned an error. Most silent failures are visible at this level.
3. Check the destination system, not just the workflow. If the workflow log shows success but the FluentCRM contact doesn’t exist, the issue is at the API layer. The HTTP request may have returned a 200 that contained an error body, which the workflow treated as a success.
4. Check WP-Cron queue depth. If scheduled workflows are queuing but not firing, WP-Cron is the problem. Check the queue using a plugin like WP Crontrol and verify events are processing, not accumulating.
5. Check PHP error logs for the relevant time window. A timeout or fatal error that killed a workflow process may not surface in the workflow logs at all, but it will appear in the server’s PHP error log.

Hidden Costs Nobody Mentions

Silent automation failures have costs that don’t appear in a post-mortem until someone does the arithmetic. For an agency managing 20 client sites, each running 5 to 10 automations, a 5% silent failure rate across all workflows means dozens of missed events per week. At an average manual task time of 8 minutes per event, that’s several hours of rework per week that nobody has budgeted for, because nobody knew it was needed.

There’s also a compounding liability for WooCommerce sites. An order fulfillment workflow that silently fails on 3% of orders means 3% of customers don’t receive their confirmation, their shipping notification, or their digital download. Those customers open support tickets.

Support tickets cost money to resolve, and they arrive without any context that automation was involved, so the connection to a workflow failure is rarely made. You can read more about the real cost structure of WordPress automation in our breakdown of what client automation costs per site.

For sites handling sensitive workflows, such as membership access provisioning or course enrollment, a silent failure has a direct revenue impact. A student whose LearnDash enrollment didn’t complete after payment will request a refund if they can’t access their course.

The workflow ran, the execution shows as complete, and the enrollment still didn’t happen. Without per-step logging, you have no way to explain what went wrong.

The workflows you never check are the ones with the highest silent failure rate. Confidence in automation you haven’t verified is not confidence, it’s exposure.

Also from wpRigel

Pollify is wpRigel’s Gutenberg native poll, survey and quiz plugin. Polls are built as real blocks inside the editor, with no shortcodes to paste and no separate configuration interface. It’s worth knowing about if you’re already using Gutenberg as your primary editor and want audience engagement tools that work the same way.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere, search everything, and run admin actions without clicking through menus. For agencies managing multiple sites, it’s the fastest way to navigate a WordPress admin, and it’s the only command palette plugin with genuine WooCommerce order, product and customer management built in.

Our Verdict

Silent automation failure is an observability problem, and it doesn’t have an observability solution on most WordPress sites because most WordPress automation tooling wasn’t built with observability in mind. The result is a large class of failures that are actively invisible: no alert, no log entry, no customer complaint until the damage has been running for weeks.

Who needs to act on this immediately: any agency or developer running business-critical workflows on client sites, particularly anything touching WooCommerce orders, membership access, or email sequences. If you don’t have per-step execution logs and automatic failure alerting today, you are operating blind.

Who can take a more measured approach: single-site owners running simple, low-stakes automations where a missed execution is inconvenient but not damaging. Set up email failure notifications as a minimum, and check execution volume monthly.

What we would do: deploy Krom Automation for the per-step audit trail and built-in failure alerting, configure a real server cron instead of relying on WP-Cron, and build one meta-workflow that posts critical failures to Slack. That stack catches the vast majority of silent failures within 15 minutes of occurrence. The free version is available at the WordPress.org plugin directory with no trial period and no execution caps.

For teams ready to move beyond reactive debugging, the full feature comparison and Pro plan details are on the Krom Automation pricing page.

Frequently Asked Questions

How do I know if a WordPress workflow is failing silently if nothing appears in the logs?

Start by comparing trigger volume to execution count. If fewer executions completed than triggers fired, some events never reached the workflow queue, which points to a WP-Cron or queue processing problem. Then check the destination system directly: if expected records aren’t appearing in your CRM, email list, or database, the workflow may be executing but routing incorrectly.

Can a WordPress automation show as “completed” even when it failed?

Yes, in two scenarios. First, if a third-party API returns a 200 status with an error body, the automation layer may record a success even though the action didn’t complete.

Second, if a conditional branch routes an execution to a path that does nothing, the workflow completes with no output and no error. Per-step logging and destination-side reconciliation are the only reliable ways to catch both of these.

Does replacing WP-Cron with a real server cron actually fix silent failure?

It fixes the timing and reliability problem, not all silent failures. A real server cron ensures scheduled workflows fire on time and that background execution queues don’t stall.

It doesn’t fix API errors, misconfigured conditions, or PHP execution timeouts. It’s a necessary foundation, but not a complete solution.

What’s the minimum alerting setup for a production WordPress automation?

At minimum: email notification on first failure, and automatic retry on transient errors. That combination catches the majority of third-party API blips without manual intervention. For revenue-critical workflows, add a Slack or Discord alert via a secondary notification workflow so failures appear in real time rather than waiting for someone to check their email.

How often should I review automation execution reports?

Weekly for any automation touching revenue, access provisioning, or customer communication. Monthly is acceptable for low-stakes automations where a missed execution is recoverable.

Don’t wait for a customer complaint to initiate a review. By the time a customer reports a missing email or access problem, the failure has typically been running for days.

WooCommerce low stock notification emails work out of the box, no plugin required, but the settings are not where most people look. The alert is enabled at WooCommerce > Settings > Products > Inventory, not under Settings > Emails, and the recipient defaults to your store admin address. This guide covers the complete setup, how to send alerts to multiple recipients including suppliers, how to set per-product thresholds, and what to do when the emails stop arriving.

The native system covers the basics and costs nothing. Where it falls short is routing, per-product control, and anything that happens after the alert lands in an inbox. For stores that need more than one recipient or want to trigger a restocking workflow automatically, we will cover both the native path and the automation layer that closes the gap.

If you want to go further than a single email to a single address, Krom Automation handles the downstream workflow without requiring a third-party SaaS subscription.

Where WooCommerce Low Stock Email Settings Actually Live

This is the question that generates the most support threads. Developers and store managers search under WooCommerce > Settings > Emails, find nothing related to stock, and assume the feature does not exist. It does exist, but it is controlled from a different screen.

The correct path is WooCommerce > Settings > Products > Inventory. The relevant fields on that screen are:

• Manage stock: must be checked. Without this, no stock tracking occurs and no alerts fire.
• Low stock threshold: the inventory level that triggers the email. Default is 2, meaning the alert fires when stock drops to 2 units.
• Out of stock threshold: separate from the low stock alert. Set this to 0 unless you want products marked out of stock before they actually reach zero.
• Notifications: two checkboxes. “Enable low stock notifications” and “Enable out of stock notifications”. Both default to enabled but can be toggled independently.
• Notification recipient(s): a single email field. This is where the alert goes. It defaults to your WordPress admin email.

The actual email template is controlled at WooCommerce > Settings > Emails > Low Stock. That is where you set the subject line, email type (plain text or HTML), and whether the notification is enabled at all.

If the checkbox under the Emails tab is unchecked, no alert fires regardless of what the Inventory tab says. Both settings must be active.

What the Native WooCommerce Low Stock Email Contains

Understanding what the alert actually sends helps you decide whether the default is enough or whether you need a custom template or an additional workflow.

Field in the email	Where the data comes from
Product name	Product title in WooCommerce
Product SKU	Inventory tab on the product edit screen
Current stock quantity	Stock quantity field on the product
Low stock threshold that triggered the alert	Global threshold from Settings > Products > Inventory, or per-product override
Product edit link	Direct link to the WooCommerce product editor
Recipient address	Notification recipient field in Settings > Products > Inventory

The alert does not include supplier contact details, reorder quantities, lead times, or any store branding beyond your site name. If your restocking process needs any of that information in the email itself, you are looking at a custom template or an additional automation layer.

Setting Per-Product Low Stock Thresholds

The global threshold at Settings > Products > Inventory applies to every product that has stock management enabled. A threshold of 2 makes sense for a high-volume consumable but is dangerously low for a product with a 6-week supplier lead time.

To override the threshold for a specific product, go to the product edit screen and navigate to Product data > Inventory. Check Enable stock management at product level, then set the Low stock threshold field to your product-specific number.

This overrides the global setting for that product only. Products without a per-product override continue using the global threshold.

For product variations, the same logic applies at the variation level. Expand the variation, enable stock management for that variation, and set the threshold there. Each variation can carry its own threshold independently of the parent product and of every other variation.

A global threshold of 2 works for toilet paper. For a product with a 6-week lead time, it is a guarantee you will stock out before the reorder arrives.

Sending Low Stock Alerts to Multiple Recipients

The notification recipient field in WooCommerce accepts a single email address. If you need alerts to reach a warehouse manager, a supplier, and a store owner simultaneously, the native field cannot do it without a workaround.

The two practical options are:

• Email alias or distribution list: set the recipient field to a shared inbox or group address that forwards to multiple people. This requires no plugin and works immediately. The limitation is that everyone on the list gets every alert, with no filtering by product category or supplier.
• Automation workflow: use a tool like Krom Automation to intercept the low stock event and send separate, targeted emails to different recipients based on conditions. This approach lets you route alerts about specific product categories to the relevant supplier while sending a summary to the store owner.

For the automation approach, the workflow builder walks through the exact steps for creating a conditional branching flow. You can use the WooCommerce Order triggers alongside post meta conditions to segment by product tag, category, or any other attribute.

Step-by-Step: Enable and Configure the Native Low Stock Email

Work through these in order. Skipping to the email template before confirming stock management is enabled will waste time because the template setting has no effect if the inventory tab is not configured first.

1. Go to WooCommerce > Settings > Products > Inventory.
2. Check Enable stock management if it is not already checked.
3. Set Low stock threshold to the number that makes sense for your slowest-moving product. You can override this per product later, so start conservative.
4. Confirm Enable low stock notifications is checked.
5. Enter the recipient address in the Notification recipient(s) field. For a distribution list, enter the group address here.
6. Click Save changes.
7. Go to WooCommerce > Settings > Emails.
8. Find Low Stock in the email list and click Manage.
9. Confirm Enable this email notification is checked.
10. Edit the Subject and Heading fields if the defaults do not match your team’s workflow. The default subject is “Low stock: {product_title}” and the default heading is “Product stock is running low”.
11. Set Email type to HTML, Plain text, or Multipart depending on your mail client preferences.
12. Click Save changes.

To verify the configuration is working without waiting for stock to drop naturally, reduce a test product’s stock quantity to just above your threshold, then manually reduce it by 1. The alert should fire within a few minutes, depending on how your server processes WooCommerce hooks.

What the Native Setup Does NOT Handle

This is the section the marketing pages leave out. Knowing the gaps before you rely on the native system prevents the kind of failure that only becomes visible when a product stocks out unexpectedly.

• One recipient only: the Notification recipient(s) field sends to one address. Multiple addresses entered with commas do not work reliably across all WooCommerce versions and hosting configurations.
• No supplier routing: there is no way to send the alert to a different address based on the product’s supplier, brand, or category. Every alert goes to the same inbox.
• No reorder information: the email tells you stock is low. It does not tell you what to order, how much, or from whom. That context has to come from your own documentation or a separate system.
• No back-in-stock customer notification: the native system notifies the admin when stock drops. It does not notify customers when stock is restored. That requires a separate plugin or a custom workflow.
• No escalation: if the alert is ignored and stock reaches zero, there is no second alert or escalation to a different contact. The out-of-stock email fires once to the same address.
• No CSV export or audit log: there is no record of when alerts fired, which products triggered them, or whether the alert was acted on.
• Variable products alert at the variation level, not the parent: if you have stock management on variations, the alert fires with the variation name and ID. The parent product does not aggregate and alert. This surprises store owners who only check the parent product in the admin.

The native low stock email tells you a problem exists. It does nothing to help you solve it, route it to the right person, or track whether anyone acted on it.

Building the Downstream Workflow: What Happens After the Alert

No competitor guide covers this part. Receiving a low stock alert is step one. The actual work is what happens in the next 30 minutes: finding the supplier contact, placing the reorder, updating the product status, and notifying customers who may be waiting.

With Krom Automation, you can build that response once and run it automatically every time a low stock event fires. A complete restocking workflow might look like this:

• Trigger: WooCommerce Order Completed fires when an order drops stock to the threshold level.
• Condition branch: check product category or tag to identify the supplier.
• Action 1: Send Email to the store admin with product name, SKU, current quantity, and a direct link to the product editor.
• Action 2: HTTP Request to your supplier’s ordering API or a Google Sheet that logs the reorder request. The Google Sheets integration handles this without code.
• Action 3: Update Post Field to add an internal note to the product, timestamping when the reorder was triggered.
• Delay: wait 48 hours.
• Action 4: Send a follow-up email if the stock has not been updated, escalating to a second contact.

The conditions and branching documentation shows how to set up the Yes/No paths that route alerts to different suppliers based on product attributes. The delays and scheduling documentation covers how to configure the 48-hour follow-up without any cron job setup.

For stores that also send order alerts to Slack or SMS, the WooCommerce order alerts guide covers the messaging integrations that work alongside this restocking workflow.

Back-in-Stock Customer Notifications

The native WooCommerce low stock system notifies the admin. It does not notify customers who want to know when a product is available again. These are two different problems solved by two different mechanisms.

For back-in-stock customer notifications, the standard options are:

• A dedicated back-in-stock plugin that adds a waitlist form to out-of-stock product pages and emails subscribers when stock is restored.
• A custom automation workflow that monitors stock quantity changes and sends email to a stored list of interested customers when the quantity rises above zero.

The automation approach gives you more control over the email content, timing, and segmentation, and it does not require customers to sign up through a separate form if you already have their contact details from a previous order. If you need to send that restocking email through a styled template rather than a plain text alert, the visual email builder in Krom Automation Pro handles block-based email design without touching code.

Troubleshooting: Why Low Stock Emails Are Not Arriving

These are the three failure modes that account for the majority of support threads on this topic.

Failure Mode 1: Stock Management Is Not Enabled at the Product Level

The global setting at WooCommerce > Settings > Products > Inventory enables stock tracking site-wide, but each product also needs stock management enabled individually. Go to the product edit screen, open Product data > Inventory, and confirm Enable stock management at product level is checked and a stock quantity is entered. If stock management is off at the product level, WooCommerce never tracks the quantity and never fires the alert regardless of the global setting.

Failure Mode 2: The Low Stock Threshold Is Set Too High or Too Low

If your global threshold is 2 and a flash sale drops stock from 50 to 3 in one transaction, the alert fires. If the same sale drops stock from 50 to 1 in a single transaction that bypasses the threshold entirely, the alert does not fire because the quantity crossed through the threshold without stopping there.

Set your threshold to a number where normal order volume reaches it gradually rather than jumps past it. A threshold of 5 on a product that sells in packs of 6 will frequently be skipped.

Failure Mode 3: The Emails Are Arriving but Going to Spam

WooCommerce sends transactional email through WordPress’s wp_mail function, which defaults to using PHP mail without authentication. Many mail servers treat unauthenticated PHP mail as spam, especially from shared hosting. The fix is to route all WordPress email through an authenticated SMTP service.

A dedicated SMTP plugin pointed at SendGrid, Mailgun, or Amazon SES resolves this for most sites. Our full breakdown of why automated WordPress emails go to spam covers the diagnosis steps and the SMTP configuration in detail.

Cost Comparison: Native Setup vs. Automation Layer

Capability	Native WooCommerce	Krom Automation Free	Krom Automation Pro
Low stock email to admin	Yes	Yes, via Send Email action	Yes
Multiple recipients	No (one address only)	Yes, separate workflow branches	Yes
Per-product threshold	Yes	Yes	Yes
Supplier routing by category	No	Yes, with conditional branching	Yes
Downstream reorder workflow	No	Yes, via HTTP Request action	Yes, plus 60+ additional actions
Execution log and audit trail	No	Yes, per-step logging included	Yes
Styled email template	Basic HTML	Plain text or basic HTML	Yes, visual block-based builder
Back-in-stock customer alert	No	Yes, via stock change workflow	Yes
Annual cost (1 site)	$0	$0	$119/year

The native WooCommerce low stock email is not broken. It just stops at the inbox. Everything that needs to happen after that is your problem to solve manually, every single time.

Also from wpRigel

Pollify is a Gutenberg-native poll, survey and quiz plugin. Every poll is built as a real block inside the editor, so there are no shortcodes to paste and no separate interface to configure. It is useful for stores that want to collect customer feedback directly on product or post pages.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere in the admin, search orders by number or customer name, and run product updates without navigating through menus. It is the only WordPress command palette with real WooCommerce order, product, and customer commands built in, which makes it genuinely useful for anyone managing a store day to day.

Our Verdict

If you manage a single WooCommerce store with one admin and a simple product catalogue, the native low stock email is sufficient. Enable it at WooCommerce > Settings > Products > Inventory, confirm it is active under Settings > Emails > Low Stock, and set a threshold that gives you enough lead time to reorder before you stock out. That setup takes under 10 minutes and costs nothing.

If you manage multiple product lines with different suppliers, need alerts routed to specific people, or want a record of when alerts fired and whether anyone acted on them, the native system will fail you at some point. Download Krom Automation free from the WordPress.org plugin directory and build the workflow once. The free version includes conditional branching, HTTP Request actions, and full execution logging, which covers the supplier routing and audit trail gaps without a paid tier.

Pro, starting at $119 per year for a single site, adds the visual email builder and the additional integrations if your restocking workflow connects to an external system. See the full plan breakdown to decide whether free covers your needs or whether Pro is worth it.

Frequently Asked Questions

Why does my WooCommerce low stock email setting not appear under Settings > Emails?

The threshold and recipient settings live under WooCommerce > Settings > Products > Inventory, not the Emails tab. The Emails tab only controls the template, subject line, and whether the notification type is enabled. Both locations must be configured correctly or the alert will not fire.

Can I send WooCommerce low stock alerts to my supplier instead of the admin?

The native recipient field sends to one address. To route alerts to a supplier, either use a shared distribution list as the recipient, or build a conditional workflow in Krom Automation that checks the product category and sends to the corresponding supplier address. The conditions and branching documentation shows how to configure the routing logic.

What happens to low stock alerts for product variations?

If stock management is enabled at the variation level, each variation triggers its own alert independently when it hits the threshold. The alert includes the variation name and ID. The parent product does not aggregate stock across variations for alerting purposes, so a parent with 3 variations can generate 3 separate low stock emails as each variation individually hits its threshold.

Why do my low stock emails arrive but land in spam?

WooCommerce uses WordPress’s wp_mail function, which defaults to PHP mail with no authentication. Most modern mail servers treat unauthenticated PHP mail as suspicious, particularly on shared hosting.

Install an SMTP plugin and connect it to an authenticated sending service like SendGrid, Mailgun, or Amazon SES. Our guide on why automated WordPress emails go to spam covers the full diagnosis and fix.

Does Krom Automation replace the native WooCommerce low stock email?

No, it extends it. The native alert still fires to the admin address as configured. Krom Automation adds a parallel workflow layer: supplier routing, downstream reorder actions, execution logging, and back-in-stock customer notifications.

You can run both simultaneously. The WooCommerce integrations documentation covers which triggers and actions are available in the free version.

Is there a way to notify customers automatically when a low-stock product is restocked?

Not through the native WooCommerce system. You need either a dedicated back-in-stock plugin or a custom automation workflow that monitors stock quantity changes. In Krom Automation, you can build a workflow that detects when a product’s stock quantity updates above zero and sends a targeted email to customers who previously expressed interest, using the Send Email action combined with stored user meta.

You can auto subscribe students to the next course in LearnDash or TutorLMS using Krom Automation, and the free version is enough for a single trigger-to-enrolment workflow. No code is required, and the workflow fires in the background without touching page load times. LearnDash Pro is required for LearnDash; the free Krom Automation plugin handles TutorLMS course completion out of the box.

Most LMS sites handle progression manually. An admin gets notified, logs in, finds the student, and clicks enrol.

At low volume that is annoying. At 50 completions a week it is a part-time job, and it introduces a delay that kills momentum for the student who just finished and is ready to keep going.

This guide covers both LearnDash and TutorLMS, conditional enrolment rules, what the workflow cannot do, and the three failure modes that catch most people out.

Browse the full feature list to see everything Krom Automation can trigger on a course completion event before you build.

What Gets Synced: Course Completion to Enrolment

The table below shows exactly what fires during the trigger event and where it lands in the enrolment action. Nothing listed here requires custom code or a third-party integration service.

Field on the trigger side	Where it lands in the enrolment action
Completed course ID	Used to match the “source” course in your workflow condition
Completing user ID	Passed to the enrolment action as the target user
User email address	Available as a merge tag for a confirmation email action
User display name	Available as a merge tag for personalised email or post creation
Completion timestamp	Logged in the execution record; can feed a delay node if you want a 24-hour gap before enrolment
Quiz score (LearnDash only)	Available as a merge tag; can drive a conditional branch to enrol or skip based on pass mark
User role	Available for conditional branching, so managers get a different next course than individual contributors

The merge tags documentation lists every dynamic variable available at each trigger point, including the full set of LearnDash and TutorLMS fields.

Requirements Before You Start

• WordPress 6.2 or higher, PHP 7.4 or higher
• Krom Automation free plugin installed and active (handles TutorLMS triggers and basic LearnDash triggers)
• Krom Automation Pro required for conditional branching by quiz score, user role, or group membership, and for the LearnDash group enrolment action
• LearnDash 4.0 or higher, or TutorLMS 2.0 or higher
• Action Scheduler must be able to run; shared hosting with WP-Cron disabled will delay workflow execution

LearnDash Setup: Course Completion Triggers Next Enrolment

The LearnDash integration documentation covers every available trigger and action, but here is the exact path for a completion-to-enrolment workflow.

Step 1: Create a new workflow

Go to Krom Automation > Workflows in the WordPress admin sidebar. Click Add New Workflow.

Give it a name that identifies the source course, such as “Module 1 Complete: Enrol in Module 2”. Click Save to open the visual canvas.

Step 2: Add the trigger

Click the Add Trigger node on the canvas. In the trigger panel that slides open on the right, select LearnDash from the integration dropdown. Choose Course Completed from the trigger list.

In the Course field, search for and select the source course by name. Click Save Trigger.

Step 3: Add a condition (optional but recommended)

If you only want to enrol students who passed a final quiz with 80 percent or above, click the Add Condition button on the trigger node. Set Field to Quiz Score, Operator to greater than or equal to, and Value to 80. The canvas will split into a Yes path and a No path.

Drag your enrolment action onto the Yes path. The conditions and branching documentation explains how to stack multiple conditions if you need to check both score and user role.

Step 4: Add the enrolment action

Click Add Action on the Yes path (or directly on the trigger if you skipped the condition). Select LearnDash from the integration dropdown. Choose Enrol User in Course.

In the Course field, search for and select the destination course. In the User field, select Triggering User from the dynamic options. Click Save Action.

Step 5: Add a confirmation email (optional)

Click Add Action below the enrolment node. Select Send Email.

Set To to the merge tag {{user.email}}, set Subject to something like “You’ve been enrolled in {{course.title}}”, and write the body using any merge tag listed in the dynamic variable panel. If your emails are landing in spam, the guide on automated WordPress emails going to spam covers SMTP configuration and sender authentication steps.

Step 6: Enable and test

Toggle the workflow status to Active in the top-right corner of the canvas. Before going live, click Test Workflow to open the workflow simulator.

The simulator runs a dry-run with zero side effects, so no real enrolment fires and no email sends. Confirm all nodes show green, then save and exit.

TutorLMS Setup: Course Completion Triggers Next Enrolment

The process is almost identical. The TutorLMS integration documentation lists the full trigger and action set. The key difference is that TutorLMS does not expose quiz score as a merge tag in the same way, so conditional branching by score requires the Pro version and uses the Quiz Passed trigger rather than Course Completed.

Step 1: Create a new workflow

Go to Krom Automation > Workflows > Add New Workflow. Name it, for example “Foundation Complete: Enrol in Advanced”. Open the visual canvas.

Step 2: Add the trigger

Click Add Trigger, select TutorLMS from the integration dropdown, and choose Course Completed. In the Course field, select the source course. Click Save Trigger.

Step 3: Add the enrolment action

Click Add Action, select TutorLMS, and choose Enrol User in Course. Set Course to the destination course and User to Triggering User. Click Save Action.

Step 4: Enable and test

Set the workflow to Active. Use the simulator to confirm the workflow resolves correctly before any real student completes the source course.

A workflow that fires 30 minutes after completion because WP-Cron was asleep is not a failed workflow. It is a misconfigured server. The fix takes 5 minutes and lives outside WordPress entirely.

Conditional Enrolment: Beyond the Simple On/Off Trigger

Every competitor covering auto-enrolment treats it as a binary: completion fires, enrolment happens. That is the right starting point, but most L&D teams need more than that. Krom Automation’s conditional branching handles the three most common real-world variations.

Enrol by user role

Add a condition after the trigger. Set Field to User Role, Operator to equals, and Value to the role name, for example subscriber or a custom role like sales-rep.

Managers can branch to a leadership track course while individual contributors branch to a skills course. One workflow, two paths, zero manual sorting.

Enrol by quiz score threshold

Use LearnDash’s Quiz Passed trigger instead of Course Completed if you want score-based routing. Set a condition on Quiz Score with a threshold of your choosing.

Students above the threshold enrol in the advanced course; students below enrol in a remedial or review course. This is the setup most training managers eventually ask for, and it is not available in any plugin that treats auto-enrolment as a single toggle.

Enrol after a delay

Some courses benefit from a gap before the next enrolment so the student has time to apply what they learned. Add a Delay node between the trigger and the enrolment action.

Set it to 7 days or any interval. The delays and scheduling documentation covers every available unit including a custom number of seconds for precise timing.

Enrolment Decision Table: Which Setup Fits Your Situation

Use this table to find the right configuration before you build. Building the wrong one and refactoring costs 30 to 60 minutes per workflow.

Your situation	Trigger to use	Condition needed	Pro required?
All completions enrol in the next course	Course Completed	None	No
Enrol only students who passed the final quiz	Quiz Passed (LearnDash)	Quiz Score >= pass mark	Yes
Different next course based on user role	Course Completed	User Role equals [role]	Yes
Enrol with a 7-day gap after completion	Course Completed	None, add Delay node	No (delay is free)
Enrol in multiple follow-on courses at once	Course Completed	None, add multiple Enrol actions	No
Enrol based on BuddyBoss group membership	Course Completed + Group check	Group membership condition	Yes
Notify a Slack channel on each enrolment	Course Completed	None, add messaging action	Yes (messaging is Pro)

Treating auto-enrolment as a single on/off switch is how you end up with every student on the same path regardless of what they demonstrated they know.

What Does NOT Transfer (Read This Before You Build)

Every integration guide should include this section. Most do not, which is why people discover these limits the hard way.

• Course progress does not carry over. Enrolment in the new course starts at zero. Any completion percentage, quiz attempt, or assignment from the source course stays on the source course. There is no mechanism to migrate progress between courses in either LearnDash or TutorLMS, and Krom Automation does not change that.
• Course access duration is not inherited. If your destination course has an expiry set, that expiry clock starts from the enrolment date the workflow creates, not from the original purchase date. Students enrolled 6 months after the original purchase will have the same access window as a student enrolled on day one.
• Paid course restrictions are bypassed. Krom Automation’s enrolment action enrols at the plugin level, not through the payment gateway. A paid course that requires WooCommerce or a membership to access will have the enrolment record written but access may still be blocked by the payment restriction layer. Test this in staging before deploying to a paid course.
• Group enrolment is not the same as individual enrolment. Enrolling a user in a course does not add them to a LearnDash group. If your course progress, reporting, or certificates depend on group membership, add a separate group enrolment action in the workflow.
• TutorLMS certificate triggers do not fire on programmatic enrolment. If you use TutorLMS certificates tied to course completion, test whether the certificate hook fires correctly when enrolment comes from an automation rather than a student clicking “Start Course” manually.

Troubleshooting the Three Common Failure Modes

Failure mode 1: The workflow fires but enrolment does not appear

Check the execution log under Krom Automation > Logs. If the enrolment action shows a green tick but the student is not enrolled, the destination course has a paid or membership access restriction that is blocking the enrolment record from granting access.

The fix is to either remove the access restriction on the destination course, use a MemberPress or WooCommerce action to grant access first, or switch the course access mode in LearnDash from Buy Now / Subscribe to Open for programmatically managed courses. See the MemberPress integration documentation if membership is involved.

Failure mode 2: The workflow fires 20 to 40 minutes late

This is WP-Cron. Krom Automation uses Action Scheduler to run workflows in the background, which depends on WP-Cron firing. On a low-traffic site, WP-Cron only runs when someone visits the site.

If no visitor arrives for 30 minutes after a course completion, the workflow waits. The permanent fix is a real server cron job: add */5 * * * * php /path/to/wp-cron.php to your crontab and disable WP-Cron in wp-config.php by setting DISABLE_WP_CRON to true. That change takes under 5 minutes and makes every scheduled WordPress task reliable, not just Krom Automation workflows.

Failure mode 3: The workflow fires multiple times for the same student

Check the Run Once Per Entity setting in Workflow Settings. This setting prevents a workflow from firing more than once for the same user-course combination. If it is off, a student who re-takes a course or whose completion record is written twice by a plugin conflict will trigger multiple enrolments.

Enable Run Once Per Entity on any workflow where duplicate enrolment would cause problems. The workflow settings documentation explains the exact option and what entity matching covers.

Enrolling in Multiple Follow-On Courses at Once

A single trigger can drive multiple enrolment actions. On the workflow canvas, after the trigger node, add one Enrol User in Course action for each destination course. All actions run in sequence during the same execution.

There is no limit on the number of actions per workflow in the free version. A student completing a certification course can be simultaneously enrolled in 3 supplementary modules, added to a cohort email list, and sent a congratulations email, all from one workflow.

If you want different courses for different cohorts, use conditional branching rather than multiple workflows. One workflow with branching is easier to audit than 6 separate workflows that all watch the same trigger. The step-by-step workflow builder guide shows how to arrange multi-action and multi-branch flows on the canvas.

One workflow with conditional branching is always easier to maintain than six workflows watching the same trigger. Audit one, not six.

Automations Worth Pairing With Course Enrolment

Auto-enrolment on its own handles progression. Add the following actions to the same workflow to handle the full student experience without any manual intervention.

• Send Email: Notify the student of their new enrolment with a link to the course. Personalise with {{user.display_name}} and {{course.title}} merge tags.
• Update User Meta: Write the enrolment date to a custom user meta field for reporting or CRM sync.
• FluentCRM tag: Add a “Module 2 Enrolled” tag in FluentCRM to trigger a nurture sequence. See the FluentCRM integration documentation for exact field names.
• Slack notification: Alert a team channel when a student progresses, useful for cohort-based programmes where a manager tracks completion rates. The messaging integrations documentation covers Slack setup.
• HTTP Request: Push the enrolment event to an external BI tool or HR system using a webhook. No Pro licence needed for outgoing HTTP requests.

What This Costs: Free vs Pro for Auto-Enrolment Workflows

The free Krom Automation plugin handles a straight completion-to-enrolment workflow with no conditions. Most teams reach for Pro within a few weeks once they want role-based or score-based routing.

Capability	Free	Pro
Course Completed trigger (LearnDash and TutorLMS)	Yes	Yes
Enrol User in Course action	Yes	Yes
Multiple enrolment actions per workflow	Yes	Yes
Delay node between completion and enrolment	Yes	Yes
Conditional branching by quiz score or user role	No	Yes
LearnDash group enrolment action	No	Yes
FluentCRM tag on enrolment	No	Yes
Slack or Discord notification on enrolment	No	Yes
Schedule trigger for bulk enrolment on a set date	No	Yes

Pro plans start at $119 per year for a single site or $299 as a one-time lifetime licence. If you manage 5 or more sites the Standard plan at $199 per year works out to $40 per site annually, which is less than an hour of developer time for a single manual workflow build. See the full pricing breakdown for plan details.

Practical Numbers: What Manual Enrolment Actually Costs

On a site with 200 course completions per month, manual enrolment takes roughly 2 to 3 minutes per student if you are fast: locate the user, open their profile, find the course, click enrol, confirm. That is 400 to 600 minutes per month, or 7 to 10 hours.

At a $50 hourly rate for an admin or VA, that is $350 to $500 per month in labour. A lifetime Pro licence at $299 pays for itself in under one month at that volume.

Even at 30 completions per month, the mental overhead of checking a completion queue daily, deciding which course comes next, and tracking who has been processed costs more than the licence. The automation stack we deploy on every client build includes an LMS progression workflow as one of the first automations added, for exactly this reason.

Also from wpRigel

Pollify is our Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the editor, so there is no shortcode to paste and no separate interface to manage. It works well alongside course content where you want to embed a quick knowledge check or learner satisfaction survey directly in a lesson page.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to search everything and run admin actions without navigating menus.

For sites managing large student rosters, the ability to find a user, view their profile and open their course history in under 3 seconds is a genuine time saver. It is the only WordPress command palette with real WooCommerce order, product and customer commands built in.

Our Verdict: Who Should Build This Workflow Today

If you have a linear course structure where every student follows the same path, the free Krom Automation plugin sets this up in under 15 minutes and you never touch it again. That is the case for most course creators and most membership sites with a defined curriculum.

If your programme has branching paths, role-based tracks, or score-based routing, invest in Pro. The conditional branching alone saves more time than the licence costs, because the alternative is either manual sorting or a bespoke developer build that costs $500 to $2,000 and breaks when the LMS plugin updates.

Who should wait: if you are still building the courses themselves and have fewer than 10 active students, set up the workflow once the content is stable. Automating a half-finished curriculum creates enrolment records in courses that do not exist yet, which generates support tickets from confused students. Build the automation the week before you open enrolment, not the week you start writing content.

Download the free plugin from the WordPress.org plugin directory and install it in under 3 minutes, or compare the Pro plans if conditional branching is on your list.

FAQ

Does auto-enrolment work if the follow-on course is a paid course?

Krom Automation writes the enrolment record at the plugin level. If the destination course is set to open access in LearnDash or TutorLMS, the student gets in.

If it is restricted to paying members or WooCommerce purchasers, the enrolment record may be blocked by the access layer even though the workflow ran successfully. Test in staging with your exact access mode before using this on a paid course.

Can one completion trigger enrolment in several courses at once?

Yes. Add one Enrol User in Course action for each destination course on the same workflow canvas.

All actions run in the same execution. There is no limit on the number of actions per workflow in either the free or Pro version.

What happens if a student completes the source course twice?

Enable Run Once Per Entity in the workflow settings. This prevents the workflow from firing more than once for the same user-course pair, so a student who re-completes a course or whose completion record is written twice does not receive a duplicate enrolment in the follow-on course.

Will the workflow still fire if my site has very low traffic?

It will fire, but possibly late. Krom Automation uses Action Scheduler, which depends on WP-Cron.

On low-traffic sites, WP-Cron only triggers when someone visits. Configure a real server cron job to run every 5 minutes and disable WP-Cron in wp-config.php to make execution timing reliable regardless of traffic levels.

Can I auto-enrol students in a course based on their job role rather than a course they completed?

Yes, with Pro. Use the User Role Changed trigger or a User Registered trigger combined with a condition that checks the assigned role.

If the role matches, the enrolment action fires. This is the standard setup for onboarding new employees into a required training track automatically when their account is created with the correct role.

For a single client site, WordPress automation pricing looks manageable under almost any model. At five sites, the gap between per-task billing and flat licensing starts to show.

At twenty-five sites, that gap can reach $3,000 to $6,000 per year, and that is before accounting for the hours your team spends managing API limits, monitoring execution failures, and explaining surprise invoices to clients. The right model is flat licensing, self-hosted, with a perpetual or annual cap, and Krom Automation is the WordPress-native tool built around that model.

This article is a money argument. We will model the actual cost of running automation across 5, 10 and 25 client sites under two billing structures, name what the marketing pages leave out, and give you a decision table you can take into a proposal conversation. If you already know the tools and want to skip to the numbers, jump to the cost model section.

If you are still evaluating what workflow automation inside WordPress actually looks like before committing to a licensing structure, the overview of how Krom Automation works covers triggers, actions and the canvas in one place.

Browse the full feature list to see what is included at the free tier versus Pro before reading the cost model below.

The Two Billing Models, Defined

Every automation tool you will evaluate falls into one of two structures. Understanding which is which prevents a decision that looks smart on month one and looks catastrophic on month twelve.

Per-task or per-execution billing charges you each time a workflow step runs. Zapier calls them tasks. Make calls them operations.

The price per unit is low, but the volume compounds fast on active client sites. A WooCommerce store completing 200 orders per month, each triggering a three-step workflow, consumes 600 tasks monthly from that site alone.

Flat licensing charges a fixed annual or one-time fee for a defined number of site activations. Every workflow runs as often as it needs to.

There is no per-execution counter, no usage dashboard to watch, and no month-end reconciliation. Self-hosted plugins almost always use this model, and that structural difference is the main reason agencies running ten or more client sites should default to it.

Per-task billing is a pricing model optimised for the vendor’s revenue, not your cost predictability. At agency scale, predictability is worth paying for.

What Per-Task Billing Actually Costs at Agency Scale

The following table models a realistic agency portfolio: a mix of simple brochure sites with light automation and active WooCommerce or membership sites with heavier trigger volumes. We use conservative estimates. Real active stores will push these figures higher.

Sites	Avg tasks/month per site	Total monthly tasks	Zapier Professional (~$49/mo per 2k tasks)	Make Core (~$9/mo per 10k ops)	Flat plugin licence (annual)
5	800	4,000	~$98/mo ($1,176/yr)	~$45/mo ($540/yr)	$199/yr (5 sites)
10	800	8,000	~$196/mo ($2,352/yr)	~$90/mo ($1,080/yr)	$369/yr (unlimited)
25	800	20,000	~$490/mo ($5,880/yr)	~$225/mo ($2,700/yr)	$369/yr (unlimited)

The Krom Automation figures are exact: $199/year covers 5 site activations and $369/year covers unlimited sites. The Zapier and Make figures are modelled from their published tier structures; actual costs will vary based on the exact plan you need to fit your task volume. The point is directional: at 25 sites, flat licensing costs roughly 15 times less than Zapier at equivalent task volumes.

If even half your clients run modest WooCommerce stores, 800 tasks per site per month is conservative. A busy store with abandoned cart recovery, order status workflows, and a post-purchase email sequence can hit 2,000 to 3,000 tasks monthly on its own. Run those numbers through the table above.

Year One Versus Year Two: The Licensing Decision

Flat licensing has an upfront cost. Per-task billing spreads the cost into smaller monthly payments that feel manageable.

This is the framing that gets agencies into expensive per-task arrangements. The table below reframes it correctly.

Scenario	Year 1 total cost	Year 2 total cost	2-year total
10 sites, Zapier	$2,352	$2,352	$4,704
10 sites, Make	$1,080	$1,080	$2,160
10 sites, Krom Automation (annual)	$369	$369	$738
10 sites, Krom Automation (lifetime)	$799	$0	$799

The lifetime Enterprise licence at $799 pays for itself before the end of year one if you are running ten or more sites, and every year after is free. The annual plan at $369 for unlimited sites is cheaper than most agencies spend on a single SaaS subscription that serves only one client.

What the Marketing Pages Do Not Tell You

Every automation vendor emphasises what works. Here is what they do not lead with.

• Per-task counters do not distinguish test runs from production runs. Every time a developer tests a workflow on a staging or client site, those test executions count against your quota. Krom Automation’s workflow simulator runs dry runs with zero side effects and nothing hits an execution counter because there is no counter.
• Multi-account management adds cost. Most SaaS automation tools charge per workspace or per account. Running Zapier across ten client accounts may mean ten separate billing relationships or a premium agency plan that changes the maths entirely.
• Client data leaves the server. SaaS automation runs on the vendor’s infrastructure. Form submissions, order data, user records and API credentials all travel through external servers. For clients in regulated industries or with data residency requirements, this is a compliance issue, not just a preference.
• Workflow migration is expensive. If you build 40 client workflows in Zapier and then switch tools, you rebuild manually. There is no export format that travels between platforms. Krom Automation workflows export as portable JSON, so you can version control them and redeploy across sites without rebuilding.
• Failure notifications are often paid features. Knowing when a workflow fails is basic operational hygiene. Krom Automation sends failure notifications by email and retries automatically with configurable backoff, included in the free version. Knowing a client’s welcome email stopped firing three days ago should not require a paid tier.

Client data flowing through a vendor’s servers is not a “privacy preference”. For agencies serving healthcare, finance or EU-based clients, it is a liability your contract may not cover.

The Hidden Labour Cost

Tool licensing is the visible number. Developer time is the one that quietly dominates the real cost of running automation at agency scale.

A developer debugging a failed Zapier workflow spends time inside a tool they do not control, reading logs they cannot extend, and waiting on support tickets for issues they cannot fix themselves. A developer debugging a Krom Automation workflow has full per-step execution logs inside WordPress, a simulator for safe testing, and direct database access if they need it. That difference is roughly 30 to 90 minutes per incident, depending on complexity.

If your team touches a failing workflow twice per client site per month, and you are running 10 sites, that is 20 debugging sessions. At a $120 hourly rate, the labour cost of inferior logging tools is $720 to $2,160 per month in developer time. That number dwarfs any tool licensing difference.

The analytics dashboard in Krom Automation shows success rate per workflow, total executions, failed execution count and an execution trend chart. More importantly, the full per-step audit trail shows exactly which action failed and why. That is what cuts debugging time, and it is available in the free version.

Which Automation Tasks Actually Run at Volume

Before you can model your real task count, you need to know what actually fires on an active client site. These are the automations that drive the majority of executions across a typical agency portfolio.

• WooCommerce order workflows: confirmation emails, status change notifications, post-purchase sequences. A store completing 300 orders per month with a three-step workflow per order generates 900 executions monthly from one automation alone.
• Form submission follow-ups: Gravity Forms, Contact Form 7 and WPForms each generate a trigger per submission. A lead generation site with 50 daily form submissions generates 1,500 trigger events monthly.
• Membership and LMS enrollments: MemberPress and LearnDash fire triggers on signup, payment, expiry and course completion. Onboarding sequences add 3 to 5 actions per trigger.
• Email list sync: syncing WordPress users to Mailchimp, FluentCRM or ActiveCampaign on every registration, role change or opt-in. High-traffic sites push these numbers fast.
• Slack and messaging alerts: Slack, Discord and Twilio notifications on order events or form submissions. Each message is one task in per-task billing.

Add these up across an active client site and 800 tasks per month is a floor, not a ceiling. We have seen membership sites comfortably exceed 5,000 executions monthly without any unusual workflow complexity.

Under flat licensing that is irrelevant. Under per-task billing it is a budget conversation nobody planned for.

How to Price Automation as a Deliverable to Clients

Every result we reviewed covers tool pricing. None of them cover what you should charge clients for the automation work itself. That gap is where agency margin lives.

There are three serviceable models.

• Project fee plus retainer: charge a one-time setup fee of $500 to $2,000 depending on complexity, then a monthly retainer of $150 to $400 for monitoring, updates and new workflow builds. This is the most common model and the most predictable for both parties.
• Embedded in the build price: include automation setup as a line item in the site build, typically 10 to 20 percent of the total project fee. Ongoing maintenance is then either a support retainer or billed hourly. Works well for simple automations the client will not touch.
• Markup on licensing: if you pass tool cost through to the client, mark it up 30 to 50 percent and include it in the maintenance invoice. At $369 per year for unlimited sites, the per-client cost is effectively zero at ten-plus sites, so the markup is pure margin. This only works with flat licensing. With per-task billing, client volume creates uncontrolled cost and unpredictable margin.

The argument for the retainer model: automation breaks. Forms change, API endpoints move, WooCommerce updates shift webhook payloads.

A client whose automation runs silently for six months and then fails during their busiest week will call you regardless of whether you have a retainer in place. Charge for the monitoring before the emergency, not after.

The client whose automation fails at 2am on Black Friday will not remember that you did not have a monitoring retainer. They will remember that you did not catch it.

What to Evaluate Before Committing to a Tool

Use this checklist before signing any automation vendor, SaaS or plugin.

• Does the licence cover your entire client portfolio, or does cost scale with site count and execution volume?
• Where does workflow data live? Client server or vendor server? Who controls access if the relationship ends?
• Can you export workflows and redeploy them? What does migration actually cost in hours if you switch tools in two years?
• What happens when a workflow fails? Email notification, automatic retry, per-step logs? Or a red icon in a dashboard you have to check manually?
• Does the tool require a separate subscription per client account, or can you manage all sites from one licence?
• Is there a staging or testing mode that does not consume your execution quota?
• Are AI features included, or are they a paid add-on that compounds the per-site cost?

Krom Automation passes all seven. The free versus Pro comparison covers exactly what is included at each tier so you can verify this yourself before committing.

The Automation Stack We Recommend Deploying

We covered the full reasoning behind our recommended per-site stack in the automation stack we deploy on every client build. The short version: one workflow automation layer handling triggers and actions, a self-hosted CRM or email list for data ownership, and flat licensing across all tools. Nothing billed per execution, nothing living on a vendor’s server that could be revoked.

For the specific integrations that drive most client site automation, the Pro features and integrations overview covers all 24 Pro integrations in one place. Forms, e-commerce, CRM, email marketing, LMS, membership, messaging and productivity tools are all covered.

Also from wpRigel

Pollify is our Gutenberg-native poll, survey and quiz plugin. Polls are built directly inside the block editor as real blocks, with no shortcodes to paste and no separate interface to configure. It is the right tool when a client site needs audience feedback, NPS scoring or quiz-based engagement built into content pages.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K from anywhere in the admin, type what you want, and jump there without navigating menus. For agencies managing client sites with dense WooCommerce setups, Commandify is the only command palette with genuine order, product and customer commands built in.

Our Verdict

If you are running five or more client sites, per-task billing is the wrong default. The cost model is structurally unfavourable at agency scale, it creates margin risk when client sites grow, and it puts execution data on infrastructure you do not control. The right default is a self-hosted flat licence with unlimited executions and portable workflow exports.

Krom Automation’s Enterprise plan at $369 per year, or $799 one-time, covers unlimited sites with every Pro feature included. That is the licence structure that works at 10 sites and still works at 50.

Download the free version from the WordPress.org plugin directory and build your first workflow before committing to anything. The free tier includes 16 triggers, 21 actions and a full visual canvas with no execution caps and no trial period.

Who should not act yet: agencies running fewer than three active client sites where automation volume is genuinely low. At that scale, the per-task cost stays manageable and the switching cost of migrating existing workflows may not be worth it. Build your next client site on flat licensing and migrate when the current contracts renew.

See the full pricing breakdown and compare all three plans before your next client proposal.

Frequently Asked Questions

Do I need one Krom Automation licence per client site, or does one plan cover multiple sites?

One plan covers multiple sites. The Standard plan covers 5 site activations at $199 per year. The Enterprise plan covers unlimited sites at $369 per year. You install the plugin on each client site and activate it against your licence key. There is no per-site billing and no usage-based charges.

Can I manage automation across all client sites from one dashboard?

Krom Automation is self-hosted, so each site has its own installation and its own workflow canvas. There is no centralised multi-site dashboard. Workflows export as portable JSON, so you can build a workflow once, export it, and import it across client sites without rebuilding.

What happens if a client’s workflow fails while I am not watching?

Krom Automation sends email failure notifications automatically and retries failed workflows with configurable backoff. The execution log shows a full per-step audit trail so you can identify exactly which action failed and why. Both features are included in the free version.

Is per-task billing always more expensive than flat licensing for agencies?

At low volume, per-task billing can cost less. The crossover point depends on your client mix. Based on the cost model in this article, flat licensing becomes cheaper than Zapier at roughly 2 to 3 active sites, and cheaper than Make at roughly 5 to 7 sites. Above that threshold, the gap widens every month.

Are AI workflow features included in Krom Automation Pro, or is that a separate charge?

AI actions are included in the free version with no paywall. Pro adds AI workflow generation, where you describe an automation in plain English and get a working workflow. You supply your own API key and pay your AI provider directly at standard rates. wpRigel does not charge per AI call and does not mark up token costs.

What does client data residency look like under a self-hosted model?

With Krom Automation, all workflow data, execution logs, API credentials and trigger payloads stay in the client’s WordPress database on their server. Nothing passes through wpRigel’s infrastructure. For clients in regulated industries or with GDPR obligations, this is the default you want, not an upgrade you have to request.

Automated WordPress emails go to spam because WordPress uses PHP’s mail() function by default. That function sends from your server with no SPF record, no DKIM signature, and no domain alignment, which is exactly what modern spam filters are trained to reject. The fix is switching to authenticated SMTP, but the right fix depends on which emails are failing and why, and that diagnosis is where most guides skip over the detail you actually need.

This guide covers every root cause: authentication gaps, shared IP reputation, content triggers, sending volume, and the Google and Yahoo policy changes that tightened bulk sender requirements in 2024 and 2025. It also covers the one thing most fix guides ignore: how to detect future failures automatically, before your customers notice them first.

The diagnostic table below is a good starting point if you already have a hunch about the cause. If you want to understand each issue in depth, work through the sections in order.

Quick Diagnostic: Symptom, Cause, and Fix

Work through this table before anything else. Match the symptom you are seeing to the most likely cause, then jump to the relevant section for the full fix. Skipping ahead without this step wastes time.

Symptom	Most Likely Cause	Fix
All WordPress emails land in spam	PHP mail with no authentication	Switch to SMTP with SPF and DKIM configured
Emails reach inbox on Outlook but spam on Gmail	Missing or misaligned DMARC record	Add a DMARC record; check From domain matches sending domain
Emails worked fine, then suddenly started failing	Shared IP added to a blacklist	Check IP on MXToolbox; switch to a dedicated IP or reputable ESP
WooCommerce order emails specifically are failing	From address is a no-reply or generic domain	Set From address to a real mailbox on your domain; confirm DKIM covers it
Password reset and registration emails go to spam	WordPress default From address (wordpress@yourdomain.com)	Override the From name and address in your SMTP plugin settings
Contact form notification emails land in admin spam	From header set to the visitor’s email on a foreign domain	Send from your own domain, put the visitor’s address in Reply-To only
High-volume sends trigger spam filters	Sudden volume spike from a shared IP	Warm up a dedicated IP or use a transactional ESP with volume handling
Emails pass SMTP but body content still flagged	Spam trigger words, broken HTML, or missing plain-text part	Audit email content; add plain-text version; remove link shorteners
Emails disappear entirely, no spam folder	Hard bounce or domain/IP on a major blocklist	Check domain reputation on Google Postmaster Tools; review bounce logs

The Real Problem: PHP Mail Has No Identity

WordPress ships with wp_mail(), which wraps PHP’s mail() function. By default it sends directly from your server without any cryptographic signature, without a matching return path, and often from an IP address shared with hundreds of other sites.

Spam filters do not care that your email is legitimate. They check three things: does the sending IP have a clean reputation, does the domain authenticate the sender, and does the message content match known spam patterns. PHP mail fails the first two checks by design.

PHP mail is not a deliverability tool. It is a server function that assumes the network will trust you. Modern spam filters assume the opposite until you prove otherwise.

The volume of email going through shared hosting makes the problem worse. Your server’s IP is shared with other WordPress sites.

If any of those sites send spam, get compromised, or hit bounce thresholds, every site on that IP inherits the reputation damage. You can run a clean operation and still land in spam because of a neighbour you have never met.

Authentication: SPF, DKIM, and DMARC Explained in Plain Terms

Email authentication is three DNS records that tell receiving mail servers who is allowed to send on your behalf. All three matter. Having two out of three still leaves gaps that Gmail and Outlook will flag.

• SPF (Sender Policy Framework): A TXT record on your domain that lists the IP addresses and services authorised to send email from it. If your SMTP provider’s IP is not in this list, messages will fail SPF checks. One SPF record per domain, and it must not exceed 10 DNS lookups.
• DKIM (DomainKeys Identified Mail): A cryptographic signature added to every outgoing message. The receiving server looks up your public key in DNS and verifies the signature. Tampering with the message in transit breaks the signature and triggers a fail. Your SMTP provider will give you a CNAME or TXT record to add.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): A policy record that tells receiving servers what to do when SPF or DKIM fails, and where to send failure reports. Without DMARC, Gmail and Yahoo have no instruction from you on how to handle unauthenticated mail claiming your domain.

A minimal DMARC record looks like v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. Start with p=none to collect reports without blocking anything, then move to p=quarantine or p=reject once you have verified all your sending sources are authenticated.

What Changed in 2024 and 2025 with Google and Yahoo

Google and Yahoo both introduced mandatory bulk sender requirements in early 2024. From February 2024, any domain sending more than 5,000 emails per day to Gmail addresses must have SPF, DKIM, and a DMARC record in place. Domains without them are routed to spam or rejected outright.

Yahoo applied the same thresholds. The enforcement tightened further in 2025 with stricter alignment requirements, meaning the From domain must match the domain covered by your DKIM signature. A mismatch that previously caused a soft failure now results in a hard spam classification on many providers.

If your automated WordPress emails were working in 2023 and started failing in 2024, this is the most likely explanation. The emails did not change. The receiving server’s standards did.

Switching from PHP Mail to SMTP

The single highest-impact fix is replacing PHP mail with an authenticated SMTP connection. This requires two things: an SMTP plugin to override wp_mail(), and an SMTP service to route through.

Popular SMTP plugin options include WP Mail SMTP, FluentSMTP, and Easy WP SMTP. All of them hook into WordPress’s mail system and redirect outgoing messages through an authenticated connection rather than the server’s PHP mail function. The plugin itself is not the deliverability layer; the SMTP service behind it is.

For transactional email services, the main options fall into two categories:

• Free tiers with volume limits: Brevo (formerly Sendinblue) allows 300 emails per day on the free plan. Mailgun has a 3-month trial with 5,000 emails per month. SendGrid allows 100 emails per day on the free plan indefinitely.
• Pay-as-you-go services: Postmark, Amazon SES (roughly $0.10 per 1,000 emails), and Mailgun’s paid tiers. These are worth considering once your volume exceeds free tier limits or you need dedicated IP options.

Configure the From name and From address inside your SMTP plugin settings. The From address must be on a domain where you control DNS, so you can add the DKIM record your SMTP provider requires. Using a Gmail or Outlook address as your From address causes DKIM misalignment because you are sending through your own SMTP provider while claiming to be from Google or Microsoft’s domain.

Which Emails Are Failing? The Answer Changes the Fix

Most deliverability guides treat “WordPress emails” as a single category. They are not. The cause of failure differs depending on which automated email is going to spam, and diagnosing the right one saves significant time.

WooCommerce Order Confirmation Emails

These fail most often because of the From address. WooCommerce defaults to woocommerce@yourdomain.com or whatever the site admin email is set to. If DKIM is configured for a different subdomain or the sending domain does not match, alignment fails.

Check WooCommerce Settings Emails and verify the From Name and From Address fields. They must match the domain your DKIM record covers.

If you use Krom Automation to send order-related follow-up emails, configure the Send Email action’s From field to the same authenticated address. You can see the full WooCommerce trigger and action options in the all free actions reference.

Password Reset and User Registration Emails

WordPress sends these from wordpress@yourdomain.com by default, with the From name “WordPress”. Neither the address nor the name builds trust with a spam filter. Override both in your SMTP plugin and point them to a real mailbox your domain owns.

If you use Krom Automation to send a welcome email when a user registers, the welcome email automation guide walks through how to configure the trigger and action together, including setting the correct From details in the workflow itself.

Contact Form Notification Emails

This is the most misdiagnosed case. Many form plugins set the From address to the email the visitor submitted in the form. If that is a Gmail or Hotmail address, your server is claiming to send on behalf of Google or Microsoft, which SPF will fail immediately.

The correct setup is to send from your own domain address and put the visitor’s email in the Reply-To header only. Krom Automation’s integrations with Contact Form 7, Gravity Forms, and WPForms all support this pattern. Trigger on form submission, send the notification from your domain, pass the visitor’s email through a merge tag into the Reply-To field.

Setting the From address to the visitor’s submitted email is not a friendly touch. It is the most common reason contact form notifications land in spam.

Content Triggers That Cause Spam Classification

Authentication solves the identity problem. Content triggers are a separate issue that authenticated emails can still fail on. Spam filters analyse the body and subject line independently of sender reputation.

Common content-level triggers to audit:

• Spam trigger words in subject lines: “FREE”, “URGENT”, “Act now”, “Guaranteed”, “Winner” and similar phrases raise scores on most filters. This applies even to transactional emails like order confirmations if the subject line is written poorly.
• HTML-only emails with no plain text alternative: Legitimate services send multipart messages with both HTML and plain text. A message with only an HTML body looks like bulk spam to filters. Most SMTP plugins add the plain-text part automatically, but verify it in your email header inspector.
• Broken or excessive HTML: Deeply nested tables, inline styles exceeding several kilobytes, and unclosed tags all raise spam scores. If you build custom email templates, test the raw HTML through a tool like Mail-Tester before deploying.
• Link shorteners and tracking pixels from unknown domains: Links pointing to shortened URLs or external tracking domains your recipients have never seen lower trust scores significantly. Use first-party tracking or your ESP’s built-in tracking, which resolves to a trusted domain.
• Image-heavy emails with little text: A message that is 90 percent image and 10 percent text looks like a phishing attempt. Keep a reasonable text-to-image ratio and always include descriptive alt text.

Shared IP Reputation and When to Use a Dedicated IP

On shared hosting, your sending IP is shared with every other site on that server. One compromised site sending spam can blacklist the IP for everyone. You have no control over this and may not notice for days.

Check your sending IP reputation at MXToolbox’s blacklist checker and Google Postmaster Tools. If you find your IP on one or more blocklists, delisting takes between 24 hours and 2 weeks depending on the list. The faster fix is switching to a transactional email service that uses its own IP infrastructure rather than your hosting server’s IP.

A dedicated IP is worth considering when you send more than roughly 50,000 emails per month consistently. Below that volume, a clean shared IP on a reputable ESP like Postmark or Mailgun is more effective than a cold dedicated IP, because a dedicated IP with low volume looks suspicious to filters that expect high-volume senders on dedicated IPs. Warming a dedicated IP correctly takes 4 to 8 weeks of gradually increasing volume.

Monitoring: The Step Everyone Skips

Every guide covers the one-time setup. Almost none cover what happens three months later when something quietly breaks. A DNS record gets overwritten during a domain migration.

A DKIM key rotates but the old record stays in DNS. A plugin update changes the From address back to the WordPress default.

Set up at least these three monitoring layers:

• Google Postmaster Tools: Free. Shows your domain reputation and spam rate as Google sees it. Check it monthly at minimum. A spike in spam rate means something changed and you need to find it before it compounds.
• Failure notifications from your SMTP plugin: Most SMTP plugins can alert you when an email fails to send. Enable this and route alerts to an inbox someone reads. A silent failure is worse than a noisy one.
• Workflow failure alerts in Krom Automation: If you use Krom Automation for automated emails, every execution is logged with a per-step audit trail. Failed executions trigger an email notification and an automatic retry with configurable backoff. Check the execution logs weekly and treat any failed Send Email action as a signal to investigate SMTP health, not just retry the workflow.

A deliverability problem that goes undetected for 30 days is not a technical failure. It is a customer relationship failure.

The emails were going out. Nobody was receiving them.

Cost of Getting This Wrong: A Realistic Estimate

The case for fixing this properly is easier to make when you attach numbers to the failure modes.

Scenario	Estimated Cost or Impact
WooCommerce order confirmation goes to spam	Customer emails support 2 to 4 times per order, adding 15 to 30 minutes of support time per affected order
Password reset emails land in junk	User cannot log in, abandons the site; on a membership or SaaS site this is a direct churn event
Lead follow-up from contact form missed	Prospect assumes no response and contacts a competitor; conversion lost
Transactional ESP on pay-as-you-go plan	Amazon SES costs roughly $1 per 10,000 emails; Mailgun roughly $1 per 1,000 emails at entry tier
Fixing a blacklisted IP versus preventing it	Delisting takes 1 to 14 days; preventing it costs $0 by switching to a clean ESP before the blacklisting occurs
Developer time to diagnose and fix from scratch	2 to 4 hours at $80 to $150 per hour, or $160 to $600 per incident

The authentication setup takes under an hour for most sites. The DNS propagation takes up to 48 hours but requires no further effort.

The ongoing monitoring described above takes under 10 minutes per month. Every one of the costs in the table above is avoidable.

The Complete Fix Checklist

Work through these in order. Skipping to step 4 without completing step 2 is a common mistake that wastes time, because SMTP without authentication still fails DMARC checks.

1. Install an SMTP plugin and connect it to a transactional email service. Configure the From name and From address to a real mailbox on a domain you control.
2. Add an SPF record that includes your SMTP provider’s sending servers. Use your DNS provider’s TXT record editor. Verify with MXToolbox’s SPF checker.
3. Add the DKIM record your SMTP provider gives you. This is usually a CNAME or TXT record under a subdomain like mail._domainkey.yourdomain.com. Verify with MXToolbox.
4. Add a DMARC record starting with p=none and a reporting address you monitor. After 2 to 4 weeks of reviewing reports with no unexpected failures, move to p=quarantine.
5. Fix your From addresses across every email-sending plugin: WooCommerce, contact form plugins, membership plugins, LMS plugins. They must all send from a domain your DKIM covers.
6. Audit email content for spam trigger words, HTML-only messages, and link shorteners. Test with Mail-Tester before and after.
7. Enable failure notifications in your SMTP plugin and in your automation plugin so silent failures surface immediately.
8. Verify monthly using Google Postmaster Tools. A clean setup can degrade without warning if DNS is changed or a plugin resets a setting.

If you use Krom Automation for any of your automated emails, the visual email builder lets you control the full message structure, including the plain text version, without editing raw HTML. Pair that with merge tags to inject dynamic data like order numbers, usernames, and product names into authenticated messages that pass every filter check.

For teams running automation across multiple plugins and integrations, the automation stack we deploy on every client build covers how to structure SMTP, authentication, and monitoring so deliverability holds across different site configurations.

Also from wpRigel

Pollify is a Gutenberg-native poll, survey, and quiz plugin for WordPress. Polls are built as real blocks inside the editor with no shortcodes to paste and no separate interface to configure.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to search everything, navigate anywhere, and run admin actions without clicking through menus. It is the only WordPress command palette with real WooCommerce order, product, and customer commands built in.

Our Verdict

Automated WordPress emails going to spam is almost always a configuration problem, not a content problem. PHP mail with no authentication, a shared hosting IP, and a mismatched From address will send legitimate emails to spam even when the message itself is perfectly written. The fix is not complicated, but it requires doing all the steps, not just the first one.

If your site sends any volume of transactional email, set up SMTP through a reputable ESP, add all three authentication records, and enable monitoring. Do it once, check it monthly, and this problem goes away. If you are managing this across multiple client sites, the 20 WordPress automations most sites should have covers the broader setup that supports reliable email delivery at scale.

You can download Krom Automation free from the WordPress.org plugin directory to handle automated email workflows with execution logging, failure alerts, and a visual email builder included at no cost.

For teams who want the full workflow automation layer alongside authenticated email delivery, see the Krom Automation Pro plans and compare what is included at each tier.

Frequently Asked Questions

Does switching to SMTP fix the problem immediately?

SMTP fixes the sending path immediately, but DNS records take up to 48 hours to propagate. Emails sent during propagation may still fail SPF or DKIM checks. Wait 48 hours after adding records, then test with Mail-Tester or MXToolbox to confirm authentication is passing before declaring the fix complete.

Why are my emails going to spam on Gmail but reaching the inbox on Outlook?

Gmail applies stricter DMARC alignment requirements than most other providers. The most common cause of this specific pattern is a missing or misconfigured DMARC record, or a mismatch between the From domain and the domain covered by your DKIM signature. Check both in MXToolbox’s DMARC lookup and compare the From header in a raw email header inspector.

Do I need a dedicated IP address to fix WordPress email deliverability?

No, and below roughly 50,000 emails per month a dedicated IP can hurt rather than help. A cold dedicated IP has no reputation, which looks suspicious to filters. Use a reputable transactional email service on a clean shared IP until your volume justifies the 4 to 8 week warm-up process a dedicated IP requires.

My contact form notifications go to my own spam folder. Is that a WordPress problem?

Usually it is a From address problem. Most contact form plugins default to setting the From address to the email the visitor submitted, which means your server claims to send on behalf of Gmail, Outlook, or Yahoo.

SPF fails immediately. Set the From address to your own domain and move the visitor’s email to the Reply-To header instead.

What is the fastest way to check if my domain or IP is blacklisted?

Run your sending domain through MXToolbox’s blacklist checker and your sending IP through the same tool separately. Google Postmaster Tools shows your domain reputation as Gmail specifically sees it, which is worth checking if Gmail is the main provider where failures are occurring. Both tools are free and return results in under a minute.

Why did my WordPress emails suddenly start going to spam after working fine for months?

The three most common causes of a sudden change are: your shared hosting IP was added to a blocklist by another site on the same server, a DNS record was overwritten during a domain renewal or migration, or a plugin update reset your From address back to a WordPress default. Check all three in that order before making changes.

You can route WooCommerce order alerts to both Slack and Twilio SMS simultaneously using Krom Automation Pro, with no code and no third-party middleware. One workflow, triggered by an Order Created or Order Completed event, fans out to both channels in under 30 seconds. Pro is required for the Slack and Twilio actions.

The gap this fills is real. Tools like Zapier and n8n keep their tutorials at the “what’s possible” level.

Nobody walks through the exact field names, the exact merge tags, and what actually breaks when order volume spikes or a Twilio API key expires. This guide does that.

We will cover building the dual-channel workflow step by step, which fields map to which destinations, when to use Slack versus SMS, and the three failure modes that catch teams off guard.

Browse the full feature list to see what else Krom Automation handles beyond order alerts.

Quick Summary

• Plugin required: Krom Automation Pro (free version handles WooCommerce triggers but Slack and Twilio actions are Pro only)
• WooCommerce triggers used: Order Created, Order Completed
• Destinations: Slack channel message, Twilio SMS to a fixed number or a dynamic customer number
• Setup time: 15 to 20 minutes for both channels on one workflow
• What you need: A Slack Bot token, a Twilio Account SID, Auth Token, and a purchased Twilio phone number

What Gets Synced: Field Mapping Table

Every field below is injected using a merge tag. Merge tags pull live data from the trigger event into the action fields at execution time, so the message your team receives contains the real order values, not placeholders.

WooCommerce Order Field	Merge Tag	Where It Lands
Order ID	{{order.id}}	Slack message body, SMS message body
Order total	{{order.total}}	Slack message body, SMS message body
Order status	{{order.status}}	Slack message body
Customer full name	{{order.billing_first_name}} {{order.billing_last_name}}	Slack message body
Customer email	{{order.billing_email}}	Slack message body
Customer phone	{{order.billing_phone}}	Twilio “To” field (dynamic customer SMS) or logged in Slack
Product names	{{order.items}}	Slack message body
Payment method	{{order.payment_method_title}}	Slack message body
Billing city	{{order.billing_city}}	Slack message body (useful for geographic routing)
Admin order URL	{{order.admin_url}}	Slack message body as a clickable link

The customer phone field deserves a note. If you want the SMS to go to the customer rather than your operations team, use {{order.billing_phone}} in the Twilio “To” field.

If that field is blank in WooCommerce, the action fails. We cover that failure mode in the troubleshooting section below.

When to Use Slack vs SMS

Both channels carry the same order data, but they serve different team behaviors. Choosing the wrong one for a given situation adds noise rather than speed.

Situation	Better Channel	Reason
Team needs to discuss or act collectively on an order	Slack	Threaded replies keep context together; anyone on the channel can pick it up
One person is on call and may not have Slack open	Twilio SMS	SMS arrives regardless of app state; no notification settings to misconfigure
High-value order requiring immediate human attention	Both	Slack for the team record, SMS to the owner’s mobile as a redundant alert
Customer confirmation of their own order	Twilio SMS to customer phone	Customers do not have Slack; SMS is the correct channel
Store processing 100+ orders per day	Slack only, with conditional filters	SMS at that volume becomes a nuisance; use conditions to send SMS only above a threshold order total
Subscription renewal or repeat order	Slack only	Routine events do not warrant interrupting a phone; log them for visibility only

Sending every order to SMS is not a notification strategy. It is a way to train your team to ignore their phones.

What You Need Before You Start

Collect these credentials before opening the workflow builder. Missing any one of them mid-setup wastes time.

• Slack Bot Token: Create a Slack app at api.slack.com, add the chat:write scope under OAuth and Permissions, install it to your workspace, and copy the Bot User OAuth Token (starts with xoxb-)
• Slack Channel ID: In Slack, right-click a channel name, choose View Channel Details, and scroll to the bottom. The channel ID looks like C0123456789. Do not use the channel name; use the ID.
• Twilio Account SID: Found on the Twilio console homepage under Account Info
• Twilio Auth Token: Same location, next to Account SID. Treat this like a password.
• Twilio “From” number: A purchased Twilio phone number in E.164 format, for example +14155551234
• Krom Automation Pro installed and active: The free plugin must also be active alongside it. See the Pro installation guide if you have not done this yet.

Step-by-Step Setup

Step 1: Create a New Workflow

Go to WordPress Admin Krom Automation Workflows Add New. The visual canvas opens on a blank workflow. Give it a name in the Workflow Name field at the top, for example “WooCommerce Order Alert: Slack + SMS”.

Open the visual workflow builder documentation in a separate tab if this is your first time on the canvas. The builder uses ReactFlow with auto layout, so nodes snap into position automatically as you add them.

Step 2: Set the Trigger

Click Add Trigger on the canvas. From the trigger panel, select WooCommerce Order Created if you want the alert at the moment of purchase, or WooCommerce Order Completed if you want it when the order fulfillment is confirmed.

For most physical goods stores, Order Created is more useful operationally. For digital or service stores, Order Completed avoids notifying the team before payment clears.

No additional configuration is required on the trigger node itself. Save the node.

Step 3: Add the Slack Action

Click Add Action below the trigger node. Select Messaging Send Slack Message.

Fill in the following fields exactly:

• Bot Token: Paste your xoxb- token here
• Channel ID: Paste the channel ID, for example C0123456789. Not the channel name.
• Message: Write your alert text and insert merge tags using the tag picker on the right side of the field. A useful starting template: New order #{{order.id}}, {{order.billing_first_name}} {{order.billing_last_name}}, ${{order.total}}, {{order.admin_url}}

Save the action node. The canvas now shows Trigger Slack Action.

Step 4: Add the Twilio SMS Action

Click Add Action again, parallel to the Slack node rather than below it. You want both actions to fire from the same trigger, not sequentially. Select Messaging Send SMS via Twilio.

Fill in these fields:

• Account SID: Your Twilio Account SID
• Auth Token: Your Twilio Auth Token
• From: Your purchased Twilio number in E.164 format, for example +14155551234
• To: Either a fixed number for your operations team (for example +447911123456) or {{order.billing_phone}} if you want the SMS to go to the customer. Choose one, not both in the same action. Add a second Twilio action if you need both.
• Message: Keep it under 160 characters to avoid multi-part SMS billing. A template that fits: Order #{{order.id}}: ${{order.total}} from {{order.billing_first_name}}. Check Slack for details.

Save the action node. The full messaging integrations documentation covers every field for both Slack and Twilio in detail.

Step 5: Add a Conditional Branch (Optional but Recommended)

If you only want the SMS to fire for orders above a certain value, click Add Condition between the trigger and the Twilio action. Set the condition to Order Total [your threshold], for example 150.

The Yes path fires the SMS. The No path fires nothing, or you can route it to Slack only.

The conditions and branching documentation explains how to combine multiple order field conditions, for example filtering by product category or billing country alongside order total.

Step 6: Test with the Simulator

Before activating, click Simulate in the top toolbar. The workflow simulator runs a dry pass through every node using sample data and reports which actions would fire and with what values.

No real Slack message or Twilio SMS is sent during simulation. This catches misconfigured tokens and bad merge tag syntax before a real order triggers the workflow.

Once the simulation passes, toggle the workflow to Active and save.

Test with the simulator before going live. A Twilio Auth Token pasted with a trailing space costs you the first real order alert and five minutes of debugging.

What Does NOT Transfer

Every integration article covers what works. This section covers what does not, because that is the part teams discover at the worst possible moment.

• Order line item images: Slack cannot render WooCommerce product images via a bot message. You get product names via {{order.items}}, not thumbnails.
• Refund and partial refund events: The Order Created and Order Completed triggers fire on creation and completion. They do not fire when a refund is processed. You need a separate workflow on Order Status Changed, filtered to the “Refunded” status.
• Custom order meta fields: Fields added by third-party plugins, such as a custom delivery date picker, are not automatically available as merge tags. You need the HTTP Request action to fetch that data from the WooCommerce REST API if it matters for your alert.
• Two-way SMS replies: Krom Automation sends outbound SMS via Twilio. It does not currently listen for inbound replies. If a customer texts back, that goes to Twilio only and does not appear in Slack or Krom Automation’s execution log.
• Slack interactive buttons: The Slack action sends a standard text message. It does not support Block Kit buttons that trigger actions when clicked. For a “Mark as packed” button in Slack that updates WooCommerce, you would need the incoming webhook receiver plus a custom Slack app configuration.
• Order edits post-creation: If an admin edits the order total or changes the shipping address after the fact, the original alert is not updated. The Slack message and SMS reflect the order as it existed when the trigger fired.

Troubleshooting

Failure Mode 1: Slack Message Not Arriving

The most common cause is using the channel name instead of the channel ID in the Channel ID field. Slack’s API requires the ID format (C0123456789), not #orders or orders. The second most common cause is the bot not being invited to the channel.

In Slack, type /invite @YourBotName in the target channel. Without that invite, the bot has the scope to post but not the access to the specific channel.

Check the execution log in Krom Automation Execution History for the exact error code Slack returns. A channel_not_found error confirms the ID issue. A not_in_channel error confirms the invite issue.

Failure Mode 2: Twilio SMS Fails with a 21211 Error

Error 21211 from Twilio means the “To” number is not a valid phone number. This happens in two situations. First, the customer left the phone field blank in WooCommerce checkout, so {{order.billing_phone}} resolves to an empty string.

Second, the number is in a local format like 07911123456 rather than E.164 format like +447911123456. Twilio requires E.164 for all numbers, including the “From” field.

The fix for blank customer phones is a condition node before the Twilio action: check that {{order.billing_phone}} is not empty, and route the Yes path to the SMS action. The No path can post a note in Slack flagging the missing number.

Failure Mode 3: Alerts Arrive Late or Not at All Under Low Traffic

Krom Automation runs background execution via Action Scheduler, which depends on WP-Cron to fire. On a staging site or a low-traffic store where no page loads happen for hours at a time, WP-Cron fires late, and so does the workflow. The fix is a real server-side cron job that hits wp-cron.php every minute, replacing the default WordPress pseudo-cron.

Most managed WordPress hosts offer this in the control panel. If yours does not, a five-line crontab entry handles it. This affects all Action Scheduler-based plugins, not only Krom Automation.

A workflow that fires 40 minutes after an order lands is not an alert system. Cron on a low-traffic store needs a real server-cron job, not WordPress’s default pseudo-cron.

Cost Breakdown: Year 1 and Beyond

The question most teams do not ask until they get the invoice is what this actually costs across all the moving parts.

Component	Cost	Notes
Krom Automation Pro (Basic, 1 site, annual)	$119/year	Covers every Pro feature including all messaging actions
Krom Automation Pro (Standard, 5 sites, annual)	$199/year	Useful for agencies running client stores
Krom Automation Pro (lifetime, 1 site)	$299 once	Breaks even versus annual at 2.5 years
Slack	$0 for alerts	A free Slack workspace receives bot messages. No paid Slack plan required for this use case.
Twilio SMS (US domestic)	~$0.0079 per outbound SMS	At 500 orders per month, that is about $4/month. International rates vary significantly.
Twilio phone number	~$1/month	Per number, per month

At 500 orders per month, the Twilio cost for sending one SMS per order runs to roughly $5 per month. At 5,000 orders, that is $50 per month.

wpRigel does not charge per workflow execution or per action at any tier, so the Krom Automation cost stays flat regardless of volume. The only variable cost is what Twilio charges.

Going Further: Related Automations Worth Pairing

The Order Created and Order Completed triggers are the most obvious starting points, but WooCommerce stores typically need a handful of other alert and action workflows running alongside them. The WooCommerce Subscriptions integration adds triggers for subscription renewals, failures and cancellations, all of which are worth routing to Slack for your retention team.

If your store uses WPForms or Gravity Forms to collect pre-sale inquiries, those can feed into the same Slack channel using the WPForms integration or the Gravity Forms integration, so lead and order alerts live in one place without switching tools.

For stores preparing for high-volume periods, the post on preparing your WooCommerce store for Black Friday covers the automation stack specifically worth having in place before a traffic spike. The 20 WordPress automations most sites should have is a useful checklist for anything beyond order alerts.

Also from wpRigel

Pollify is our Gutenberg-native poll, survey and quiz plugin. Every poll is a real block inside the block editor, so there are no shortcodes to paste and no separate interface to configure. It fits naturally into product pages, post-purchase thank-you pages, or any content where you want audience input without leaving the editor.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K from anywhere in the admin, type what you need, and get there without clicking through menus. It is the only command palette with real WooCommerce depth: you can search orders by number or customer name, change order status, and update product prices directly from the palette.

Our Verdict

If your WooCommerce store processes more than 30 orders per day and your team relies on refreshing the admin dashboard to know what is coming in, a Slack plus SMS alert workflow is not a nice-to-have. It is a basic operational requirement. Setting it up with Krom Automation Pro takes under 20 minutes, carries no per-execution fees, and keeps every credential and execution log inside your own WordPress database rather than a third-party platform.

Who should not bother: stores doing fewer than 10 orders per day where the owner checks the dashboard regularly anyway. At that volume, the setup time exceeds the time saved for at least the first few months. Start with the free version on the WordPress.org plugin directory to get familiar with the workflow builder before committing to Pro.

Who should act now: any agency managing WooCommerce stores for clients, any store with an operations team split across time zones, and any store where an order that sits unacknowledged for 30 minutes causes a real problem. See the full pricing and plan options and pick the tier that matches your site count.

Frequently Asked Questions

Do I need Krom Automation Pro to send WooCommerce alerts to Slack and Twilio?

Yes. The WooCommerce triggers (Order Created, Order Completed) are available in the free version, but the Slack and Twilio SMS actions are Pro-only features. The free version supports 21 actions including HTTP Request, which is an alternative for advanced users comfortable building a custom webhook payload, but for a no-code setup you need Pro.

Can I send the SMS to the customer instead of my team?

Yes. In the Twilio action’s “To” field, use the merge tag {{order.billing_phone}} instead of a fixed number.

If the customer did not provide a phone number at checkout, the action fails. Add a condition node before the Twilio action to check that the phone field is not empty, and route orders without a phone number to a Slack flag instead.

What happens to my alerts if the Twilio API is down?

Krom Automation logs the failed execution and retries automatically with configurable backoff. You will also receive a failure notification by email.

The Slack action and the Twilio action are independent nodes, so a Twilio API outage does not prevent the Slack message from arriving. Your team still gets the order notification in Slack; only the SMS is delayed until the retry succeeds.

Is there a limit on how many workflows I can run per month?

No. Krom Automation does not impose per-execution limits or per-workflow caps at any plan tier.

Every plan, including the free version, runs unlimited executions. The only external usage costs are from Twilio, which charges per SMS sent at approximately $0.0079 per message for US domestic numbers.

Can I route different order values to different Slack channels?

Yes, using conditional branching. Add a condition node after the trigger and set the rule to Order Total greater than your threshold. The Yes path points to a high-value-orders Slack channel, the No path points to a standard-orders channel.

You can chain multiple conditions to create as many tiers as you need. Each branch is a separate Slack action node configured with a different Channel ID.