Preview, test and live modes
An autorule changes real budgets, so Adset.pro gives it three verification stages: a preview of the draft right in the builder, test mode (Dry-run), in which the rule runs on schedule but changes nothing, and only then live mode (Live). This article covers what each stage shows, how to switch a rule to live, and how to stop it, return it to test, delete or edit it.
Two independent switches
A rule has a state (“Enabled” / “Disabled”) and a mode (“Dry-run” / “Live”). They change separately:
State | Mode | What happens |
|---|---|---|
Disabled | Dry-run | The rule does not run. Every new rule is created this way |
Enabled | Dry-run | The rule runs on schedule, calculates everything and writes to the log what it would do. Nothing changes in Facebook |
Disabled | Live | The rule does not run; once enabled, it will start changing objects |
Enabled | Live | The rule pauses, enables and changes budgets in Facebook |
Important. A new rule — from a template or from scratch — is always created disabled and in Dry-run mode. The save button for a new rule is literally called “Create in dry-run”. You cannot create a live rule right away.
Draft preview
The builder's “Preview” step shows what the rule would do right now in one ad account. Nothing is applied or written to the log. The preview works both for a new draft and for unsaved edits to an existing rule.
If the rule has several ad accounts, select an ad account in the list above the preview — it is calculated for one ad account at a time.
The “Calculate” button builds the preview; the “Update automatically” toggle recalculates it about 1.5 seconds after each edit. If you changed the draft and the preview is still old, it is marked “The draft has changed”.
While the steps contain errors, the preview is not built: “Fix the errors in the steps to build the preview” and a list of problems with step numbers.
What the preview shows
Block | What it contains |
|---|---|
Data freshness | “Data as of HH:MM”. If the data is older than the allowed lag — “The data is behind by N min (allowed M min): the scheduled run would be skipped” and the reason (for example, “Facebook spend sync is behind”) |
Live mode block and attribution | “Live is blocked for this ad account: the rule would not change anything here”, “Tracker attribution covers only part of the traffic of this ad account…” or “Tracker attribution is not set up for this ad account…” |
Warnings | List of rule and data warnings (table below) |
Counters | “In scope” — how many objects fall under the rule, “Evaluated” — how many were checked, “Matched” — how many passed the conditions. Objects that did not match are grouped by reason: “Conditions not met”, “Not enough data to decide”, “Below the minimum volume”, “Volume metric is unavailable” |
What the rule would do | The final decision for each action: what would be done (for example, “Change budget: $100.00 → $120.00”) and what was skipped with the reason (for example, “Skipped: budget would not change — Maximum budget limit”), plus the summary “Accepted: X of Y”. An action that will not run because live mode is blocked in the ad account is marked “live blocked” |
Objects and conditions | Up to 50 objects (matched ones first): “matches” / “does not match” and the reason. An expanded object shows a “Metric — Value — Condition — Result” table for each condition: “yes”, “no” or “unknown” with the reason (“No data”, “No complete hours in the window yet”, “Only a lower bound is known”, etc.). The condition window boundaries are shown in a tooltip. If an object has not reached the minimum volume — “Below the minimum volume: metric, value, required …” |
Preview warnings
Warning | What it means and what to do |
|---|---|
“No minimum volume threshold” | The rule can fire on an object with $2 of spend. Add a minimum volume or a condition on spend, clicks or impressions |
“Today's revenue by event time is understated” | Today's revenue metrics by event time have not fully arrived yet. Use the click-date cohort or full days |
“Budget action without an ad account budget cap” | The rule has an increase or “Set exact value”, but there is no cap on the ad account's total budget. Set it on the “Guards and notifications” step |
“Ad accounts use different currencies: …” | Budget amounts in the rule are a number in each ad account's currency. Check that the same limits make sense for all currencies, or split the rule |
“Budget type of some objects is unknown: N” | Budget actions on these objects will be skipped until the budget type arrives with the sync |
“Tracker attribution is not set up: live is blocked for this ad account” | The rule reads tracker metrics, but none of the ad account's sources passes the ID of the required level. Without it, all objects have “zero” deposits — live mode is blocked in the ad account. Map the campaign, ad set and ad ID macros in the tracker sources |
“Tracker attribution covers only part of the traffic” | Some sources do not pass the ID: objects of these sources will have zero conversions. Live mode works, but stop-loss and “zero deposits” rules will fire falsely on such traffic |
“Scope is cut at the object limit” | The ad account has more than 5000 objects under the rule — only the first ones are checked. Narrow the filters |
“Too many anchored windows: some conditions are unknown” | Objects have too many different “since the budget change” moments; for the oldest ones conditions will be “unknown” |
“Some objects are older than the tracker conversion history…” | “Lifetime” conversion conditions are unknown for objects older than about 190 days. For old setups, use “Last N days” windows |
What the preview does not show
Other rules of the ad account. The preview calculates a single rule. Conflicts with other rules (pause wins, priorities) are visible only in the log after real runs.
The history of a new rule. A new draft has no past actions, so the cooldown after an action and the daily limit do not trigger in the preview. For a saved rule, they take its past actions into account.
Whether the ad account can change objects at all. Whether the ad account has a profile with change permission is shown on the “Name and ad accounts” step: the “Chrome extension only” and “Changes not allowed” labels.
Other users' objects in the ad account budget cap. The total budget for the cap in the preview is calculated over the objects you can see; with restricted access to the ad account, it may be lower than the real one.
Tip. For a saved rule there is one more tool — the “Why not now?” log tab: enter an object ID and see whether it falls under the rule, which filter excluded it and what each condition returns. More details in the article “Log”.
Test mode (Dry-run)
An enabled rule in Dry-run mode runs on schedule like a live one, but changes nothing in Facebook. The builder hint: “Dry-run: the rule only writes what it would do to the log, nothing changes in Facebook”.
What happens in test mode:
the rule selects objects, calculates metrics and conditions, checks data freshness, applicability, the pause after a manual change, budget limits, the growth limit and the ad account budget cap — everything as in live mode;
the simulation takes the ad account's live rules into account: if in live mode another rule's pause would win over the test rule's budget increase, the log shows it;
actions that would have been executed are written to the log with the outcome “Simulated (dry-run)”, skipped ones — with their reasons;
notifications arrive marked as test mode — “test run” in the title, “test mode” and “Nothing was changed — switch the rule to Live” in the text; such a notification for an ad account is sent no more than once every 6 hours;
test rules do not interfere with live ones and do not occupy objects;
the profile change permission is not required for testing.
How test mode differs from live mode:
The rule does not remember its actions. The cooldown after an action and the daily action limit do not hold back repeats in test mode: if the condition persists, a “Simulated” entry for the same object will appear in every run. In live mode, after the first action the rule would wait for the cooldown. Evaluate the test by the number of distinct objects, not by the number of entries.
No check against Facebook before a change and no 00:00 re-enables after a pause until the end of the day.
Tip. Keep the rule in test mode for a day or two, and for rules on “yesterday” and “N full days” — at least two days: this way you will see both daytime and morning runs. Check which objects it fires on, whether there are false triggers on live ad sets, and how many actions there would be per day.
Switching to live mode (Live)
Who can
What | Team owner | Team lead | Tech specialist | Buyer |
|---|---|---|---|---|
Create and change rules in test mode | Yes | Yes | Yes | No, view only |
Switch to Live, enable and change a live rule | Yes | Yes | Yes | No |
Delete rules | Yes | Yes | Yes | No |
Allow changes on a social profile | Yes | Yes | No | No |
A platform administrator can do everything. Besides the role, the “Meta autorules” plan feature is required.
How to switch
In the builder — the “Switch to live” button in the rule header. Save or discard your edits first: “Save or discard the changes first”.
In the rule list — the mode toggle in the rule row or the “Change mode” bulk action for the selected rules.
Switching always requires confirmation. In the builder — “Let the rule change Facebook objects?” with a list of ad accounts; in the list — “Switch to live?” or “Enable a live rule?”. An enabled rule starts acting at the next scheduled run; a disabled one — only after it is enabled.
When switching, the system checks the rule once more:
the configuration fully passes the current checks (if the rule was saved long ago and the validation rules have changed since then, you will have to fix it);
all of the rule's ad accounts are available both to you and to the rule owner — otherwise “Some ad accounts of the rule are not available to you, so it cannot be enabled or switched to live” or “…not available to its owner…”;
the rule owner is an active team member (the rule runs on their behalf and sees only their ad accounts).
Even in live mode, the rule will not change anything in an ad account if:
the ad account's profiles do not have the “Allow autorules to change statuses and budgets of this profile's campaigns” permission, or the ad account is connected only via the Chrome extension — actions are skipped with the outcome “Skipped: no profile can make changes”;
the rule reads tracker metrics, but the ad account's attribution is not set up — “Skipped: not applicable — Tracker attribution is not set up for this ad account”.
Checklist before switching to Live
The rule has run in test mode for at least a day or two, and the log shows no false triggers on live objects.
The preview for each ad account has no “Tracker attribution is not set up”; if there is “covers only part of the traffic”, you know which sources do not pass the ID.
The data is fresh: no “The data is behind…”, and the log has no “Skipped: stale data” runs.
The “Name and ad accounts” step has no “Chrome extension only” and “Changes not allowed” labels; the change permission is enabled on the ad accounts' profiles.
The “Objects in the rule now” counter on the “Which objects” step shows the expected number of objects, and there are no “more than 500” and “will process only the first 5000” warnings.
Budgets: amounts are in each ad account's currency, increases have a real maximum, the ad account budget cap is set, and there is no different-currencies warning (or you have accepted it deliberately).
Guards: the cooldown after an action and the daily action limit match the schedule frequency; the pause after a manual change does not interfere with your manual work.
The schedule and activity windows are in each ad account's time zone, not yours.
The priority is aligned with other live rules of these ad accounts (stop-losses above scaling).
In “Notify about”, “Errors” is enabled, and “Notify” is added to the actions for the initial period.
Start with one ad account: leave one ad account in the rule and switch it to live; add the other ad accounts after the first day.
Pausing a rule
The “Disable” button in the builder or “Pause” in the list (as well as the bulk action) stops the rule.
You can always stop a rule — even if its configuration no longer passes the current checks or someone else has just changed it.
There will be no new runs; actions already taken remain in the log and can be rolled back.
Objects that the rule paused until the end of the day will still be re-enabled at 00:00. Scheduled re-enables are shown on the “Scheduled enables” log tab.
After it is enabled again, the rule runs at the next suitable scheduled time; runs missed during the pause are not made up.
Returning to test mode
The “Back to dry-run” button in the builder or “Switch to dry-run” in the list. No confirmation is required; you can return to test at any time.
Starting from the next run, the rule stops changing objects and again only writes “Simulated” entries.
Actions already applied remain in the log and can be rolled back.
Scheduled 00:00 re-enables after a pause until the end of the day will be executed.
Deletion
You can delete a rule from the list (a row action or bulk deletion) with confirmation: “The rule will be paused and moved to deleted. Its log is kept”.
A deleted rule is disabled and no longer runs. You can find it with the “Deleted” filter → “Deleted only” or “Including deleted”.
A deleted rule opens in read-only mode: “The rule is deleted and cannot be changed”. It cannot be restored — create a new one if needed. The name of a deleted rule can be reused.
The log is kept: action entries are stored for 90 days, runs — for 180 days.
Scheduled 00:00 re-enables will be executed even after deletion.
Deletion requires the delete permission: “Your role cannot delete rules”.
Editing and version conflicts
Editing opens in the same builder. Changes take effect from the next run. If the rule was changed while a run was in progress, that run is skipped with the reason “Rule changed during the run”.
An enabled live rule can be changed only by a role with the Live permission. Without it, the rule opens in view mode: “The rule is live and enabled: changing it requires the live permission”.
A rule name is unique within the team: “A rule with this name already exists in the team”.
You can change the level of a saved rule, but conditions and actions are re-validated — some of them may become unavailable at the new level.
There is no protection against leaving the page with unsaved edits — save before leaving.
“Someone else changed this rule”
Each save increments the rule version. If you opened a rule and a team lead saved their edit before you, your save will not overwrite their changes. The builder will show: “Someone else changed this rule after you opened it. Reload it to see the current version; your unsaved changes will be lost” — and a “Reload” button.
Write down your values before reloading: after it, you will see the other user's version and apply your edits on top of it.
The “Enable” and “Switch to live” buttons are also bound to the version: exactly the configuration you saw is enabled. If it was changed in the meantime, the list shows “The rule was changed while the list was open. The row has been refreshed: check its state and try again”.
“Pause” and “Switch to dry-run” are not blocked by version conflicts — you can always stop a rule.