Answers
Data flow cards and recipes: what moves, and what you told it to do
Status answers four questions now, one per tab. Health: is it working. Data flow: what is it doing. Recipes: what have I told it to do. Execution log: what did it actually do, with a receipt for every run.
Data flow, as cards
Every flow between your connected systems is a card: where it comes from, where it goes, what it says in one line, how many times it has run in the last ninety days and when it last ran. The chip on each card is its real state, moving, waiting, paused or stopped, and the chips along the top filter the grid to one kind of flow at a time. The diagram is still there behind the toggle for anybody who thinks in arrows.
The run counts come from the same activity log you can read in the sidebar, so a card claiming twelve runs can be checked against twelve entries. A flow that has never run says so with a dash rather than a zero dressed up as progress.
Recipes
A recipe is one rule: when something happens, do something in your CRM. When an order is paid, apply a tag. When a tracked call is missed, apply a follow up tag so your automation calls them back. When a booking is a no show, set a field. A store plugin can only key on orders. MyVitalAssistant also sees your calls, your bookings, your forms and your deals moving stage, so a recipe can key on any of them.
Triggers: order paid, order refunded, form submitted, call answered, call missed, booking made, booking no show, deal moved to a stage. Most take an optional condition: only these products, only these forms, only these numbers, only this stage. Leave it empty and the recipe fires for every event of that kind.
Actions: apply a tag, remove a tag, write a note, set a custom field, or achieve a campaign goal in Keap. Notes and field values take merge fields such as the contact’s name, the order number, its total and the products on it, so a note can read “Paid order 4127 for $89.00: Cleaning Kit” without you typing any of it.
Tags and fields are picked from your own CRM, never typed, because a typo in a tag name is an automation that never fires and nobody notices. On HighLevel the tag list is what we have seen on your contacts, since HighLevel does not let us read its tag list directly.
Templates
The templates row holds the recipes most people write first. Click one and it opens in the editor with the trigger and the action filled in and the one thing you have to choose, usually the tag, left for you.
What a recipe will not do
Run twice for the same event. Each run is keyed to the event it came from, so a webhook that arrives twice, a store sync that re-reads yesterday, or a page refresh changes nothing the second time. Write into a CRM you have made read only on Settings → Tracking: every recipe pauses while that protection is on and says so on its card. Guess at a contact: if the person is not in your CRM yet when the event arrives, the run waits for the store sync or the form to create them and fires then, rather than tagging nobody or creating a duplicate. And it will not run more than three hundred CRM writes in a day for one account, which is a ceiling no real business has reached and a stop for a runaway rule.
Execution log
Every run and every failure lands here with the person it touched and a link to their record, filtered by recipe if you want one rule’s history. A failure says what the CRM answered, in its own words. Ninety days of history, and the same entries appear in the Activity log beside everything else that happened.
Who can write one
Owners and admins. A recipe is a standing instruction to write into your CRM, so it is held to the same rule as Do Not Contact and lead rules. Members see every recipe and every run.