11.3 Conditional Logic & Decision Objects

Appian Certified Associate Developer ACD101

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Architecture & Environments

1.1 Appian Platform Architecture & Core Capabilities 1.2 Appian Designer, Applications & Object Containers 1.3 SDLC Environments, Deployment & Community Resources

2 Chapter 2: Security & Platform Governance

2.1 Group Hierarchies & Role-Based Access Control 2.2 Design Object Security & Dependency Tracking 2.3 Appian Design System & UX Governance

3 Chapter 3: Relational Data Modeling & CDTs

3.1 Custom Data Types (CDTs) & Schema Design 3.2 Data Stores, Entity Mapping & Table Publication

4 Chapter 4: Data Persistence Operations & Query Entity

4.1 Querying Relational Data with a!queryEntity 4.2 Data Modification & the Write to Data Store Entity Smart Service

5 Chapter 5: Records Architecture & Data Fabric

5.1 Record Types Architecture & Synced Data Sources 5.2 Record Relationships & Custom Record Fields

6 Chapter 6: Record Views, Actions & Record Queries

6.1 Record List Configuration, Headers & Views 6.2 Record Actions & Querying Records with a!queryRecordType

7 Chapter 7: Process Model Architecture & Task Design

7.1 Process Model Canvas, Lanes & Process Variables 7.2 User Input Tasks, Activity Chaining & Assignment 7.3 Script Tasks & System Smart Services

8 Chapter 8: Process Orchestration, Sub-Processes & Exception Handling

8.1 Workflow Gateways & Branching Logic 8.2 Sub-Process Design: Synchronous vs. Asynchronous 8.3 Process Escalations, Deadlines & Exception Events

9 Chapter 9: SAIL Interface Design & State Management

9.1 SAIL Framework & Component Hierarchy 9.2 Local Variables & Dynamic Refresh Behaviors 9.3 Rule Inputs, Component Parameters & Two-Way Binding

10 Chapter 10: Advanced Interface Components & Sites

10.1 Read-Only Grids and Editable Grid Layouts 10.2 Form Validations, Error Handling & Dynamic Display 10.3 Appian Sites, Navigation & Portal Configuration

11 Chapter 11: Expression Rules & Functional Data Manipulation

11.1 Expression Rule Architecture & Function Namespaces 11.2 List Processing & Looping with a!forEach 11.3 Conditional Logic & Decision Objects

12 Chapter 12: Query Optimization, Testing & Debugging

12.1 Expression Rule Testing, Assertions & Test Cases 12.2 Query Construction & Performance Best Practices 12.3 Error Handling, Type Coercion & Expression Debugging

11.3 Conditional Logic & Decision Objects

Key Takeaways Explain This Topic AI

a!isNullOrEmpty does not classify whitespace-only text as empty; trim text when the policy requires that normalization.

Decision policies are Unique, First, and Rule Order; First gives intentional row priority.

Unique forbids overlapping rules but does not guarantee a match for every input.

Rule Order produces multiple results, so the calling expression must handle the corresponding output shape.

Last updated: October 2026

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.

Input Useful question

null Was any value supplied?

empty text Has the text been cleared?

spaces Should text be trimmed under the business rule?

empty list Are there any items to process?

populated map with null fields Are the required fields valid, rather than merely the map existing?

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

Policy Matching behavior Suitable requirement
Unique Conditions must not overlap Exactly one permitted classification rule
First Returns the first matching row A prioritized override followed by general rules
Rule Order Returns matching outputs in row order Several applicable reasons or categories

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 .