Decision Object

What is a decision?

A decision is a design object that captures business rules and logic in a table. A decision table takes input values, looks for matching rows, and returns the outputs associated with the matching rows.

Each column in the decision table 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 returns the output values specified for that row.

For example, to determine the legal drinking age:

A decision object in Appian can capture the rules of a decision table in an equally readable format:

A decision object can be referenced in other objects. To learn about referencing decisions and other objects, see Referencing Objects in Expressions.

When to use a decision

Use a decision object when you need to:

• Encapsulate business policies: Capture and manage complex business rules in a central, readable location.
• Determine outcomes from multiple criteria: Evaluate multiple input values to return the correct output, such as calculating an insurance premium.
• Determine task assignment: Route approvals or tasks to specific groups based on business rules, such as purchase request thresholds.
• Expose business rules as a service: Make decision logic available to external systems via web APIs.

Determining task assignment with a decision

Decisions can output Appian objects and be called from anywhere, including processes. The entirety of approval logic can be stored in a single decision in a readable format.

For example, a purchase request approval decision can determine what group of users needs to approve a purchase request before it is finalized:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

The output of this decision is the group to assign the approval task to. Call this decision directly in the Assignment tab of the User Input Task node:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Driving logic and interfaces with a single decision

Decisions can return more than a single type of value using a compound output. For example, a credit card application decision can determine whether a user is approved and what message to display on the next page of the form, all from a single decision:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

The decision's output above is a dictionary consisting of two fields, isApproved and notification. The isApproved field is a boolean value to determine whether the application should go to the approval step or rejection step. The notification field's value is a message to display on the interface with details about the credit card approval decision for that user.

Dynamic process execution with a decision

Decisions can use Appian object output types and compound outputs to reduce complex process routing. For example, a car insurance claims routing process that routes based on the driver's region, age, and risk status might look like this without a decision:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

A decision can consolidate all of this logic into one central place. The decision below takes information about the driver and determines which regional claims process to execute, which insurance agent to assign, and whether to flag the driver as high risk:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Using this decision with the Start Process smart service, pass the decision's result into the smart service to dynamically determine which process to start and what parameter values to pass. The routing process model above can be simplified to a single script task that calls the decision and a Start Process smart service node:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Elements of a decision

A decision object is divided into two panes:

• Configuration pane
• Test Inputs pane

Configuration pane

The configuration pane of a decision object contains the following elements:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

#	Element	Available Actions
1	Hit policy selector	Select a hit policy that determines what a decision returns when more than one business rule matches the inputs.
2	Input	Configure input that will be used to pass data into the decision. Each cell in an input column must be configured with a logical operation and value for that particular input type.
3	Output	Configure the values that are returned when a decision is evaluated. Each cell in an output column can be configured with a value for that particular output type.
4	Notes	Add comments and information for each decision rule. The information in this column is not used when the decision is evaluated.
5	Actions	Perform additional actions on decision rules.
6	Decision rules	Configure decision rules. 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 object. The decision output is used to specify what the decision returns if a particular row's logic matches the passed-in input values.
7	ELSE	Define the default output to return if no rules match the inputs.
8	Add New Row	Add a row for a new decision rule.

Test Inputs pane

The Test Inputs pane contains a field for each input configured for the decision.

Enter sample values in each field to test your decision.

For example:

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Decision security

Object security for decisions is configured through role maps. By default, decisions inherit the security of the folder they are saved in. You can override that default by editing the decision's security.

Any user can invoke any decision that is used by an interface or process they can access.

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

Actions	Administrator	Editor	Viewer	Deny
Evaluate the decision	Yes	Yes	Yes	Yes
View the decision definition	Yes	Yes	Yes	No
Duplicate the decision	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	Yes	Yes	No	No
Rename the decision	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

Common decision options

A decision supports the following common design object options:

• Versioning: Decisions support versioning.
• Renaming: Decisions can be renamed.
• Viewing Appian design guidance: Decisions support Appian design guidance.
• Duplicating: Decisions can be duplicated.
• Viewing performance details: Decisions support viewing performance details.
• Object overwrite protection: Decisions support object overwrite protection.

To view options available from the toolbar in Appian Designer, see Common view elements.

Create a decision

For step-by-step guidance on how to build a decision, see Create a Decision.

Edit decision properties

To edit a decision's properties:

1. In the Build view, select the name of the decision. The decision opens in a new tab.
2. Open the settings menu .
3. Select Properties.

4. Edit the following properties:

   Property	Action
   Name	Enter a name for the decision. This name is not case sensitive, but we recommend following the Standard Object Names convention. The decision name must be unique in the Appian environment.
   Description	Enter a short description for the decision. This text displays in the expression editor and in the objects grid of some Designer views.
   Save In	Select the rule folder that the decision is saved into.

5. Click OK to save your changes.

Delete a decision

Deleting a 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 process reports.

Decisions can be deleted by users with Administrator permissions for the decision. Appian does not recommend deleting decisions that are in use because the decision can no longer be edited or deployed.

To delete a decision:

1. In the Build view, select the checkbox next to the decision's name.
2. Click DELETE in the toolbar. System administrators can delete multiple objects at once.
3. Review the list of dependent objects to verify that you want to continue with the deletion. See the impact of deleting objects that rely on each other for more information.
4. Click DELETE to confirm.

Duplicate a decision

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.

Move a decision

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.

Deploy a decision

As part of your app deployments, decisions 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 must reset these values in the decision after it is imported. The constant values set in the import customization file are not applied for decisions.

Decision related resources

• Create a Decision: Step-by-step guidance on creating and configuring a decision for use in an application.
• Expression Rules: Expression rules are used for calculating or manipulating data, as opposed to decisions which handle business logic.
• Expressions: Decisions can be called from any expression using the rule! domain.

Feedback