AutomatorWP Advanced Custom Fields

A field stores a decision, but it tells no one

Someone changes a field called "Status" to "Approved" in the editor. The data is saved and correct. But the person who should act never hears about it, the email does not go out, and the next step keeps waiting for someone to remember to check that screen.

As soon as you use custom fields to track a process, each field is a decision taken that sets nothing in motion on its own. This add-on joins Advanced Custom Fields to AutomatorWP: a field changing to a value can start an automation, and an automation can write a value into a field.

It does not create fields or replace ACF, which remains where data is defined and stored. Nor does it automate anything without AutomatorWP, the plugin that runs automations inside your site.

Four triggers and three actions

An automation has two parts: the trigger, which is what happens, and the actions, which are what gets done next. These are the triggers:

• Free: a user updates a post field with a value.
• Pro: a user updates a user field with a value.
• Pro: a user updates a post field with a value on a post.
• Pro: a user updates a page field with a value on a page.

And these are the actions:

• Free: update a post field with a value.
• Pro: update a user field with a value.
• Pro: update a page field with a value.

Two directions for using the same field

The field as a signal. The value change is the trigger, and you supply the actions: AutomatorWP works with hundreds of triggers and actions from other plugins, and one action can be emailing the user. That way, the "Approved" value no longer has to wait for someone to see it.

The field as memory. Here the order flips: something happens in another integrated plugin and the action writes a value into a field. The field then records what happened, with nobody copying it by hand.

Both recipes are your own combinations, so try them on test content before trusting them with a real process.

Options pages and changes by other routes

The triggers and actions are divided among posts, pages and users. None of them is for options pages.

The action list is not symmetrical either: there are three actions against four triggers. It pays to compare what you need before designing the flow.

The triggers speak of a user updating a field with a value. If fields on your site also change by other routes, check which of them start the automation.

Building your first automation with a field

It works on top of ACF and AutomatorWP, with both active alongside the add-on. To get started:

1. Define in ACF the field that will mark the process, and its values.
2. Create an automation in AutomatorWP.
3. Choose the matching ACF trigger and set the field and value.
4. Add the action that should happen next.
5. Change the field on a piece of test content and check the result.
6. Repeat with another value to confirm it does not run when it should not.

AutomatorWP, ACF Pro and Uncanny Automator

AutomatorWP Pro opens the catalog of paid add-ons on the same platform. AutomatorWP Formatter shapes text, numbers and dates between steps, which helps if a field's value must arrive in another format. There is also AutomatorWP Webhooks.

To define the fields there is ACF Pro. If you prefer another automator, Uncanny Automator Pro works with recipes inside WordPress.

User fields, the Free part and code, in brief

Can I react to a user field?

Yes, with the Pro trigger for user fields. There is also a Pro action that writes to them.

Which part is Free?

One trigger and one action, both on post fields. The rest is Pro.

Does it work with any post type?

The list covers post, page and user fields. With a custom content type, run a test first.

Does it create the fields for me?

No. Fields are created in ACF. The add-on reads their changes and writes values to them.

Do I need to code?

No. AutomatorWP is set up by choosing triggers and actions.