Every prior course in this track has pushed you toward the same instinct: if WordPress needs to do something, register an ability for it. That instinct is right for anything that reads or writes WordPress’s own data. It starts to break down the moment the task crosses into systems WordPress has no business knowing about: a CRM, a billing platform, a Slack workspace, an email marketing tool. This lesson is about recognizing that line before you write the code, since building it the wrong way is a lot of PHP to eventually throw away.
No new setup for this lesson. It assumes you’ve built at least one working ability and MCP server, from Course 2, and that you’re evaluating a real integration idea, connecting WordPress to a CRM, an email tool, or a chat platform, as you read.
Step 1: Ask what the logic is actually about
The test that holds up in practice is simple: is this logic about WordPress’s own data, or is it about coordinating what happens across two or more separate systems? An ability that drafts a post, updates an order’s status, or queries site content is about WordPress data, full stop, even if an AI agent or an external platform is the one calling it. A workflow that says “when an order ships, look up the customer in HubSpot, update their lifecycle stage, then send them a branded email through Mailchimp” is not about WordPress data anymore. WordPress supplied one input, the order, and everything after that is coordination between other services.
| The logic is about | Belongs in |
|---|---|
| Reading or writing a WordPress post, order, user, or setting | A WordPress ability |
| Deciding what to do based on WordPress data plus a model’s judgment, conversationally | An MCP client or agent calling that ability |
| Reacting to a WordPress event by touching a CRM, email tool, or chat platform | An automation platform (n8n, Make, Zapier) watching a webhook |
| Multi-step coordination across three or more external services, with retries and branching | An automation platform, not a WordPress plugin |
Step 2: Why cross-system logic doesn’t belong in a plugin
Say the same “order ships, update CRM, send email” logic as a WordPress ability instead. You’d now need a HubSpot API client library, a Mailchimp API client library, credential storage for both, retry logic for when either service is briefly down, and a way to change any step without touching WordPress at all. None of that is WordPress’s job, and every dependency you add makes your plugin more fragile and harder to update independently of the site it lives on. An automation platform already solved retries, credential storage, and per-node error handling, reusing that is strictly less work than rebuilding a worse version of it in PHP.
There’s a second cost that’s easy to miss: visibility. A five-step n8n workflow shows you exactly where an execution failed, with the actual request and response for that step. The same five steps buried inside a WordPress action hook show up, at best, as one line in your error log, no matter how carefully you wrote the try/catch blocks.
Step 3: What still has to stay in WordPress
Moving orchestration out doesn’t mean moving everything out. WordPress still owns:
- The event itself: an order was placed, a post was published, a user registered.
- Any read or write against WordPress’s own data, exposed either as a REST endpoint or a registered ability.
- The authorization decision for whether a given request is even allowed to touch that
data,
permission_callbackdoesn’t move to n8n.
What leaves WordPress is everything downstream of that: what other systems get told, in what order, with what retries, and what happens if one of them fails. That boundary is exactly what Lessons 2 and 3 build, a webhook out of WordPress carrying the event, and an MCP call back into WordPress whenever the workflow needs to read or write something.
Step 4: A concrete example to hold onto
Picture a WooCommerce store where a new order over $500 should notify the sales team in
Slack, create a deal in a CRM, and tag the customer for a follow-up email sequence. The
“order over $500” check and the order data itself are WordPress’s job. Everything after
that, three separate external services, each with its own API shape, is squarely an
automation platform’s job. Trying to write that as one WordPress ability means one
execute_callback making three outbound API calls to three different vendors, with no
retry visibility and no way for a non-developer on your team to adjust the Slack message
wording without a code deploy.
Test it: run your own integration idea through the table
Take one real integration idea you have in mind (or one from later in this course: Slack notifications, CRM enrichment) and place every step of it into the table from Step
- If more than one step lands in the “automation platform” row, that’s your answer: build it as a workflow, not an ability.
It’s tempting to reason that a single outbound wp_remote_post() call to one CRM isn’t
enough coordination to justify a whole automation platform. The test isn’t call count,
it’s ownership and change frequency. If marketing wants to change what triggers the CRM
sync, or add a second destination next quarter, that’s a workflow edit in n8n taking
minutes. The same change to a hardcoded PHP call is a code change, a deploy, and a
developer’s time, every time.
Recap
The dividing line is whether the logic is about WordPress’s own data (an ability, called by an agent or the REST API) or about coordinating multiple external systems (an automation platform workflow, triggered by a WordPress event). WordPress always keeps the event, the data, and the authorization decision. Everything downstream of that, CRM updates, email sends, Slack messages, and any retry or branching logic connecting them, belongs in n8n, Make, or Zapier instead. The rest of this course builds exactly that boundary in both directions.
Resources & further reading
- n8n documentation, n8n
- WooCommerce Webhooks documentation, woocommerce.com
- wp_remote_post() function reference, developer.wordpress.org