11.3 Conditional Logic & Decision Objects

Conditional Logic and Decision Objects

Conditional logic translates business rules into predictable outputs. The Associate Developer exam expects developers to interpret an expression as well as build one. Start by identifying the input types and asking which branch applies to a concrete value. Then test boundary and missing-value cases rather than relying on a vague description such as high priority.

Use if() for a Boolean choice, choose() for a controlled one-based option index, and a!match() for several readable condition/result alternatives. A decision object expresses a policy as a table of inputs, conditions, and outputs. These are related tools, but they have different contracts.

Binary Logic with if

The expression if(condition, valueIfTrue, valueIfFalse) returns the selected branch. Keep the condition Boolean and make its meaning explicit. For an original example policy, a request amount of at least 1000 requires review:

if(
  a!isNullOrEmpty(ri!amount),
  "AMOUNT_REQUIRED",
  if(ri!amount >= 1000, "REVIEW", "STANDARD")
)

With amount 999 the output is STANDARD; at 1000 it becomes REVIEW. With null input it is AMOUNT_REQUIRED. The guard makes missing input an explicit outcome instead of silently treating it as an ordinary request. These outputs are illustrative business choices, not built-in Appian statuses.

Indexed and Multi-Condition Choices

choose() selects among results using a one-based index. It is appropriate when the input already represents a controlled option number. Validate the index domain; do not rely on an out-of-range value to provide a business fallback. When the requirement is based on several conditions rather than an index, a match or decision is usually clearer.

a!match(
  value: ri!status,
  equals: "DRAFT", then: "Editable",
  equals: "SUBMITTED", then: "Under review",
  equals: "CLOSED", then: "Read only",
  default: "Unknown status"
)

Read the conditions in their configured order and identify the first matching result. If more than one condition could match, put intentional priority into the design or remove the overlap. Keep a default that makes unexpected values visible. Do not mix side-effecting process operations into a rule intended only to classify an input.

Null, Empty, and Whitespace

Appian's a!isNullOrEmpty() checks null, an empty string, or an empty list. A string containing spaces is not empty. To reject whitespace-only text, normalize it deliberately:

a!isNullOrEmpty(trim(ri!name))

This example assumes a Text rule input. Test null, empty text, spaces, and a real name. Do not use an invented isblank() function or assume that every empty-looking collection is equivalent. A list containing one null item is a different data shape from an empty list.

Avoid using presence checks as complete business validation. A nonempty account number may still have the wrong length or belong to an unauthorized customer. Normalize, validate the required structure, and then apply the business condition.

Build a Decision Table

A decision object is appropriate for a policy combining several dimensions. A shipping policy might use destination region, service level, and weight to return a handling category. Define typed inputs and outputs, then enter rows reflecting the policy. Use notes to explain unusual rules and make thresholds clear enough for a business reviewer.

Single-output decisions return that output's type; compound outputs return a structured value. Rule Order policies return multiple results. Document the expected shape so a calling rule does not treat a list of decisions as one scalar classification.

Select the Hit Policy

Unique does not mean one row must match every imaginable input. With no match and no default output, a decision can return null or an empty list according to its output type. Supply an intentional default where the application requires a complete result.

For First, row ordering is part of the policy. A special handling override belongs before a general service rule. For Rule Order, verify that the caller can consume multiple outputs. Summing or displaying all results is a separate operation; the decision does not infer the desired combination.

Worked Policy Review

A company routes requests using amount and an urgent flag. The first row handles urgent requests, the second handles ordinary requests above the review threshold, and the remaining default handles standard work. First permits the urgent override to win even when the amount also exceeds the threshold.

Test an urgent high-value request, an ordinary high-value request, an exact-threshold request, and missing input. If the policy should return every applicable review reason instead, select Rule Order and adjust the caller to handle a list. Changing only the hit policy can change the output shape and downstream behavior.

Choose Between a Rule and a Decision

Use an expression rule for list transformations, calculations, query wrappers, or reusable function composition. Use a decision when a tabular input/output policy makes conditions and overlaps easier to inspect. Interfaces render the outcome; process models orchestrate the resulting work. Keep the policy in one authoritative object rather than copying thresholds into every screen.

Takeaway: State the input contract, choose the appropriate conditional tool, and verify boundaries, missing values, overlap, and output cardinality.

Sources checked 2026-10-18: decision hit policies, decision output behavior, and null/empty checks.