Why Are Subscription Actions Greyed Out in AutomateWoo?

If you've opened AutomateWoo to build a workflow and found that subscription-related actions are greyed out or completely unavailable, you're not alone. This is one of the more confusing UX moments in the plugin — and the cause is almost always a dependency or configuration issue rather than a bug. Here's what's actually happening and what determines whether those actions become available to you.

What Subscription Actions in AutomateWoo Actually Do

AutomateWoo is a marketing automation plugin for WooCommerce. Among its features is a set of subscription-specific actions — things like pausing a subscription, changing its status, updating the next payment date, or sending targeted emails based on subscription lifecycle events.

These actions are designed to work alongside WooCommerce Subscriptions, a separate premium extension from WooCommerce (now Woo). The key word there is separate. AutomateWoo doesn't include subscription management functionality on its own — it hooks into WooCommerce Subscriptions to expose those actions inside your workflows.

The Primary Reason: WooCommerce Subscriptions Isn't Active

The most common reason subscription actions are greyed out is straightforward: WooCommerce Subscriptions is either not installed or not currently active on your site.

AutomateWoo detects whether WooCommerce Subscriptions is running in the background. If it can't find an active instance of the plugin, it disables the related actions in the workflow builder — hence the greyed-out appearance. The actions show up in the interface (so you know they exist) but are locked behind that dependency.

To check this:

• Go to WordPress Admin → Plugins → Installed Plugins
• Look for WooCommerce Subscriptions and confirm it shows as Active
• If it's deactivated or missing, those AutomateWoo actions will remain unavailable

🔌 Integration Checks Beyond Just "Is It Installed?"

Even if WooCommerce Subscriptions is installed and active, there are a few other variables that affect whether AutomateWoo can fully communicate with it.

Plugin version compatibility is a real factor. AutomateWoo and WooCommerce Subscriptions are both updated independently, and occasionally a version mismatch creates partial integration failures. An older version of either plugin may not support the full action set that newer versions expose. Keeping both plugins updated to their current stable releases is the baseline for reliable behavior.

License and activation status matters too. WooCommerce Subscriptions is a paid extension. If the license has expired or wasn't activated on the current site's URL, the plugin may still appear "active" in the plugins list but could be running in a degraded or unlicensed state. Some functionality — including API-level integrations — can be affected by this.

PHP and WordPress environment occasionally plays a role. If your environment has errors or conflicts that prevent WooCommerce Subscriptions from loading fully on every page request, AutomateWoo may intermittently fail to detect it as available.

How AutomateWoo Determines Which Actions to Show

Understanding this makes the greyed-out behavior less mysterious. AutomateWoo uses a conditional loading system — it checks for the presence of supported third-party plugins and only registers the relevant action classes when those dependencies are confirmed active.

This means:

This is intentional design — it prevents users from building workflows around actions that would fail silently at runtime because the underlying functionality isn't there.

Trigger vs. Action: A Distinction Worth Knowing

There's another layer here that trips some users up. In AutomateWoo, triggers and actions are different things. Some subscription-related triggers (like "Subscription Status Changed") might be available even when certain actions are greyed out — or vice versa. If you're seeing a mixed state where some subscription elements work and others don't, that's worth investigating separately.

For example, a workflow might successfully trigger on a subscription event but fail to execute a subscription-specific action if the dependency check for that particular action isn't passing. This can create confusing situations where a workflow appears to run but doesn't complete the expected step.

🛠️ Other Variables That Affect Individual Setups

Beyond the core dependency, a few setup-specific factors shape what you'll experience:

• Multisite environments handle plugin activation differently. A plugin active at the network level may not register the same way as one activated per-site, which can confuse AutomateWoo's detection.
• Third-party subscription plugins that aren't WooCommerce Subscriptions (like YITH WooCommerce Subscriptions or Subscriptio) are not the same dependency. AutomateWoo's subscription actions are built for WooCommerce Subscriptions specifically — alternatives generally won't unlock those actions.
• Caching layers occasionally serve stale plugin state information in the admin, making something appear inactive when it isn't. A cache clear is a low-effort diagnostic step worth trying.

What This Looks Like Across Different Setups 🔍

A store running a fully licensed, up-to-date WooCommerce Subscriptions alongside a current version of AutomateWoo will typically see all subscription actions available and functional. A development or staging environment where the Subscriptions plugin license isn't validated for that domain may see those actions locked. A site that recently migrated or cloned from a live environment might have the plugin present but not properly reactivated.

The right resolution depends on which of these scenarios reflects your actual environment — and that's what makes this particular issue one where the diagnosis has to come from your own setup rather than a universal fix.