Good WordPress automation documentation is not a nice-to-have. It is the difference between a client who can operate a site independently and one who calls you every time a workflow stops firing. If you are handing over a site built on Krom Automation, this guide covers exactly what to capture, what to abstract for non-technical clients, and how to use the built-in notes field and export features as a documentation layer that travels with the site.

Most automation documentation fails because it describes what a workflow does, not why it exists or what happens when it stops. A client reading “Send Email on User Registered” learns nothing useful.

A client reading “Sends the welcome email with the login link. If this fails, new users see no confirmation and email support volume spikes” knows what to watch and when to panic.

The guide below is written for agency owners and developers handing off client sites. The same principles apply if you are building internal tooling and documenting for a team rather than a client.

Browse the full Krom Automation feature list to see what is available before you decide what needs documenting.

Why Automation Documentation Fails at Handover

The standard handover document covers credentials, hosting details, and plugin licences. It almost never covers the automation layer. That gap matters because automations are invisible when they work and catastrophic when they do not.

A silent automation failure on a WooCommerce site can mean hundreds of orders processed without fulfilment notifications. On a membership site it can mean new subscribers who never receive their access email.

Neither failure throws an error the client sees. They only surface when a customer complains, and by then the damage is done.

An undocumented automation is a liability that transfers with the site. The client inherits the risk but none of the context needed to manage it.

There are three failure modes that handover documentation must prevent:

• The trigger changes and nobody knows the workflow depended on it. A form is renamed or a post type is removed. The workflow still shows as active. Nothing fires.
• A plugin that a workflow depends on gets deactivated or updated. WooCommerce, a CRM plugin, or a forms plugin changes its hook structure. The workflow breaks silently.
• The client edits a workflow without understanding the downstream effects. They change a delay from 24 hours to 0 hours because they want emails faster. Three actions that depended on that delay window now fire simultaneously.

Good documentation does not prevent all of these. It makes each one diagnosable in under 10 minutes rather than 3 hours.

What to Document: The Non-Negotiable List

For each workflow on the site, capture the following. This is the minimum. Anything below this and the handover is incomplete.

1. Business purpose in one sentence. Not a technical description. What happens in the business if this workflow stops running?
2. Trigger: what fires it, and under what conditions. Name the exact trigger, any conditions on the trigger, and what the source is (a specific form, a specific post type, a specific user role).
3. Actions in sequence. List every action in order. Include delays as part of the sequence, not as an afterthought.
4. Dependencies. Which plugins must be active for this workflow to run? If the FluentCRM integration powers a contact tagging step, note that FluentCRM must stay active and at a minimum version.
5. Owner. Who is responsible for this workflow? Whose job breaks if it fails?
6. Last tested date and tester. A workflow that has never been tested in production is an assumption, not a fact.
7. Failure behaviour. What does the client see or not see when this fails? How do they check the execution log?

Seven fields per workflow. On a site with 12 active workflows, that is roughly 4 hours of documentation work.

A developer billing at $120/hour should charge for it, and most should. The alternative is a support ticket backlog that costs more.

Using the Krom Automation Notes Field

Krom Automation includes a notes field on every workflow, visible inside the workflow settings panel. This is not a hidden feature. It is the right place to store the business purpose and dependency information for each workflow, because it travels with the workflow when the site is handed over.

The notes field renders inside the canvas view. A client or future developer opening a workflow sees the note before they see anything else. That means documentation that lives in a separate Google Doc or Notion page, where nobody will look, becomes documentation that is impossible to miss.

The workflow settings documentation covers the notes field alongside the run-once setting, pause controls, and import/export. Read that before you build your first client workflow so the notes habit is built in from the start, not retrofitted at handover.

Our recommended note format for each workflow:

• Purpose: [one sentence business reason]
• Trigger source: [form name, post type, or event]
• Depends on: [plugin names and minimum versions]
• Owner: [name or role]
• Last tested: [date]

Paste this as plain text into the notes field on every workflow before you hand over. It takes 3 minutes per workflow and eliminates the most common support call: “We changed something and now the emails stopped. Can you look at it?”

Export as Portable Documentation

Krom Automation supports workflow export as JSON. Each exported file contains the complete workflow structure: trigger configuration, all actions, delays, conditions, merge tags, and settings. The notes field travels with the export.

For a client handover, export every active workflow and include the JSON files in the handover package alongside credentials and hosting details. This gives you three things:

• A point-in-time snapshot of every workflow as it was at handover
• A restore path if a workflow is accidentally deleted or corrupted
• A portable copy that can be imported to a staging or development environment for testing

The JSON export is also your migration safety net if the client ever moves hosts. Importing 12 workflows from JSON takes under 10 minutes. Rebuilding 12 workflows from memory takes a day.

The export file is the closest thing to version control that most WordPress automation setups will ever have. Treat it like a build artefact, not an afterthought.

Store the exports in the same place as the site backup. If the client uses a project management tool, attach the JSON files to the project closeout ticket so they are searchable later.

What to Abstract for Non-Technical Clients

Not every client needs to understand conditional branching or merge tags. Most need to understand three things: what the workflow does, what it costs them if it stops, and how to tell if it has stopped.

Build a separate one-page summary for the client. This is distinct from the technical documentation above, which is for the next developer. The client summary covers:

• Workflow name (match the name in Krom Automation exactly, so they can find it)
• What it does in plain English (two sentences maximum)
• How often it should run (on every order, daily, on new user registration)
• How to check if it is running (point them to the execution log in the analytics dashboard)
• Who to call if it stops (your support contact or their internal team)

The analytics dashboard in Krom Automation shows total executions, success rate, failed execution count, and an execution trend chart. A client who checks this once a week will catch a silent failure within 7 days. A client who has never been shown the dashboard will call you 6 weeks later wondering why conversion rates dropped.

Documenting Integrations Separately

Integrations deserve their own section in the handover document because they carry external dependencies the client controls, and those dependencies can change without warning.

For each external integration in use, document:

• Which service it connects to (Mailchimp, FluentCRM, Google Sheets, Slack)
• What credential or API key is stored in WordPress
• Who owns that credential (the agency or the client)
• What happens to the workflow if the API key is revoked or the account is closed
• Where to regenerate the credential if needed

If the site sends data to Google Sheets or Google Calendar, note which Google account owns the connection and what happens if that account loses access. If the site posts to social media via the social media integration, note the connected page, the connected account, and the token expiry behaviour.

Messaging integrations to Slack, Discord, Twilio or Telegram are particularly fragile at handover because they use workspace-level credentials the client may rotate during an internal IT change. A single paragraph in the handover document explaining this saves a support call.

For form-triggered workflows, link the integration doc so the next developer can verify the setup. For example, a workflow triggered by Gravity Forms or WPForms will break if the form is renamed or the field mapping changes. That is worth one sentence in the handover notes.

The Handover Documentation Structure

A complete handover documentation package for a site running Krom Automation has four parts. The table below shows who reads each part and what they do with it.

Document	Audience	Format	Lives Where
Workflow notes (per workflow)	Next developer	Plain text in Krom Automation notes field	Inside the plugin, travels with export
Technical handover document	Next developer or internal team	Markdown or PDF	Project folder, handover package
Client summary (one page)	Client or site owner	PDF or shared doc	Client’s preferred tool (Notion, Google Drive, email)
Workflow JSON exports	Next developer, disaster recovery	JSON files	Site backup folder, project archive

The technical handover document should list every active workflow, its dependencies, the credential owner for each integration, and the support contact. It does not need to explain how Krom Automation works. It needs to explain how this specific site’s workflows work.

Cost of Getting This Wrong

Skipping automation documentation is a pricing decision, even if it does not feel like one. The cost lands somewhere. The question is whether it lands on your support hours or on the client’s operations.

Scenario	Without documentation	With documentation
Workflow breaks 3 months post-handover	2 to 4 hours to diagnose without context. $240 to $480 in unbilled support at $120/hr	Client checks execution log, finds the failed step, calls you with the error. 30 minutes to fix
Client changes a plugin and breaks an integration	Root cause unclear. Developer rebuilds from memory. 3 to 6 hours	Dependency listed in notes. Developer restores from JSON export. Under 1 hour
New developer takes over the site	Discovery audit needed. 4 to 8 hours billed to client	Technical handover document covers it. 1 hour onboarding
API key rotated, integration breaks	Unknown which workflows are affected. Full audit required	Integration doc lists credential owner and regeneration steps. Fixed in 20 minutes

Across an agency running 20 client sites with automation, the difference between documented and undocumented handovers is realistically 40 to 80 support hours per year. At $120/hour, that is $4,800 to $9,600 in unrecoverable time.

Charging $300 to $500 per site for a documentation package at handover is not overhead. It is margin recovery.

Charging for handover documentation is not adding a line item. It is pricing the risk correctly instead of absorbing it silently in your support queue.

Testing Before You Hand Over

Documentation of an untested workflow is documentation of an assumption. Before any handover, run every workflow through the simulator.

Krom Automation includes a workflow simulator for dry-run testing with zero side effects. It runs the workflow logic without sending emails, creating posts, or firing HTTP requests. Use it to verify that every branch executes as expected and that merge tags resolve correctly.

For workflows that cannot be fully validated by simulation, such as those that depend on a live payment gateway or a production form submission, document the test procedure in the handover notes. Describe the exact steps, the expected output, and how to check the execution log to confirm it ran. The client or next developer should be able to run the test themselves in under 15 minutes.

If a workflow has never been tested in production, say so in the handover document. An honest note that says “validated in staging but not confirmed in production” is more useful than silence. It tells the next person where to start.

Multi-Site and Agency Considerations

If you are managing automation across multiple client sites, the documentation burden multiplies quickly. The answer is not to document less. It is to standardise the documentation format so each site takes less time.

We cover the broader strategy for WordPress automation across multiple client sites in a separate guide, including how to build reusable workflow templates and what to centralise versus what to configure per site. The short version: standardise the workflow structure, standardise the notes format, and export templates from your reference build rather than rebuilding from scratch for each client.

Krom Automation’s import/export system is designed for exactly this. Build a workflow on one site, export the JSON, and import it to a new client site in under 2 minutes. The notes field travels with the import, which means your documentation template travels too.

For agencies evaluating the cost model across client sites, the per-site cost analysis we published covers what automation tooling actually costs at 1, 5, 10 and 20 sites, including licence costs, time costs, and the break-even point between free and Pro tiers.

Also from wpRigel

Pollify is wpRigel’s Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the block editor, so there are no shortcodes to paste and no separate interface to learn. It pairs naturally with automation workflows that trigger on user responses.

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 developers managing client sites, it is the fastest way to navigate without knowing every menu path. It is the only command palette with real WooCommerce order, product and customer commands built in.

Our Verdict

If you are handing over a WordPress site with active automations and you have not written workflow notes, exported the JSON files, and produced a one-page client summary, the handover is not complete. It will cost you or your client time within 6 months.

That is not a prediction. It is the pattern we see repeatedly across agency builds.

The tools to do this correctly are built into Krom Automation: the notes field, the JSON export, the execution log, the analytics dashboard, and the workflow simulator. None of them require extra setup. They require the habit of using them before you hand over, not after the first support ticket arrives.

Who should invest in this now: any agency handing over more than 3 client sites per quarter, and any developer who has ever spent a Saturday debugging an automation they built 8 months ago and cannot remember. Who can wait: teams where all automation is internal, the codebase is under version control, and the same developer maintains it indefinitely.

The free version of Krom Automation is available on the WordPress.org plugin directory with no trial period and no feature caps. If you are evaluating it for client work, start there and review the free vs Pro comparison before you decide whether the Pro integrations are worth it for your stack.

See the full Krom Automation pricing and plan details to find the right licence for your site count.

Frequently Asked Questions

Where does automation documentation live in Krom Automation?

Each workflow has a notes field inside the workflow settings panel. Text entered there travels with the workflow when exported as JSON, making it the most reliable place for handover documentation. It is visible to any developer who opens the workflow on the destination site.

What happens to workflows if a dependent plugin is deactivated?

The workflow remains active in Krom Automation but the affected triggers or actions will fail to execute. The failure is logged in the execution history with a per-step audit trail, which is how you diagnose it. Documenting plugin dependencies at handover is what makes this diagnosable in minutes rather than hours.

Can I export all workflows at once for a client handover package?

Krom Automation exports workflows individually as JSON files. For a full site handover, export each active workflow separately and bundle the files in the handover package. Each file is self-contained and can be imported to a new or staging environment without any additional configuration.

How does the workflow simulator help with handover testing?

The simulator runs the full workflow logic without executing any real actions, so you can verify trigger conditions, branch logic, and merge tag resolution without sending emails or modifying data. It is the right tool for pre-handover validation and for testing changes on a live site without side effects.

Is Pro required to use the notes field and JSON export?

No. Both the workflow notes field and JSON import/export are included in the free version of Krom Automation. You do not need a Pro licence to document and export workflows as part of a client handover.

You can connect WooCommerce to Mailchimp without Zapier using Krom Automation, a native WordPress plugin. The free version handles basic subscriber sync. The Pro version adds the Mailchimp action that subscribes contacts, applies tags, and updates audience fields directly from any WooCommerce trigger, at no per-task cost.

The official Mailchimp plugin for WooCommerce handles audience sync reasonably well, but it gives you a fixed pipeline. You cannot add conditional logic, delay the subscription, branch based on order value, or chain Mailchimp into a wider workflow. Krom Automation treats Mailchimp as one action inside a workflow you control, which means you can subscribe a customer, send an internal Slack alert, and update a Google Sheet in the same automation without touching Zapier.

This guide follows the integration post structure: what syncs, how to set it up step by step, what does not transfer, the three real failure modes, and a verdict on when this approach makes sense versus the official plugin.

Browse the full Krom Automation feature list to see what else you can connect alongside Mailchimp.

What Gets Synced: WooCommerce to Mailchimp

The table below shows every data point the Krom Automation Mailchimp integration can pass from WooCommerce to Mailchimp, and exactly where it lands in your audience. Fields not listed here do not transfer automatically and require a custom HTTP Request action or a separate workflow step.

WooCommerce Field	Where It Lands in Mailchimp
Customer email address	Audience contact email (primary identifier)
First name	FNAME merge field
Last name	LNAME merge field
Order total	Custom merge field (mapped manually in workflow)
Order status	Tag applied to contact (e.g., “order-completed”)
Product name(s)	Tag or custom merge field (one per workflow action)
Billing country	Custom merge field or audience segment data
Opt-in status at checkout	Subscribed vs. non-subscribed contact status
Workflow-assigned tag	Tag on Mailchimp contact, set per workflow branch

Order line items beyond the first product require a loop or separate action per product. There is no native array-to-tag bulk operation. If your store sells bundles with 8 to 12 line items and you need every product tagged individually, plan for that complexity before you build the workflow.

Requirements Before You Start

• WordPress 6.2 or higher
• PHP 7.4 or higher
• WooCommerce installed and active
• Krom Automation free plugin active (handles the WooCommerce triggers)
• Krom Automation Pro active (required for the Mailchimp subscribe action)
• A Mailchimp account with at least one audience created
• A Mailchimp API key with read/write access

The free Krom Automation plugin gives you the Order Created and Order Completed WooCommerce triggers at no cost. The Mailchimp action itself is a Pro integration.

See the full free vs. Pro comparison if you want to check which other actions require the Pro licence before committing.

Step-by-Step Setup

Step 1: Install and Activate Krom Automation

Go to Plugins > Add New Plugin in your WordPress admin. Search for “Krom Automation” and install the plugin listed by wpRigel. Activate it.

A new Krom Automation menu item will appear in your left admin sidebar. If you have the Pro licence, upload the Pro zip at Plugins > Add New Plugin > Upload Plugin and activate it alongside the free plugin. The Pro installation guide covers licence key activation and what to do if the Pro features do not appear after activation.

Step 2: Connect Your Mailchimp Account

Go to Krom Automation > Settings > Integrations. Find the Mailchimp card and click Connect. You will be prompted for your Mailchimp API key.

Paste it into the API Key field and click Save. Krom Automation will verify the key and display your account name if the connection succeeds. If you see a “401 Unauthorized” error, the key does not have the required audience read/write scope, generate a new one from your Mailchimp account under Account > Extras > API Keys.

Step 3: Create a New Workflow

Go to Krom Automation > Workflows > Add New. This opens the visual workflow builder canvas. Click the Add Trigger node at the top of the canvas.

From the trigger panel on the right, select the WooCommerce category, then choose Order Completed as your trigger. If you want to subscribe customers the moment they place an order rather than after payment clears, choose Order Created instead. The difference matters for refund handling, which we cover in the limitations section below.

Step 4: Add the Mailchimp Subscribe Action

Click the plus icon below your trigger node to add an action. Select the Mailchimp category from the action panel.

Choose Subscribe Contact. The action card will show the following fields, all of which are required unless marked optional:

• Audience: select your Mailchimp audience from the dropdown (populated automatically from your connected account)
• Email Address: use the merge tag {{order.billing_email}}
• First Name: use {{order.billing_first_name}}
• Last Name: use {{order.billing_last_name}}
• Status: set to Subscribed if opt-in was captured, or Pending to trigger Mailchimp’s double opt-in email
• Tags (optional): enter a static tag such as “woo-customer” or use a merge tag to apply a dynamic value

The merge tags documentation lists every available WooCommerce order variable you can inject into action fields, including order total, product names, and billing address components.

Step 5: Add Conditional Branching (Recommended)

If you only want to subscribe customers who opted in at checkout, add a Condition node between the trigger and the Mailchimp action. Click the branch icon on the trigger node. Set the condition to: Order > Customer opt-in > equals > true.

Connect the Yes path to the Mailchimp subscribe action. Leave the No path empty or route it to a different action.

This single step prevents you from adding non-consenting contacts to your audience, which matters for GDPR compliance and Mailchimp’s own terms of service. The conditions and branching documentation covers every available operator and how to stack multiple conditions in a single node.

Step 6: Test with the Workflow Simulator

Before setting the workflow live, click Simulate in the top toolbar. The simulator runs every node against a sample payload with zero side effects: no real Mailchimp contact is created, no email is sent.

You can verify that your merge tags resolve correctly and that the conditional branch routes as expected. Fix any errors the simulator flags, then click Activate to set the workflow live.

A workflow that looks correct in the builder and fails silently on real orders is the most expensive kind of mistake. Run the simulator before you activate, not after you notice missing subscribers.

What Does NOT Transfer: Honest Limitations

Most integration guides skip this section. We will not, because this is where stores waste hours debugging something that was never going to work.

• Historical orders: Krom Automation is event-driven. It fires when something happens from the moment the workflow is active. Customers who ordered before you activated the workflow are not synced retroactively. If you need to backfill 3,000 existing customers, export them from WooCommerce as CSV and import directly into Mailchimp.
• Automatic unsubscribes on refund or cancellation: The free WooCommerce triggers include Order Created and Order Completed, but not a dedicated “Order Refunded” trigger in the free tier. You can handle this in Pro with a Post Status Changed trigger on the shop_order post type, but it requires an additional workflow. Do not assume a cancelled order removes the contact from Mailchimp automatically.
• Mailchimp e-commerce data (purchase history, revenue): The Mailchimp subscribe action adds and updates contacts. It does not write to Mailchimp’s e-commerce data layer (orders, products, revenue), which the official Mailchimp plugin populates via a separate API. If you rely on Mailchimp’s purchase-based segments or revenue reporting, you need the official plugin running alongside Krom Automation, or you need to write to Mailchimp’s Orders API via the HTTP Request action.
• Abandoned cart: Krom Automation does not currently fire a trigger on cart abandonment. Abandoned cart emails require the official Mailchimp plugin or a dedicated WooCommerce abandoned cart plugin that exposes a hook Krom can listen to.
• Checkout Block opt-in checkbox: The native WooCommerce Checkout Block does not expose a Mailchimp opt-in checkbox in the same way the classic checkout does. If your store uses the Checkout Block, test the opt-in field rendering before going live. The Mailchimp official plugin has better handling of the Checkout Block opt-in at present.

For stores that need WooCommerce Subscriptions events such as subscription created, cancelled, or renewed, the WooCommerce Subscriptions integration documentation covers the additional triggers available in Pro and how to chain them into Mailchimp or any other email platform.

The official Mailchimp plugin and Krom Automation are not rivals here. For stores that need Mailchimp’s e-commerce data layer populated, running both is the honest answer.

Troubleshooting: The Three Real Failure Modes

Failure 1: Customers Appear as “Non-Subscribed” Instead of “Subscribed”

This is the most common complaint. The cause is almost always one of two things. First, the Status field in your Mailchimp subscribe action is set to Pending, which means Mailchimp sends a confirmation email and the contact stays non-subscribed until they click.

If you captured consent at checkout and want immediate subscription, change the Status field to Subscribed. Second, Mailchimp’s own audience settings may have double opt-in forced on at the audience level. Check under Audience > Settings > Audience name and defaults in Mailchimp and disable double opt-in if you want single opt-in behaviour from the API.

Failure 2: Workflow Fires but No Contact Appears in Mailchimp

Open Krom Automation > Execution Logs. Find the execution for the order in question and expand the Mailchimp action step. The log will show either a success response or the exact error Mailchimp returned.

The two most common errors are “Invalid API Key” (the key was regenerated in Mailchimp after you connected) and “Audience not found” (the audience ID stored in the action no longer matches your Mailchimp account). For the API key issue, go to Krom Automation > Settings > Integrations > Mailchimp and reconnect. For the audience mismatch, open the workflow, click the Mailchimp action node, and reselect the audience from the dropdown.

The per-step audit trail in the execution log is the fastest path to the actual error. If you have had silent failures before and want to understand why they are hard to catch, this post on silent automation failures covers the structural reasons and how to set up failure notifications.

Failure 3: Duplicate Contacts or Duplicate Emails

Duplicate contacts in Mailchimp usually mean the workflow is firing more than once per order. This happens when both Order Created and Order Completed triggers are active in separate workflows pointing to the same Mailchimp subscribe action. Decide which event is the correct subscription point and disable the other workflow.

Duplicate transactional emails (the customer receiving two order confirmation emails) are a separate issue caused by WooCommerce’s own emails and a Krom Automation send email action both firing. If Krom Automation handles your order email, disable the equivalent email under WooCommerce > Settings > Emails. Enable Run Once Per Entity in the workflow settings to prevent the same order ID from triggering the same workflow twice, regardless of how many times the order status changes.

Official Plugin vs. Krom Automation: Which Setup Fits Your Store

The right choice depends on what you are trying to accomplish. This table answers the decision rather than listing features side by side.

Your Situation	Better Fit	Why
You need Mailchimp’s purchase history, revenue data, and e-commerce segments	Official Mailchimp plugin	Writes to Mailchimp’s e-commerce API layer; Krom does not
You want abandoned cart emails through Mailchimp	Official Mailchimp plugin	Has built-in cart abandonment tracking
You want to subscribe customers AND post to Slack, update a Sheet, and tag in a CRM in one workflow	Krom Automation Pro	Mailchimp is one action in a multi-step workflow; official plugin is Mailchimp only
You need conditional logic (only subscribe if order total exceeds $100)	Krom Automation Pro	Visual conditional branching; official plugin has no equivalent
You want to avoid per-task fees from Zapier at scale	Krom Automation Pro	Flat annual fee, no execution caps, self-hosted
You run 10+ WooCommerce client sites and need one licence	Krom Automation Pro Enterprise	Unlimited sites for $369/year or $799 lifetime
You use the WooCommerce Checkout Block and need opt-in checkbox support	Official Mailchimp plugin (currently)	Better Checkout Block integration at this time

For stores that need both the e-commerce data layer AND multi-step workflow logic, running the official plugin and Krom Automation together is a workable combination. The official plugin handles the Mailchimp-specific data sync.

Krom handles everything else. They do not conflict.

Scaling Considerations for High-Volume Stores

Krom Automation executes workflows via Action Scheduler, which means no workflow runs during a page load. At 500 to 1,000 orders per day, the queue processes in the background without affecting frontend performance.

The execution log stores a per-step audit trail in 9 custom database tables, so log size grows with volume. For stores processing more than 2,000 orders per day, review your log retention settings under Krom Automation > Settings > Logs and set a retention window (30 or 60 days) to prevent table bloat.

The Mailchimp API enforces a rate limit of 10 concurrent connections. On very high volume days (Black Friday, for example), queued workflows may take 20 to 40 minutes to fully process if order volume spikes above normal. Contacts will be subscribed, just with a delay.

If same-day subscription timing is critical for a campaign, test your queue throughput before the event. Our Black Friday WooCommerce prep guide covers queue and performance considerations in more detail.

Going Further: Related Integrations

If Mailchimp is not the right fit for your store, Krom Automation connects to several other email platforms using the same workflow structure. The setup pattern is identical: pick your WooCommerce trigger, add the platform action, map your merge tags, add a condition if needed. Detailed documentation is available for ConvertKit, MailerLite, ActiveCampaign, and FluentCRM.

For form-based subscription workflows, where a Gravity Forms or WPForms submission triggers the Mailchimp subscribe action rather than a WooCommerce order, see the Gravity Forms integration documentation and the WPForms integration documentation. The merge tag structure differs slightly from the WooCommerce fields shown above, but the Mailchimp action configuration is identical.

Every hour you spend configuring Zapier tasks for a WooCommerce-to-Mailchimp connection is an hour you are paying for infrastructure that lives outside your site, outside your control, and on a billing meter that grows with your order volume.

Also from wpRigel

Pollify is our Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the editor, so there are no shortcodes to paste and no separate configuration interface to learn. It is a natural complement to a WooCommerce store running post-purchase surveys or NPS feedback collection.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere, search anything, and run admin actions without clicking through menus. It is the only command palette plugin with genuine WooCommerce depth: search orders by number, customer name or email, change order status, update product prices and stock, and manage customers, all without leaving the keyboard.

Our Verdict

Use Krom Automation for this integration if you need Mailchimp as part of a wider workflow, want to avoid Zapier’s per-task billing, or manage multiple WooCommerce sites under one licence. The Pro Enterprise plan at $369 per year covers unlimited sites, which works out to under $37 per site across a 10-site agency portfolio. That compares well against Zapier’s Growth plan at $299 per month for 2,000 tasks, which a mid-size WooCommerce store can exhaust in a week during a promotion.

Do not use Krom Automation as your sole Mailchimp connection if Mailchimp’s e-commerce segments, purchase-based automations, or revenue reporting are central to your marketing strategy. Those depend on Mailchimp’s e-commerce data layer, which requires the official plugin.

For stores where abandoned cart is the primary use case, the official Mailchimp plugin remains the simpler path. The honest answer is that these two tools solve different parts of the problem, and for many stores, both running together is the right call.

Download the free Krom Automation plugin from the WordPress.org plugin directory to get the WooCommerce triggers active, then see the Pro pricing when you are ready to add the Mailchimp action.

Frequently Asked Questions

Does WooCommerce integrate with Mailchimp natively, or do I need a plugin?

You need a plugin. WooCommerce has no built-in Mailchimp connection.

The two main options are the official Mailchimp for WooCommerce plugin (free, handles the e-commerce data layer) and Krom Automation Pro (paid, handles Mailchimp as part of a multi-step workflow). For most stores, the choice depends on whether you need Mailchimp’s purchase-based segments or whether you need Mailchimp connected alongside other tools in the same automation.

Why are my customers showing up as non-subscribed contacts in Mailchimp?

The two most common causes are: the Status field in the Mailchimp action is set to “Pending” instead of “Subscribed”, which triggers Mailchimp’s double opt-in flow before the contact activates; or double opt-in is forced on at the audience level in Mailchimp under Audience > Settings > Audience name and defaults. Change the Status field to “Subscribed” and disable audience-level double opt-in if you want immediate subscription without a confirmation email.

Can I send abandoned cart emails through this setup?

Not with Krom Automation alone. Krom Automation fires on WordPress and WooCommerce events, and abandoned cart is not a WooCommerce event in the standard sense as no order is created.

You need a dedicated abandoned cart plugin that captures the incomplete session and fires a hook, or you use the official Mailchimp plugin, which has built-in cart tracking. Krom Automation can handle everything that happens after an order exists.

How do I stop WooCommerce and my Mailchimp workflow from sending duplicate order emails?

If Krom Automation is sending a custom order confirmation email, disable the equivalent WooCommerce default email under WooCommerce > Settings > Emails. Find the email type (e.g., “Processing Order”), click Manage, and set it to disabled. The two systems will otherwise both fire independently for the same order event, and the customer receives two identical emails within seconds of each other.

What does this cost compared to running the same workflow through Zapier?

Krom Automation Pro starts at $119 per year for one site with no execution caps. Zapier’s Starter plan is $29.99 per month ($359.88 per year) with a 750-task cap per month. A WooCommerce store completing 100 orders per month and running 3 Zap steps per order uses 300 tasks monthly, leaving 450 in the buffer.

At 250 orders per month with 3 steps, you exceed the Starter cap and move to the Professional plan at $73.50 per month ($882 per year). Krom Automation’s cost does not change regardless of order volume.

Does this integration work with WooCommerce Subscriptions?

Yes, through Krom Automation Pro. The WooCommerce Subscriptions integration adds triggers for subscription created, cancelled, expired, and renewed.

You can subscribe a customer to a Mailchimp audience on initial sign-up and apply a different tag on renewal or cancellation, all in separate workflows. See the WooCommerce Subscriptions integration documentation for the full trigger list and setup steps.

You can connect WordPress to Zapier using the official Zapier for WordPress plugin, and the free Zapier plan works for basic testing. For anything beyond a handful of Zaps, you will hit task limits quickly, and for WordPress-native automation, Krom Automation handles the same workflows without per-task billing or a third-party dependency.

This guide covers both paths honestly. The Zapier integration is the right answer when you need to connect WordPress to an external service that has no native WordPress plugin. A self-hosted automation plugin is the right answer when the trigger and the action both live inside WordPress, because routing that traffic through Zapier’s servers adds latency, cost and a failure point you do not need.

We will walk through the exact setup steps for both, show you what each handles well, and be direct about where each one breaks down. If you are running this decision for a client site or an agency stack, the cost section will matter more than the setup section.

Browse the full feature list for Krom Automation if you want to see the native option before reading the setup steps.

What the Zapier WordPress Integration Actually Connects

The Zapier for WordPress plugin creates a two-way bridge. WordPress can act as a trigger source, firing a Zap when something happens on your site. It can also act as an action target, receiving data from Zapier and creating or updating content inside WordPress.

The plugin authenticates using WordPress application passwords, introduced in WordPress 5.6. You generate a password inside your user profile and paste it into Zapier during the connection flow. No OAuth app, no custom API keys, no coding required.

WordPress events you can use as Zapier triggers:

• New post published (any post type, filterable by category or tag)
• New user registered
• New comment posted
• Post updated (fires on any save, including autosave in some configurations)
• WooCommerce order created or completed (requires WooCommerce installed)

What Zapier can do inside WordPress as an action target:

• Create a new post or page with title, content, status and category
• Update an existing post by ID
• Create a new user with role, email and username
• Create a WooCommerce product or update an existing one

What Gets Synced: Field-Level Reference

WordPress field or event	Where it lands in Zapier
Post title	post_title key in the trigger payload
Post content (raw HTML)	post_content key, unsanitised
Post author ID	post_author key as an integer
Post status at trigger time	post_status key (publish, draft, etc.)
Post permalink	guid key in most configurations
User email on registration	user_email key
User display name	display_name key
User role at registration	roles key as a comma-separated string
Comment author name	comment_author key
Comment content	comment_content key
Comment status	comment_approved key (0, 1, or spam)
WooCommerce order total	total key as a string with currency symbol
WooCommerce order status	status key (processing, completed, etc.)
WooCommerce customer email	billing.email nested key
Custom post meta fields	Not included by default; requires custom code or a Pro Zap filter
User meta fields	Not included by default; requires a separate HTTP Request Zap step

The two rows at the bottom are where most Zapier setups run into trouble. Custom post meta and user meta do not appear in the default trigger payload. Pulling them requires a second Zap step that calls the WordPress REST API directly, which consumes an additional task per execution and adds conditional logic complexity.

Step-by-Step: Connecting WordPress to Zapier

Step 1: Install the plugin

Go to Plugins Add New inside your WordPress admin. Search for “Zapier for WordPress” and install the plugin listed as published by Zapier Inc.

Activate it. No settings page appears after activation because the plugin works entirely through the REST API and application passwords.

Step 2: Create an application password

Go to Users Profile for an administrator account. Scroll to the Application Passwords section near the bottom. In the “New Application Password Name” field, type something identifiable like “Zapier Integration 2026”.

Click Add New Application Password. Copy the generated password immediately. WordPress will not show it again.

The account you use here sets the permission scope for every Zap. Use a dedicated administrator account rather than your personal one, so you can revoke access cleanly if the integration is ever compromised.

Step 3: Authenticate in Zapier

Inside Zapier, create a new Zap and search for “WordPress” as the app. Choose your trigger or action and click Sign In. Zapier asks for three fields: your WordPress site URL (with https://), your WordPress username, and the application password you just generated.

Zapier will test the connection by hitting your site’s REST API. A green “Connection Successful” message confirms the link is live.

Step 4: Build your trigger

Select the WordPress event. Zapier will ask you to load sample data by fetching real recent records from your site. This step is required before you can map fields to the action.

If your site has no recent posts, users or orders, Zapier cannot load samples and the builder stalls. Create a test record in WordPress, then return to Zapier and click Load More.

Step 5: Configure the action and map fields

Choose the destination app and the action. Map WordPress trigger fields to the destination fields using Zapier’s dropdown interface.

Every mapped field counts as data that travels through Zapier’s servers. Turn on the Zap and run a live test with a real WordPress event to confirm the payload arrives correctly.

The Zapier connection takes about 15 minutes to configure. The cost of that connection compounds every month at scale, and most sites discover that cost only after the bill arrives.

Zapier Pricing: What WordPress Sites Actually Pay

The free Zapier plan allows 100 tasks per month across 5 Zaps. One task equals one action step in one Zap execution.

A Zap with two action steps consumes two tasks per trigger firing. Our detailed breakdown is in the Zapier pricing 2026 guide, but the headline numbers are these:

Scenario	Tasks per month	Zapier plan needed	Annual cost (approx)
New post published, notify Slack	30 to 50	Free	$0
Form submission to Google Sheets + email	200 to 600	Starter ($29.99/mo)	~$360
WooCommerce orders to CRM + Slack + email	600 to 2,000+	Professional ($73.50/mo)	~$882
Agency: 10 client sites, 3 Zaps each	3,000 to 10,000+	Team ($103.50/mo+)	~$1,242+

That last row is what stings agencies. Every client site runs independently, but all tasks pool into one Zapier account. A busy month on one site can push you into the next billing tier for all clients simultaneously.

If your automations stay inside WordPress, paying per task for that traffic makes no sense. A user registers, gets a welcome email, and has their role set.

Those three things touch only your WordPress database. Routing them through Zapier’s servers costs money and adds an external dependency for something your own server can handle in under a second.

The Native Alternative: Krom Automation

Krom Automation is a visual workflow automation plugin that runs entirely on your WordPress server. It connects WordPress events to automated actions using a drag-and-drop canvas, with no per-task fees and no third-party account required. The free version includes 16 triggers and 21 actions covering users, posts, comments, media and WooCommerce.

For WordPress-to-WordPress automations, the workflow is: choose a trigger, drag an action node onto the canvas, map your fields using merge tags, and activate. Execution logs are stored in your own database, and the analytics dashboard shows success rate per workflow so a failing workflow does not hide behind aggregate numbers. That matters because a workflow failing silently on WordPress looks identical to a working one until you check the per-step audit trail.

The Krom Automation documentation walks through triggers, actions and workflows if you want to understand the data model before installing.

Side-by-side: Zapier vs Krom Automation for WordPress

Dimension	Zapier + WordPress plugin	Krom Automation
Where automations run	Zapier’s servers (external)	Your WordPress server (self-hosted)
Cost model	Per task, per month	Flat annual or lifetime licence
Free tier limits	100 tasks/month, 5 Zaps	No task limits, no run caps
Custom post meta access	Extra Zap step required	Native via merge tags
Execution logs	30-day history on paid plans	Full per-step audit trail, your database
WooCommerce triggers (free)	Order Created, Order Completed	Order Created, Order Completed
WooCommerce depth (Pro)	Depends on WooCommerce Zapier add-on	Native Pro triggers and actions included
External service connections	6,000+ app integrations	24 Pro integrations (WordPress-native focus)
Data leaves your server	Yes, every execution	No
AI actions	Via OpenAI Zapier app (tasks consumed)	Built in free, bring your own API key

The external service count is where Zapier wins outright. If you need WordPress to talk to a service that has no native WordPress plugin, Zapier is often the fastest path. If everything you are automating lives inside WordPress, paying for that reach is waste.

Every task that touches only your own database should not be paying rent to a third-party server. That cost is invisible in month one and painful by month twelve.

Running Both: The Practical Agency Stack

The cleanest setup for most agencies is not either-or. Use Krom Automation for all WordPress-native workflows and reserve Zapier for the connections that genuinely need it. This keeps task counts low, which keeps Zapier on a cheaper plan, while giving you full native automation inside WordPress.

Krom Automation Pro adds an incoming webhook receiver with a unique secret URL per workflow and HMAC-SHA256 signature verification. That receiver can accept payloads from Zapier, Make, or any external service. So you can run a Zap that collects data from an external app and fires a webhook at WordPress, and Krom Automation handles everything that happens next.

The external-to-WordPress handoff costs one Zapier task. Everything after that is free.

For agencies managing multiple sites, Krom Automation’s Enterprise plan covers unlimited sites for $369 per year. That is a flat cost regardless of how many client workflows run across how many sites.

The equivalent Zapier spend at 3,000 tasks per month is roughly $882 per year, before you factor in additional app connections or team seats. The detailed agency cost comparison lives in what client automation costs per site.

Connecting Specific Plugins to Zapier, and the Native Alternative

Most guides cover WordPress and Zapier generically. The real questions are about specific plugins. Here is where the native approach typically wins:

Form plugins: If your form submissions need to reach Google Sheets or a CRM, Zapier works but consumes tasks for every submission. Krom Automation has native integrations for Gravity Forms, WPForms, Contact Form 7, Fluent Forms, and Elementor Forms. A form submission triggers the workflow directly in WordPress, with zero external API calls for the trigger step.

Email marketing: For syncing WordPress users or form entries to Mailchimp, ConvertKit or ActiveCampaign, native integrations handle subscribe, tag and list management without routing through Zapier. The Mailchimp integration, ActiveCampaign integration, and FluentCRM integration all cover this natively.

WooCommerce: The Zapier for WordPress plugin covers basic order triggers. For deeper WooCommerce work, including subscription events, the WooCommerce Subscriptions integration in Krom Automation Pro handles subscription lifecycle events that the standard Zapier plugin does not expose at all.

Membership and LMS: MemberPress, LearnDash and MemberPress have no meaningful Zapier triggers beyond basic webhook workarounds. Krom Automation Pro includes dedicated trigger sets for MemberPress and LearnDash covering signup, expiry, course completion and quiz events.

What Does Not Transfer and What Breaks

This is the section most guides skip. Read it before you build.

Custom post meta does not appear in the default trigger payload. If you are automating custom post types with ACF or Meta Box fields, Zapier only sends the standard WordPress post fields. You will need a separate Zap step using the HTTP Request action to call the WordPress REST API for the meta, which adds cost and failure surface.

Polling delay means Zapier is not real-time. Most WordPress triggers in Zapier use polling rather than webhooks, checking for new data every 1 to 15 minutes depending on your plan. A user who registers and expects an instant response may wait up to 15 minutes for a Zap to fire. Krom Automation executes via Action Scheduler, which fires within seconds of the trigger event on a normally trafficked site.

Zap history is capped and then deleted. Zapier keeps 30 days of task history on paid plans and 7 days on free. If an automation fails and you do not notice within that window, the evidence is gone. Krom Automation stores every execution log in your own database with no automatic expiry.

Multi-step Zaps multiply task cost. A Zap that checks a condition, sends an email, and updates a CRM record consumes 3 tasks per trigger firing. On a site with 500 form submissions per month, that Zap alone costs 1,500 tasks, which is above the Starter plan’s 750-task limit.

Application password revocation is site-level. If you revoke the application password Zapier uses, every Zap connected to that site stops silently. There is no Zapier-side notification. You discover the failure when a task that should have run did not.

Silent failures are the real cost of external automation. You pay for the task whether or not the action completed, and you find out what broke only when a customer complains.

Troubleshooting: The Three Real Failure Modes

Failure mode 1: The Zap is not triggering

The most common cause is the polling interval. Zapier polls WordPress for new events on a schedule, not in real time.

If your test fires immediately after activating a Zap, Zapier may not have polled yet. Wait 2 to 5 minutes, then check the Zap history in the Zaps Task History section of your Zapier dashboard.

If no history entries appear at all, check whether the WordPress REST API is accessible. Go to yoursite.com/wp-json/wp/v2/posts in a browser.

If that returns a 403 or a redirect to a login page, a security plugin or server firewall is blocking the REST API. Common culprits are Wordfence with “Disable WordPress REST API for logged out users” enabled, or a Cloudflare rule blocking unauthenticated API requests.

Failure mode 2: Authentication errors after initial setup

Application passwords stop working when the WordPress user account is deleted, when the specific application password is revoked from Users Profile Application Passwords, or when a security plugin force-resets all application passwords after detecting a login anomaly. The fix is to generate a new application password and re-authenticate the Zapier connection. Go to Zapier Connected Accounts, find your WordPress connection, and click Reconnect.

Failure mode 3: Payload mapping errors when field names change

If you update a form plugin, a WooCommerce version, or a custom post type structure, Zapier’s saved field map may reference field names that no longer exist in the trigger payload. The Zap continues to fire but sends empty or incorrectly mapped data downstream.

The fix is to open the Zap, click Trigger Test, load fresh sample data, and remap any fields that have changed. This is a manual step that Zapier does not alert you to.

Also from wpRigel

Pollify is a Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the editor, so there are no shortcodes to paste and no separate interface to learn. It is worth knowing about if you collect audience feedback alongside your automations.

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.

It is the only command palette plugin with real WooCommerce order, product and customer commands built in. For agencies managing client sites, it replaces a significant amount of menu-clicking.

When to Keep Zapier, When to Replace It, and What We Would Do

Keep Zapier when you need to connect WordPress to a service that has no native plugin integration. Posting a new WordPress article to a LinkedIn Company Page, syncing WooCommerce orders to a fulfilment system’s proprietary API, or pushing form submissions into a Salesforce instance are legitimate Zapier use cases because those connections have no WordPress-native equivalent.

Replace Zapier with a native plugin when the trigger and the action both live inside WordPress. Welcome emails, role changes, post status automations, CRM syncs to FluentCRM, email list subscriptions, LMS enrolments, and WooCommerce order handling all fall into this category. Routing any of those through an external service adds cost, latency and a failure point that serves no one.

What we would do: install Krom Automation free from the WordPress.org plugin directory, migrate any WordPress-to-WordPress Zaps in the first week, and keep Zapier only for the connections that need its external reach. Most sites find they can drop to Zapier’s lowest paid plan or eliminate it entirely within 30 days. The 20 WordPress automations most sites should have is a useful checklist for identifying what can move to native.

See Krom Automation plan pricing to compare annual and lifetime options across 1, 5 and unlimited sites.

FAQ

Do I need a paid Zapier plan to use it with WordPress?

The free Zapier plan supports up to 100 tasks per month across 5 Zaps. That is enough for light testing or a single low-volume workflow. Most WordPress sites with active forms, user registrations, or WooCommerce orders exceed 100 tasks within the first week of real use and need at least the Starter plan at $29.99 per month.

Why does my Zap fire on post update instead of only on publish?

Zapier’s “New Post” trigger polls the WordPress REST API for posts with a publish status and a date newer than the last check. If you update a post and it triggers the Zap again, it means Zapier is seeing the updated timestamp as a new record. The workaround is to add a Zapier filter step that checks whether the post date equals the post modified date, but that filter step consumes an additional task per execution.

Can Zapier send form submissions to Google Sheets without custom code?

Yes, using a contact form plugin that supports Zapier triggers (WPForms and Gravity Forms both do via their Zapier add-ons) or by using the standard WordPress REST API. Each submission consumes one Zapier task for the trigger and one for the Google Sheets action, so a site with 300 monthly submissions uses 600 tasks for this one workflow alone. Krom Automation’s Google Sheets integration handles the same sync natively without per-row task costs.

Is it safe to give Zapier an application password for my WordPress site?

Application passwords are scoped to the WordPress REST API and cannot be used to log into the WordPress admin directly. The main risk is account-level: if the Zapier account is compromised, the attacker can create posts, users and WooCommerce products using the REST API. Mitigate this by creating a dedicated WordPress user for the Zapier connection with the minimum role needed (Editor for post creation, Administrator only if user creation is required), and review the application passwords list in your user profile monthly.

What happens to my Zaps if Zapier has an outage?

Zapier queues tasks during outages and attempts to replay them after service resumes, but the replay window is not guaranteed for all plan levels. Time-sensitive automations, like sending a password reset email or confirming a WooCommerce order, may fire minutes or hours late during an incident. Self-hosted automation runs on your own server, so the only uptime dependency is your hosting provider rather than a third-party service.

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.