Uncanny Automator is a complex WordPress plugin that can sometimes be confusing, especially if you’re just getting started and are trying to test things.
Here are a few tips that might explain common issues we see when people are testing recipes and just starting out.
- Make sure the triggers and actions, plus the recipe itself, are “Live”. It’s really easy to overlook setting the recipe to “Live” and then wondering why it won’t run.
- By default, each recipe only runs once per user. If you’re testing, you probably want to set the recipe to run multiple times (using the setting on the right) so that you can trigger the conditions more than once. You can always turn the number back down after confirming the recipe runs properly.
- Remember that recipes only run against triggers that are satisfied after the recipe is set up. As an example, if a trigger is a product purchase, and the user already purchased the product, activating the recipe will not run the recipe on that historical purchase, just future purchases.
- If you have multiple recipes that run on the same triggers, and those recipes include redirects, the behaviour will be unpredictable. It is not recommended that you include redirects for recipes that are likely to be triggered simultaneously.
- All triggers run with AND conditions. In words, if a recipe includes 2 triggers, both must be satisfied after the recipe was set up for the actions to run. If you want a recipe to run when only one of the triggers is satisfied, you will need to use multiple recipes instead.
- Custom fields set up with Advanced Custom Fields (ACF) are not currently supported. The variety of field types and how they’re stored requires significant development; support is not expected until sometime in 3.x.
- All recipes must be run against a WordPress user. If no user is relevant to the recipe (e.g. submit a form anonymously to pass data to Google Sheets) you can map the recipe to a hardcoded placeholder user instead.
As you get more advanced with Automator recipes, here are some considerations for successful use:
- Deactivating plugins that have active triggers and actions can have unpredictable results. When you deactivate a plugin, any recipes that include triggers tied to that plugin simply can no longer be completed. In other words, if the plugin doesn’t exist, the trigger can’t run. This means that recipes that include triggers from deactivated plugins will stop running and cannot be completed; actions will never be executed. To fix this you can either reactivate the plugin or delete triggers associated with deactivated plugins. For recipes with actions tied to deactivated plugins, those steps simply won’t run, and worse, there is then no way to trigger them later if they’re skipped. As an example, let’s say a recipe has 2 triggers: submitting a form and making a WooCommerce product purchase. The actions are to enroll the user into a LearnDash course and send the user an email. If LearnDash gets deactivated while the recipe is live and the user completes the triggers, the user will be sent the email but will not be enrolled in the course. And if WooCommerce gets deactivated, the recipe never gets executed because the product cannot be purchased.
- Email actions may behave unpredictably when triggered frequently. This is especially true if you use a third-party email service such as Sendgrid, Sparkpost, Amazon SES, Gmail, etc. for outgoing emails. These services may restrict identical emails sent in succession (such as notifications) or limit the rate at which emails are sent.