Timer Fields
A Timer runs a list of actions after a delay, either once or over and over. Like a Multi-Action it has no appearance - the user never sees it - and like a Multi-Action it is where a form does something without anybody clicking anything.
Typical uses: run something a moment after the form opens, once everything has loaded; refresh a search or a set of required documents every so often on a screen left open all day; step a display along on its own.
Settings
Field Name - The name used to refer to the timer in conditions and in actions.
Number of Seconds to Start - How long to wait before the actions run the first time. Decimals are allowed for a fraction of a second. Set it to 0 to run as soon as the form loads, and leave it empty to disable the timer entirely, which also stops it repeating. {field} notation can be used, so the delay can come from a field on the form.
Run Action Repeatedly - Turn this on for a timer that keeps going. Turn it off and the actions run once.
Seconds Between Actions - How long to wait between runs when the timer repeats. It is required when Run Action Repeatedly is on and shows in red until you fill it in; a repeating timer with this left empty runs only once. Decimals are allowed, and {field} notation can be used here too. A timer that refreshes something every ten seconds therefore has 10 in Number of Seconds to Start, Run Action Repeatedly turned on, and 10 in Seconds Between Actions.
Run When - A condition that decides whether the timer runs at all, built the same way as the conditions described in Field Conditions. Use it to keep a repeating timer from running where it is not wanted - only on the record screen, only for internal users, only while the record is at a particular workflow step.
Actions - The list of actions to run, in order, each with its own Execute When condition.
Controlling the Timer from an Action
Any action that can set a field can control a Timer by using Set Field Value on the Timer field with one of three words. RESET starts the wait for the next run over from now: once the timer is repeating it waits Seconds Between Actions, and before its first run, or on a timer that runs one time, it waits Number of Seconds to Start. STOP holds the timer until a START or RESET arrives, even if Number of Seconds to Start changes in the meantime. START sets a stopped timer going again, or re-arms a one-time timer that has already run. A timer with Number of Seconds to Start left empty is disabled and ignores all three.
RESET is the one to reach for when a refresh should wait for the user. A dashboard that refreshes its Data Source every 30 seconds, plus a Multi-Action that watches the fields the user edits and ends with Set Field Value RESET on the Timer, refreshes 30 seconds after the last edit rather than in the middle of one. The same idea on a one-time timer gives a pause-then-run: a Timer set to run one time after 10 seconds, reset on every change to a field, runs its action once the user has stopped typing for 10 seconds.
Points to watch
A repeating timer keeps running for as long as the form is open. Anything it does that reaches the server - a search refresh, a REST call, an Action Set - happens once per cycle, for every person with the form open. Set the interval to the slowest that is still useful; a few seconds is rarely necessary where a minute would do.
For a one-off action as the form opens, a Timer set to 0 seconds is the usual way to have something run after everything has loaded, which a form-load action cannot always guarantee.
Where the timer's work is more than a step or two, put the sequence in a Multi-Action field and have the timer trigger that. The sequence is then easier to test - a button can run it on demand - and can be reused elsewhere.