Overview

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 decision objects in your applications.

Properties

Each decision object has the following properties:

Create

To create a decision object:

1. In your application, go to the Build view.
2. Click NEW > Decision.

3. In the Create Decision dialog, configure the following:

   Property	Description
   Name	The name that is used when evaluating the decision.
   Descriptions	A short description about the decision object.
   Save In	The rule folder that the decision is saved into.

4. Click CREATE.

The decision object opens in a new tab or window.

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 represents 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 represents 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, for example, < 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.

Inputs

The input description can be seen by hovering over the question mark icon by the input name. If there is no question mark icon, it means no description was added to that input.

The following types are available for decision 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.

Outputs

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

Compound output

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.

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 decision, the last row in the decision table is used to define the default output. The default output will be returned when the decision is evaluated but there are no matching rows.

Use defined lists

Values for an input or output can be selected from a list instead of being specified free-form.

To use a defined list to configure an input or output:

1. On an input or output, click .
2. Click Edit Input.

3. In the Edit Input dialog, select the Use a dropdown to list values you can select for this input/output checkbox.

   

   

4. Choose to configure the list of options using:
   • Choice Values: 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.
   • Edit as an expression: Click this button to use an expression to generate the list of values for the input or output. 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.

   Note:  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 option, only reference values that will be consistent across all of your environments.

5. Click OK.

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 execution 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:

Hit policy

The hit policy of a decision specifies what the result of a decision is in the cases of overlapping rules, that is, 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:

Test

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.

In the Test Inputs pane, add sample test values for each input and click Test to evaluate the decision and display the type and value of the result.

To save a default value for your test inputs, click Set as default test values. 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 Admin Console.

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

While editing your decisions you may encounter guidance. Appian design guidance reinforces best practice design patterns that should be implemented in your objects. Guidance is calculated while editing expressions within the decision or when a precedent of the decision is updated.

In addition to supporting general expression guidance, the decision designer helps you create smarter decisions with the following decision specific 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

The designer also checks for completeness of your decision logic and identifies gaps in your logic. This design information is meant as a suggestion for helping you craft more robust decisions and does not affect the evaluation of a decision.

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. Hover over the icon to display a tooltip that identifies values which that input does not have logic accounting for.

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.

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

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

Versions

Each time you modify and save a decision, a new version is created. All objects that use the decision will 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 information on how to manage object versions, see Managing Object Versions.

Move

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 appears.

4. Use the folder picker or browser to select the new parent folder.

   Tip:  You can also create a new folder in the browser, if you have Editor permissions to its parent folder.

5. Click Move.

Duplicate

Developers with Viewer permissions to this object can duplicate it. There are two ways to duplicate an object:

• From any view in an application, you can select the object you wish to duplicate and use the toolbar option to launch the duplication dialog. The duplicated object will be added to the application you're working in. This capability is only available for single object selections from the grid.
• If you are in an interface, expression rule, integration or decision object, you can select Duplicate from the object's settings menu . From there, you can specify the target application for the new object.

Once you select the Duplicate option, you will see the following dialog:

You can only duplicate the most recent version of an object. If you have unsaved changes and attempt to duplicate the object from within the designer, the most recent saved version of the object will be duplicated without the unsaved changes. A banner appears when there are unsaved changes to remind you before duplicating.

Delete

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 permissions 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. In your application, go to the Build view.
2. Select the checkbox of the decision you want to delete.
3. Click Delete.
4. Review any object dependents and click DELETE.

Import

As part of your app deployments, decision objects can be exported and then imported into another environment. If you define inputs using an expression with constants and set those constants with an import customization file, you will need to reset these values in the decision object after it is imported. The constant values set in the ICF are not applied for decisions.

Security

The security role map of a decision controls which developers can see or modify it and its properties. By default, decisions inherit the security of the folder that they are saved in. However, after creating the decision, you can disable that inheritance and modify the decision's security. See Editing Object Security to modify a decision's security.

The following table outlines the actions that can be completed for each permission level in a decision's security role map: