Appian a!match()

The shape

a!match() takes one value and a list of conditions, each followed by what to return when it matches, then a default for when nothing does.

a!match(
  value: status,
  equals: "O", then: "Open",
  equals: "C", then: "Closed",
  default: "Unknown"
)

It is the answer to the nested if() ladder from the first lesson: the same logic, written flat, one outcome per line.

Two kinds of condition

• equals — matches when the value is exactly this
• whenTrue — matches when a condition holds. Inside it, fv!value is the value being matched

Every condition is followed by its own then, and you can mix both kinds in one call:

a!match(
  value: score,
  whenTrue: fv!value >= 90, then: "A",
  whenTrue: fv!value >= 60, then: "C",
  default: "F"
)

fv!value also works inside then and default, so the result can use the value it matched.

First match wins, and the rest never run

Conditions are checked top to bottom. The first one that matches decides the answer, and everything after it is not evaluated at all — the same short-circuit if() has. A later branch can safely divide by something an earlier branch has already ruled out.

The trap: order decides ranges

Because the first match wins, whenTrue ranges must go from tightest to loosest. Put fv!value >= 60 above fv!value >= 90 and a 95 matches the first one it reaches and comes back as a C. Nothing is wrong with either condition; they are in the wrong order, and no error tells you.

Also worth knowing

• equals compares text case-sensitively, so "b" does not match "B". That is the opposite of the = operator, which Appian documents as case-insensitive — so rewriting an if(x = "B", ...) as a!match() can quietly change which values match
• default is required. Leave it off and the call fails rather than returning null
• Every argument needs its keyword. Appian states that keywords are required, because the pairs are recognised by name