Recipes for Everyone

A recipe for Everyone runs whether or not the person who triggered it is logged in: a visitor submitting a form, a guest checking out, or another service sending data to a webhook. Because the trigger does not come with a known user, you tell the recipe which WordPress user its actions should run as, or have it create one. This article builds an Everyone recipe from a form submission and sets up both cases. For what the two recipe types are and when to choose each, read Recipe types: logged-in users and everyone first.

The example uses WPForms with a form that has Name and Email fields; any supported form plugin works the same way. Choosing which user the actions run as, an existing user or a new one, requires Uncanny Automator Pro. Without Pro, the card reads Choosing which user an Everyone recipe runs its actions on requires Uncanny Automator Pro. and the choices in the dialog are turned off.

Build the recipe

1. Go to Automator > Add new recipe.
2. In Select a recipe type, click Everyone, then Confirm. The type cannot be changed later.

3. Click Name your recipe and type a title. The recipe saves automatically.
4. In TRIGGERS, click + Add trigger, search for WPForms, and click it. If the picker shows it as Not installed or Not active, install and activate WPForms first; Finding integrations in the recipe builder explains the picker’s states.
5. Click A form is submitted. In an Everyone recipe the picker lists only the triggers that work for visitors, so the logged-in “A user submits a form” trigger is not offered.
6. On the Set up step, choose your form in Form. The first form on the site is selected to start with. This trigger has no Test step, so click Save.

An Everyone recipe has one trigger, so once it is saved Diagram view shows no + Add trigger button.

7. Click the + at the end of the flow and add an action that acts on a user, for example LearnDash > Enroll the user in a course. On the Set up step, choose the course from the Course list and save it.

As soon as the recipe contains an action that needs user data, a RUN RECIPE AS section appears between TRIGGERS and ACTIONS with the card Choose which user the recipe runs as and a User data needed notice.

Run the actions as an existing user

Use this when the people submitting the form already have accounts, for example a request form for existing members.

1. Click the Choose which user the recipe runs as card. The Run actions as dialog opens.
2. Under Run actions as, keep An existing user.
3. In Match by, keep Email. User ID and Username are the alternatives when the trigger supplies one of those instead.
4. In Value, click the ∗ button and, in the trigger’s group (its heading reads Form: followed by your form’s name and is submitted), pick Email. Each submission is then looked up by the address the visitor entered. If the trigger’s group is not listed, save the trigger first and come back.
5. Under If the user doesn’t exist, choose Skip the action to do nothing for unknown addresses, or Create a new user to register them (the new-user fields from the next section appear).
6. Check the sentence at the top of the dialog. It reads An existing user matching Email followed by the token. Click Save. The card then shows the same sentence, and the User data needed notice is gone once Value is filled in.

Create a new user from the form

Use this to turn an ordinary form into a registration form: the submission creates the account and the recipe’s actions then run on it.

1. Open the card and, under Run actions as, select A new user.
2. Fill the account fields from the form’s tokens: Email, Username, First name, Last name, and Display name. The email field is the one to get right; use the visitor’s email address as the username as well if your form does not ask for one.
3. Leave Password empty unless your form collects one. With no password, the user must reset their password before they can log in, so add a Send an email action that includes the User reset password link token (in the Common section of the token picker’s Global tab) so they receive the link straight away.
4. Choose a Role: Subscriber, Contributor, Author, or Editor. Subscriber is right for members and learners.
5. Switch on Log the new user in if the visitor should land on your site already signed in. This works for triggers the visitor causes on your site, such as this form; a webhook from another service cannot log anyone in.
6. Under If the user already exists, choose Use the existing user so returning members are updated rather than rejected, or Skip the action. Neither is selected until you choose, and the field is required. Choosing Use the existing user adds Match the existing user by (Email or Username), which decides which account wins if one matches the email and a different one matches the username.
7. Click Save.

Note: For a form that serves both new and returning people, the existing-user setup with Create a new user as the fallback does the same job from the other direction: known addresses are matched, unknown ones get an account.

Switch on and test

1. Check that the trigger and every action show On, then click Recipe off in the top bar so it reads Recipe on.
2. Open the page with the form in a private browser window, so you are logged out, and submit it with a test name and address.
3. In the builder, expand Details: Completed runs should read 1, and View logs opens the Logs page where the Action tab shows what ran and for which user. For a new-user setup, the account also appears under Users in WordPress.

Common uses

• Registration forms: any form plugin’s submission trigger plus A new user, then actions such as enrolling in a course, adding to a group, or emailing a coupon. See Register users from a form submission.
• Webhooks: data from Zapier, Make, IFTTT, or another site running Uncanny Automator arrives at an incoming webhook trigger, and the recipe matches or creates the user from the payload’s fields.
• Guest checkout: a WooCommerce order that may come from a guest, matched to a user by the billing email, or left to run without a user when the actions do not need one.
• Recipes with no user at all: a form submission that posts to Slack or sends data to a webhook. These need no Run recipe as setup, and the RUN RECIPE AS section does not appear until you add an action, condition, or token that needs user data.

Multisite

WordPress shares user accounts across a multisite network, so an Everyone recipe cannot create a user on one site of the network when that user already exists on another. The workaround, for developers, is to update the existing user instead of creating one: on the originating site, an action sends the user’s data by webhook to the target site; on the target site, an Everyone recipe with an incoming webhook trigger matches the existing user, and the WordPress Set user meta action (Uncanny Automator Pro) adds two rows under Meta: wp_2_capabilities set to a:1:{s:10:"subscriber";b:1;} and wp_2_user_level set to 0, where 2 is the target site’s blog ID and the serialized role can be changed to suit.

Who can reach the trigger

An Everyone recipe lets anyone who can reach the trigger create or change users on your site without logging in. Before switching one on, think about where the trigger is exposed:

• Should anyone be able to submit this form, or only certain people?
• Should search engines index the page that holds the form?
• Should the page appear in your site’s own search results?

If several forms run different recipes, restrict access to the pages with your membership plugin or another plugin that limits who can view a page.

Related: Recipe types: logged-in users and everyone, Creating a recipe, Register users from a form submission, Incoming webhook triggers, Managing actions