Reserved words

Both lists below are ReservedWords() from the parsers, dumped at build time.

The rule

A reserved word may not be used as a bare name. There are exactly three bare name positions in the languages:

• an event name — count(open ...)
• a property name inside a where — where url contains "..."
• an aggregate field name — sum(amount of ...)

That is all. Everywhere else, names are either qualified (attr.x, activity.x) or quoted ("onboarding"), and neither can be confused with a keyword — so neither is restricted.

It is also why the set can grow without breaking your files. The call webhook statement brought four new words with it — call, webhook, as, failed — and every quoted name in every existing workflow went on meaning exactly what it meant before. A new keyword narrows only the three bare positions above; a quoted string was never a candidate for a keyword in the first place, which is the whole reason topics, templates, lists and webhook keys are quoted.

This is why all of the following are perfectly legal:

attr.count = 5 and in list "segment"

workflow "Reserved words are fine when quoted" v1 {
  enter on segment "trial-started"

  // A topic called "timeout" is a string, so it cannot collide with anything.
  send "welcome" via topic "timeout"
}

And why this is not:

exists(within within 7d)

"within" is a reserved word and cannot be used as an event name

The parser cannot tell whether that first within is an event called within or the start of a window. So it is rejected, and the error says exactly why.

SendQL

SendFlow

SendFlow reserves everything SendQL does, plus its own workflow keywords.

Two words that are not reserved

attr and activity are not reserved words. They are qualifiers, and they are only meaningful directly before a ..

Which is exactly why attr.count works: count is reserved, but the name being parsed there is not a bare count — it is the property half of a qualified reference, and the qualifier has already told the parser what to expect.