WordPress Automation Across Multiple Client Sites
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.