Turn Automator into a CRM with user and post meta

There are many hidden gems in Uncanny Automator, but one that doesn’t get enough attention is the use of custom user meta and post meta records to make new scenarios possible in your recipes. We sometimes get requests from our power users to do things like the following:

• Store user flags and identifiers in their profiles
• Pass data from one recipe to another recipe
• Use data from one recipe run in a subsequent recipe run
• Allow more condition types when determining when (or when not) to run a recipe or just an action

While Uncanny Automator might not have its own system to pass data between recipes and iterations, you can still do it. What’s more, it’s really easy and very powerful.

In fact, you could follow the examples in this article to turn Uncanny Automator into a simple CRM. After all, adding user identifiers to a user’s profile and making workflows conditional on those values is basically how tagging works in CRMs.

Why use flags in user meta?

A recent ticket from a customer is a great example of why you might want to do this on your site. For that user, they wanted to run some onboarding actions (an email greeting, adding a user to a group, setting a CRM tag) whenever someone signed up for a subscription. The problem is that the trigger they wanted to use would fire every month when the subscription was renewed, because that renewal was a new order for that product.

So why not just set the recipe to run only once per user? That would be an easy solution, but the problem there is that users might resubscribe in future–and all of those actions should run again for the user when they resubscribe.

That’s where user meta flags come in. We can set an identifier in the user’s profile to control when and when not to run the recipe for the user. To put this in simplified terms, we can tell Automator to do the following:

1. On first purchase, run through the actions and add a flag to the user’s profile that they’re subscribed.
2. Tell Automator not to run the recipe actions if that subscription flag exists.
3. Have a recipe to remove the flag if the user’s subscription is cancelled.
4. Repeat from step 1 if the user resubscribes in future, with the actions now running because the flag is gone.

Pretty useful, right? Let’s walk through exactly how this would work in Uncanny Automator.

Please note that Uncanny Automator Pro is required because this scenario makes use of conditional actions.

Use user meta to control actions

Let’s suppose we want to run a series of actions whenever someone sets up a subscription for a particular product. It should only run for manual purchases when a subscription doesn’t yet exist, not recurring subscription orders. Maybe on purchase the user is sent an email, but we need to make sure the email only goes out to the user when setting up the subscription. Here’s what it might look like:

Let’s walk through exactly what we’re doing here in the actions.

The first action is sending the email, but we’re saying to send the email ONLY if the user’s value for the “active_subscription” meta key is not equal to 1. We set this condition by clicking the Filter button and choosing the General > A token meets a condition option. That allows us to run actions based on user meta values, like this:

For the first recipe run, of course, this value wouldn’t be populated. That means the email would go out to the user.

In the next action, we’re setting that user met value (active_subscription) to 1. That’s how we make sure that if this recipe runs again for the user, the email won’t go out while that value is populated.

Why the delay? That’s just in case it’s a complex recipe that takes a few seconds to process; with the delay we can make sure this action runs last and won’t affect earlier actions in any way.

Removing the user meta flag

For as long as this user maintains an active subscription, we don’t want the email going out to them. But if they cancel the subscription and repurchase it at a later date, we want it going out. (The email example is for simplicity, in a real-world scenario maybe we need to remove a CRM tag, membership level or group enrollment.)

We then need another recipe with triggers that cover a user’s subscription expiring or being cancelled. Then, in the action for this recipe, we set the user meta value for active_subscription to a different value:

Now, because the value is “2”, and not “1”, if the user triggers the original subscription again, the recipe will tell the system to send out that email (or whatever other actions are set up). That recipe runs, does what it’s supposed to do, and changes the active_subscription flag in user meta back to 1. That’s a simple example of how you can use user meta values as flags to change how recipes run across iterations and with consideration for other recipes.

Isn’t that how CRM tags work?

You might even think about using these user meta records the way way you might use tags in a CRM. You can add any values you want to a user’s profile, and then you can control automations and site behaviours based on those values–just like tags in a CRM. Following this approach, you could use Automator and user meta checks to:

• Remove access to a course if a user doesn’t have a meta value (perhaps added by form submission or purchase) after 60 days of receiving course access. This works because conditions are verified when an action runs (when an action is delayed), not when the triggers are completed.
• Add a user’s post to an activity feed via form submission if they have a special flag in their profile, otherwise notify the user (perhaps via pop-up) that they can’t make posts.
• Don’t send welcome emails if a user has previously been a member of a group, as defined by a user meta tag (since normally groups in most plugins can’t track historical access).

These are just a few ideas, but there are a lot of possible use cases with this approach to using user meta as a tagging system.

What about post meta?

You can use post meta flags in exactly the same way. Maybe you only want posts with a certain ACF field value to be posted to Facebook and Twitter, and you’re using categories and tags for other purposes. Or maybe you you want posts created by Uncanny Automator to be treated differently than other posts, so on creation, you set the flag. Then, when the post type is incorporated into other recipes, you can distinguish posts by how they were created, or which recipe created them.

Have other creative ideas for leveraging user meta and post meta in your recipes? Let us know in the comments!