You want to say "at most 50 people a day can use this campaign" or "once the gift codes run out, the flow should say something else". The Trigger counter counts how many times a condition has been passed and sends the flow down the other branch once the number is reached. This article covers setting the counter up, how the reset period works and why the counter behaves differently from every other rule.
⚠️ Note: The counter belongs to the automation, not to a person. A hundred different people trigger it and they all draw from the same counter. If you want "each person may use this campaign once", you need a field or a tag on the contact card, not a counter; see Field actions.
In this article you will find:
What the counter does
Setting the counter up
How the reset period works
Why the counter sits alone in its step
Reading the counter from the logs
The counter in a test
Limits and known issues
Common mistakes
What the counter does
A counter step answers two questions at once: "how many times has this step been passed" and "is the cap reached".
If the cap is not reached, one unit is taken and the flow continues down the True branch.
If the cap is reached, the flow continues down the False branch and the counter does not increase. A full counter never keeps inflating, and the remaining period does not shift.
The counting happens on the server in a single step. Even if two messages land at the same instant, the cap is never exceeded: the fifty-first person never ends up on the True branch under any circumstances.
The counter is the only rule with a side effect. Every other rule only looks; the counter changes something when it is passed. The consequences of that difference are covered in the sections below.
Setting the counter up
Add a new Condition step. Use a separate step for the counter; do not put other rules in it.
Choose Trigger counter as the rule kind.
Type the cap into the first box (How many). The default is 50.
Type the number for the reset period into the second box and pick its unit from the list next to it: minutes, hours or days. The default is 1 day.
In Connections, attach the True branch to the campaign steps and the False branch to your "cap reached" message.
The hint under the step summarises what the setting does. The values in the boxes read like "50 times / 1 day": fifty passes a day.
A concrete example: a hair salon gives a discount code to the first 20 people who comment on an Instagram post. After the comment trigger the flow holds a counter step set to 20 times / 1 day. The True branch sends the code and adds a got-code tag to the person; the False branch says "Today's quota is full — write to us again tomorrow."
How the reset period works
The period starts at the first pass and is not aligned to the calendar.
When you say "50 times / 1 day", the period does not wait for midnight: it resets 24 hours after the step is first passed. If the first pass happened at 10.00 in the morning, the counter resets at 10.00 the next morning.
The period is rebuilt in three cases:
When the period expires — The counter resets and the new period starts with that pass.
When you change the period — If you change the reset period (the number or the unit) and publish, the counter resets on the first pass after that and the period is rebuilt. This is the practical way to reset a counter by hand.
When the step is new — If you have just added the step, the first pass creates the period.
Changing the cap does not reset the period: the current cap is read on every pass. So raising the cap from 20 to 50 lets thirty more people through in the same period. Lowering it does not take the count below what it already is; the flow takes the False branch until the period expires.
💡 The counter is tied to the step you put it on. If the same automation holds two counter steps, each counts its own cap. Delete a step and add a new one, and the new one starts from zero.
Why the counter sits alone in its step
If the pre-publish check finds the counter in a step with other rules, it blocks publishing: "The trigger counter must be alone in its step."
The reason is this: the All must match and Any is enough modes short-circuit. Once the first rule comes out false, the rest are never evaluated. If the counter sat second in that list it would count on some passes and not on others — and you would be left with a cap you set to "50 a day" that nobody can say how often it counted.
The right arrangement is: set up the filter conditions first, and put the counter step after them.
Condition: "Tag · doesn't have · got-code" → people who have not had a code.
Condition: "Business hours · inside" → within opening hours.
Condition: Trigger counter · 20 times / 1 day.
Action: send the code and add the got-code tag.
Only the people who genuinely qualify pass through the counter, and the cap counts correctly.
Reading the counter from the logs
You can read from the logs why someone fell onto the False branch.
Open the automation and switch to the Logs tab.
Open the session and find the Condition line in the step-by-step log.
The line carries the counter's state at that moment: what the cap was, which pass of that period this was and when the period resets. If the cap is reached, the line says so as well. That line is the only certain answer to "why did the campaign cut off".
The counter in a test
The simulation on the Test tab does not actually count. In a test the counter always reads as "not full" and the flow takes the True branch.
This is deliberate: a test should not eat into your live campaign's quota. But it has a consequence — you cannot verify the False branch in the simulation. To test it, set the cap temporarily to 1, trigger the flow twice live and then put the cap back.
Limits and known issues
The cap is at least 1 and at most 1,000,000.
The reset period is at least 1 and at most 100,000 units (minutes, hours or days).
The counter is independent of the person: its key is the automation and the step.
The counter must sit alone in its own step; otherwise publishing is blocked.
When the cap is reached the counter does not increase and the remaining period does not change.
In a simulation the counter does not count; it always reads as "not full".
There is no button in the panel to reset a counter by hand. Changing its period and publishing is the way to rebuild the window.
The counter is a plan feature. If your plan does not cover it, the session stops at this step and a "Plan lock" line is written to the log.
Common mistakes
Thinking the counter is per person. It belongs to the automation. For a per-person limit, use a tag or a field.
Putting the counter in a step with other rules. Publishing is blocked; the counter wants its own step.
Putting the counter before the filters. People who do not qualify consume the counter too. Filters must come first.
Expecting the period to reset at midnight. The period counts from the first pass.
Leaving the False branch empty. When the cap is reached the flow ends quietly and the customer gets no answer at all.
Waiting for the cap to fill in a simulation. A test does not count.
If the counter does not behave as you expect, read the Condition line on the Logs tab first; if the problem persists, contact our Support team.