Decision Object


A Decision is a grouping of business rules that determines output values based on a set of inputs. Unlike expression rules, which primarily calculate or manipulate data, Decisions are best used to encapsulate complex, business-specific logic. Decisions are configured in the decision designer, which enables fast, intuitive implementation of business logic without using expressions by way of decision tables.

Decisions can be called from any expression, so they can be reused across multiple objects throughout the system.

Each time you modify and save a Decision, a new version is created. All expressions that use the Decision use the latest version. All versions are accessible to designers who can view the Decision, and a Decision can be reverted back to a previous version at any time.

For step-by-step guidance on how to build your first Decision, see the Create a Decision page.

For examples of different Decision use cases, see the Appian Decisions page. These examples will help you understand how you can leverage Decisions in your applications.


Each Decision has the following properties:

Property Name Description
Name The name that is used when evaluating the Decision. Names are case-insensitive and must be unique across Decisions, interfaces, expression rules, query rules, constants, and functions.
Description Supplemental information about the Decision that is displayed in the inline help within the expression editor and the application contents grid.
Save In The rule folder that the Decision is saved into.
Inputs Inputs are used to pass data into the Decision.
  • Name: The name that is used for referencing the input when passing arguments by keyword. Input names are case insensitive and must be unique within a given Decision.
  • Type: The type of the Input.
Decision Outputs Decision outputs are the values that are returned when a Decision is evaluated.
  • Name: The name that is used as the field name of for the output value when the Decision returns a dictionary. Output names are case insensitive and must be unique within a given Decision.
  • Type: The type of the Decision output.
  • Array: Decision outputs can be either a single value or an array of values.
Decision Definition The business logic that is defined as a decision table. The input values passed into the Decision are used to evaluate this logic to determine what rules in the table match. More information about how to specify this logic is below.
Hit Policy Determines what a Decision returns when more than one business rule matches the inputs.

Decision Basics

The logic of a Decision is configured using a decision table. In a decision table, each column is either an input to the Decision or one of its outputs. Each row in the table respresents a decision rule, in which each cell is a logical operation. When all the cells' conditions for a particular row are true, the Decision will return the output values specified for that row.

  1. Decision rules as rows - Each row in the table respresents a decision rule, in which each cell is a logical operation. Each row starts off with a row number that is used to identify the row throughout the designer.
  2. Input - Inputs to the Decision are represented as columns with a white background. Each cell in an input column must be configured with a logical operation and value for that particular input type.
  3. Decision output - Outputs to the Decision are represented as columns with a gray background right after all the input columns. Each cell in an output column can be configured with a value for that particular output type.
  4. Hit policy indicator and menu - The top left cell of the decision table identifies which hit policy the Decision is defined with.
  5. Input cell (or input entry) - Each input cell in the decision table corresponds to a logical operation that is evaluated with the value passed into the input at execution time. The cell consists of two sections: a dropdown for choosing what type of logical operation the cell will evaluate, and a value field to define the value that completes the logical statement, e.g. < 10.
  6. Notes - This column is used only for documenting notes about the logic of each row for the designers of the Decision. The information in this column is not used when the Decision is evaluated.
  7. Default output - The "Else" row in your table returns your decision's default output. The default output will be returned when the decision is evaluated but there are no matching rows.


The following types are available for Inputs:

  • Boolean
  • Date
  • Number (Decimal)
  • Number (Integer)
  • Text

A Decision is invalid if not all of its input values are defined. When a Decision with undefined values is evaluated, it will fail to return a value. The decision designer helps you identify if there are any missing or invalid values when you test and save your Decision.


The Decision output is used to specify what the Decision returns if a particular row's logic matches the passed in input values. Decision output columns are indicated by a gray background.

The following types are available for Decision outputs:

  • Boolean
  • Date
  • Document
  • Folder
  • Group
  • Number (Decimal)
  • Number (Integer)
  • Process Model
  • Text
  • User
  • User or Group

Decisions that are defined with Appian Objects as output values will have these objects identified as precedents to the Decision. Appian recommends only using objects that will exist in all of your environments for your Decisions.

Like inputs, a Decision can have multiple outputs. This is considered a compound output. When a Decision has a compound output, it will return a dictionary with fields that correspond to each output column of the Decision. The field names in the dictionary are the output names specified in the Decision.

Decisions have an explicit return type, this helps designers understand what to expect when integrating the Decision into their applications. The return type is displayed in the inline help within expression editors along side the Decision's description and inputs. A Decision's return type depends on the type of output, whether it has a compound output, and its hit policy.

Hit Policy Compound Output Output Type
Unique, First No The type defined in the Decision's single output column. Available types are listed above.
Unique, First Yes Map
Rule Order No The type defined in the Decision's single output column. Decisions with the Rule Order hit policy must output an array type.
Rule Order Yes List of Map

When a Decision is evaluated but there are no matching rows and no default output is defined, the Decision will return either a null of its output type or an empty list of its output type if it is an array type (which is determined by the scenarios outlined in the table above).

Default Output

In the Decision Model and Notation (DMN) standard, you can specify a default output for your decision. In the Appian decision designer, the last row in the decision table is used to define the decision's default output. The default output will be returned when the decision is evaluated but there are no matching rows.

Using Defined Lists

Values for an input or output can be selected from a list instead of being specified free-form. The Use a dropdown to list values you can select for this input/output option in the input and output dialogs allows you to configure what values to choose from when defining that input or output. This configuration only constrains the experience of configuring the Decision, and has no effect on how the Decision evaluates.

This list of values can be defined in two ways:

  • As a list: The values are defined in a free-form, newline-separated list. This is useful for reducing the amount reentry that is necessary when specifying logic in your decision table.
  • As an expression: An expression can be used to generate the list of values for the input or output to use. The values returned from the defined expression are what are used inside the Decision when the Decision is called. This allows you to leverage application reference data that is stored in constants, a database table, or an external system just as you do throughout the rest of your application. The defined expression is not evaluated when executing the Decision, it only gets evaluated when opening the Decision in the designer and saving the individual input or output. When using this feature, it is important to only reference values that will be consistent across all of your environments. Appian objects referenced in the expressions will be identified as precedents to the Decision.

The list of values can also have optional labels for choices in the list, similar to how dropdown components are defined. These choice labels are defined the same way the values are defined and will be what represents the value in the decision table. These labels are used to further improve the ease of configuring decision rules in the table, and have no effect on the Decision's execution or output values.

Define Decision Logic

Decisions are defined in the decision designer by specifying logic in the decision table located in the main pane of the designer.

Each input cell in the decision table corresponds to a logical operation that is evaluated with the value passed into the input at exectuion time. When called, the Decision evaluates each row in order. If any cell in the row evaluates to false then the Decision stops evaluating that row. If all the logical conditions for a row evaluate to true, then that row is said to be a hit, or a match, and the Decision will result in the defined output value for that row. The Decision's hit policy determines whether it will continue to evaluate rows or finish once it has found a match.

The following logical operations are available per input type:

Logical Operator Description Available Types
= Equals. When using the list of values feature with Text and Integer types, multiple values can be selected and the operation will check if the Inputs equals any of the selected values. All
not Does not equal. When using the list of values feature with Text and Integer types, multiple values can be selected and the operation will check if the Inputs does not equal any of the selected values. All
is null The input value is null All
not null The input value is any value but null All
any The input can be any value, it is irrelevant in this row of logic. The cell will always evaluate to true. All
< Less than
Note: For Date inputs, the operator's label is "before"
Date, Number (Decimal), Number (Integer)
> Greater than
Note: For Date inputs, the operator's label is "after"
Date, Number (Decimal), Number (Integer)
<= Less than or equal to Number (Decimal), Number (Integer)
>= Greater than or equal to Number (Decimal), Number (Integer)
from Inclusive range of values. Specify two numbers, and all values in that range, including those numbers, will be in the set. For example, "from 1 to 3" means the numbers 1, 2, and 3 are in the set. Date, Number (Decimal), Number (Integer)
between Exclusive range of values. Exclusive range of values. Specify two numbers, and all values strictly between those two numbers will be in the set. For example, "between 1 to 3" means only the number 2 is in the set. This is most useful for certain types of decimal value ranges. Date, Number (Decimal), Number (Integer)

Hit Policy

The hit policy of a Decision specifies what the result of a Decision is in the cases of overlapping rules, i.e. when more than one row matches the input data. Hit policies are configured by clicking the "U" in the top left cell of the decision table in the decision designer. Appian supports a number of hit policies defined in the Decision Model and Notation (DMN) standard:

Hit Policy Description
Unique Overlapping rules are not allowed. Only a single rule can ever be matched and all rows must be unique. Unique is the default hit policy for Decisions. The decision designer indicates which rows in your Decision overlap when using this hit policy. Decisions with the Unique hit policy will fail to evaluate if they contain overlapping logic. The Decision stops evaluating after finding the first match (in rule order).
First Multiple (overlapping) rules can match. The first match by rule order is returned and the Decision stops evaluating.
Rule Order Evaluates the entire Decision and returns outputs for all matches in row order. Decisions with the Rule Order hit policy must always return an array type.


Testing your Decision in the decision designer gives you rapid feedback on what a given set of inputs will evaluate to, allowing you to quickly understand and adjust the decision to produce the exact results required. A Test button is displayed in the right pane. Clicking the button evaluates the Decision and displays the type and value of the result.

If you have one or more Inputs, you can enter values for each input in the Test Inputs section. These values are used when testing the Decision. You can save a default value for your test inputs by clicking the Set as default test values link in the designer. Once set, the default values will be saved with the decision. Default test values are always exported with the decision, but can only be imported if the destination environment has the Allow Test Values to Be Imported with Design Objects setting enabled. For more about this configuration, see the Deployment section of the Appian Administration Console page.

When testing your Decision, additional design information and validations are run and displayed on the decision table itself. See the Design Guidance and Validations section below.

Design Guidance and Validations

In addition to allowing fast and intuitive configuration of your Decisions, the decision designer helps you create smarter Decisions with the following functionality:

  • The designer immediately validates the soundness of your logic by identifying when values are invalid.
  • Upon testing and saving the Decision, decision designer pinpoints which cells are missing values.
  • Overlapping rule validations during testing the Decision identify when rules won't ever match.
  • Completeness check discovers gaps in your logic as you test your Decision

Overlapping Rules Validation

When using the Unique hit policy, the designer will highlight which of your rows overlap with each other to identify when rules won't ever be matched. When a Unique hit policy Decision has overlapping rules, it will fail to evaluate. Overlapping rules are highlighted red on the decision table and when you hover over the error icon for that row, a tooltip will appear identifying which rows it overlaps with.

Completeness Check

Additionally, when testing, the designer checks for completeness of your decision logic and identifies gaps in your logic. The completeness check icon will appear on the left side of an input's column header when there are gaps in the logic you defined for that input. Hovering over the icon will display a tooltip that identifies values that that input does not have logic accounting for. This design information is meant as a suggestion for helping you craft more robust Decisions and does not affect the evaluation of a Decision.

Completeness check identifies the following gaps:

  • When your logic doesn't account for all the items in the list of values you've configured for a given input
  • When an input of the Boolean type doesn't use both true and false values
  • When there are missing ranges of number or date values between the lowest and highest values you've configured for a given numeric or date input

The completeness check icon disappears once the identified missing gaps are covered.

Call a Decision From Another Expression

Decisions are called using the rule! domain. When calling a Decision, values or variables must be passed to the Inputs by keyword, as shown below.

rule!IQ_determineCarInsuranceQuote(age: pv!age, state: pv!state)

Decisions cannot be used inside process events, process report column definitions, or web content channels.


All versions of an object are saved and designers can view the definitions of old versions; however, when invoked, it is always the latest version that executes.

View Versions

Versions of a single object can be accessed by users with Viewer permissions, by doing one of the following:

  • Select a single object in Appian Designer and select Versions from the toolbar
  • Open the object designer and go to Versions in the Settings menu

This option opens the Versions dialog with a list of versions:

Versions dialog

Revert to a Previous Version

If you wish to revert to an older version, open that version by clicking on it and save it. This will create a new version of the object with the definition that is currently loaded in the designer. Modifying a previous version and saving it as the latest version does not affect the old version. To avoid confusion, you should close the tab from which you opened the Versions dialog, since it now contains an old version.

Delete Versions

Versions can be deleted by users with Editor permissions and if there are multiple versions. A single version can be deleted by clicking the corresponding red X in the rightmost column of the versions grid.

Bulk deletion can be done by selecting filter criteria that returns multiple versions, which causes a message to appear that prompts you to delete the filtered versions. If the latest version is included in the filtered results, it will not be affected by the bulk deletion. This allows for easier and faster cleanup of object versions, in order to maintain useful versions and prevent version buildup that may affect engine memory.

Bulk delete object versions


Users with Administrator permission to this object or rule folder can move it to another folder:

  1. Navigate to the parent folder that the object or folder is in.
  2. Select the object or folder.
    • You can select more than one.
  3. Click the Move button on the toolbar.
    • The Move Objects dialog box is displayed.
  4. Use the folder picker or browser to select the new parent folder.
    • You can also create a new folder in the browser, if you have Editor rights to its parent folder.
  5. Click Move.

NOTE: Any objects that are configured to inherit the security of the parent folder assume the security rights of the target folder.


Deleting an Decision prevents users from further viewing or editing it. However, the last version of the Decision is still available to be used in processes, record views, and reports.

Decisions can be deleted by users with Administrator rights to it. Appian does not recommend deleting Decisions that are in use because the decision can no longer be exported.

To delete a Decision:

  1. Go to an application that contains the Decision.
  2. Select it in the grid and then click the Delete button in the grid toolbar.

System Administrators have the ability to delete Decisions (and other objects) in bulk by selecting them and clicking Delete in the toolbar.


The security rolemap of the Decision controls who can see or modify the Decision definition and properties. However, Decisions can be evaluated by any user regardless of their defined role in the security rolemap.

The following actions can be completed by each role:

Actions Administrator Editor Viewer Deny
Evaluate the Decision Yes Yes Yes Yes
View the Decision definition Yes Yes Yes No
Test the Decision Yes Yes Yes No
Add, reorder, or delete rows in the Decision Yes Yes No No
Update values for existing inputs and outputs Yes Yes No No
View the security in the application designer Yes Yes No No
Add, edit, or delete Inputs and outputs Yes No No No
Edit the Decision's hit policy Yes No No No
Delete the Decision Yes No No No
Update the security Yes No No No

By default, Decisions inherit the security of the folder that they are saved in. To view or modify the security of a Decision, go to an application that contains the Decision and use the Security option in the application contents grid toolbar.