Uncanny Automator Workflows: Automate WordPress and Know When to Customize

Uncanny Automator lets you connect WordPress plugins and outside apps without writing code. You build “recipes”: when something happens on your site (a trigger), WordPress does something in response (an action). Most business workflows, like registering a user after a form submission or enrolling a customer in a course after purchase, can be built this way. Custom development comes in when you need a trigger or action that does not exist yet, or when a workflow grows too complex to manage by clicking.

This article explains how Automator works, how to design workflows that stay reliable, and how to tell when it is time to customize.

How Uncanny Automator works

The idea is simple: “if this happens, then do that.” The Automator knowledge base describes these building blocks.

Recipes

A recipe is one automation. It contains triggers, actions, and optional settings like conditions and delays. Each recipe can be turned on or off on its own.

Triggers

A trigger is the event that starts a recipe. Examples:

• A user submits a specific Gravity Forms form.
• A customer buys a WooCommerce product.
• A student completes a LearnDash course.
• A user’s role changes.

The free version supports one trigger per recipe. With Automator Pro, logged-in recipes can have several triggers, and you choose whether actions run when any of them happen or only when all of them have happened.

Actions

An action is what happens in response. Examples:

• Create or update a WordPress user.
• Enroll the user in a course or membership.
• Send an email.
• Add a row to a Google Sheet or a contact to an email marketing list.
• Send data to another system with an outgoing webhook.

Tokens

Tokens are placeholders for dynamic data. When you write the email in an action, you can insert tokens for the user’s first name, the form field values, or the product they bought. Automator fills them in when the recipe runs. You pick tokens from a menu, so no code is needed.

Logged-in recipes vs recipes for everyone

Automator has two kinds of recipes, and choosing the right one matters.

Logged-in recipes track each user. They fit things like “when a member finishes three courses, give them a certificate role.” Because Automator tracks the user, it can wait until all triggers are met.

Recipes for everyone (previously called “anonymous” recipes) work for visitors who are not logged in, like someone filling out a public contact form. If the actions need a user, Automator can create a new user or match the visitor to an existing user.

A common mistake is building a logged-in recipe for a public form. It never fires for visitors who are not logged in, and nobody notices until leads go missing.

Adding logic: conditions, delays and loops

Simple recipes are “when X, do Y.” Real workflows usually need more. Automator Pro adds tools for that.

• Action conditions let an action run only when certain things are true. The Automator docs on action conditions give examples like checking the user’s email domain, their WordPress role, or a value in a form submission.
• Delays and schedules control when an action runs. A delay waits for a period after the triggers complete. A schedule runs the action on a set date. One detail from the scheduled actions docs: if the scheduled date has already passed when the user meets the triggers, the action runs right away.
• Loops run actions in bulk on users or posts that match criteria, such as emailing every user with a certain role.

Webhooks also come in two directions. Outgoing webhooks, which send data to another system, are available in the free version. Incoming webhooks, which let an outside system start a recipe, are part of Pro, according to the plugin’s WordPress.org page.

Example workflow: from form to customer

Here is a typical workflow we might build for a training company, using Gravity Forms and Automator together:

1. Trigger: A visitor submits the “Course signup” form (a recipe for everyone).
2. User step: Automator creates a WordPress user from the form’s email field, or matches an existing user.
3. Action: Enroll the user in the course.
4. Action: Add the contact to the email marketing list with a “new student” tag.
5. Action with condition: If the “Company” field is filled in, notify the sales team.
6. Delayed action: Seven days later, send a check-in email.

Each step uses tokens from the form, so the emails and records carry the right names and details. If you need the form itself to do more, like filling fields from your own data, see our article on Gravity Forms custom development.

Designing workflows that stay reliable

Automations save time until one fails quietly. These habits keep them dependable.

Name and document every recipe

Give each recipe a clear name that says what it does: “Course signup form: create user and enroll.” Keep a short list of what each recipe is for and who owns it. Six months from now, someone will need to know.

Keep recipes small

One large recipe that does ten things is hard to debug. Several small recipes, each with a clear job, are easier to test and change.

Check the logs

Automator keeps recipe, trigger and action logs. The action log shows what ran and any errors. Check it after building a recipe and regularly after that. A failed action in the log is much better than a customer telling you they never got access.

Test with real scenarios

Before turning a recipe on, test it on staging with a real user flow: submit the form, buy the product, finish the course. Then check that each action happened. For important workflows, an automated browser test can repeat this after every update. Our guide to automated WordPress testing with Playwright and PHPUnit explains the approach.

Treat plugin updates with care

A recipe depends on every plugin it touches. An update to your form, store or course plugin can change how a trigger or action behaves. Run updates through staging first, as described in our guide to safe WordPress updates.

When to customize

Automator supports a large library of plugins and apps, but not everything. Here is how we decide when custom work makes sense.

You need a trigger or action that does not exist

Your site may run a custom plugin, an internal booking system, or a niche plugin with no Automator support. Instead of hacking around it, a developer can build a custom integration. The Automator developer resources describe how a typical integration includes triggers, actions, a condition, tokens and a settings page. Once built, your custom triggers and actions show up in the recipe builder next to the built-in ones, so your team can use them without code.

You need tokens that carry your own data

If your recipes need values from custom fields or your own database tables, custom tokens make that data available in any recipe.

The workflow has outgrown point-and-click

Some workflows have many branches, heavy data handling, or strict error handling needs. If a recipe needs a dozen conditions to cover every case, it may be clearer and safer as code, with automated tests, that Automator calls as a single action.

Performance is suffering

Recipes run inside WordPress. A loop over thousands of users, or many recipes firing on every page load, can add load to the server. If your site has slowed down since adding automations, it is worth a look. Our article on why your WordPress site is slow explains how we diagnose this.

Automator and technical debt

Automations can become technical debt. Old recipes for retired products keep running. Nobody remembers why a delay is set to 14 days. Custom code built around Automator has no tests. We include recipes in our technical debt reviews and ask the same questions we ask of plugins: is it still needed, does it still work, and is it documented? Our guide to measuring WordPress technical debt covers the full method.

Why we work with Automator

Our founder is a core developer of Uncanny Automator, so we know how triggers, actions and tokens work under the hood. That helps when a recipe behaves in a way the documentation does not explain, and when we build custom integrations that need to fit in with the rest of the plugin.

Get help with your automations

If you want to automate a workflow, fix recipes that fail, or build a custom integration, see our Uncanny Automator expert service. We review your setup and give you a fixed quote. Contact us to talk it through.

Frequently asked questions

What is an Uncanny Automator recipe?

A recipe is a saved automation. It has one or more triggers, which are events like a form submission or a course completion, and one or more actions that run when the triggers happen, like creating a user or sending an email.

What is the difference between logged-in recipes and recipes for everyone?

Logged-in recipes are tied to a WordPress user and run when that user does something. Recipes for everyone, a Pro feature, can run for both logged-in and logged-out visitors, and can create a user or match an existing one when the actions need user data.

Can Uncanny Automator replace Zapier?

For automations between plugins on the same WordPress site, often yes, because the work runs inside WordPress. Connections to outside apps are supported too, and the free version includes a limited number of app credits.

When do I need custom development for Uncanny Automator?

When no existing trigger or action fits, for example with a custom plugin or an internal system. Automator has developer resources for building custom triggers, actions, tokens and conditions that appear in the recipe builder like built-in ones.