Appian allows you to capture complex, business-specific logic in a zero-code, easy-to-read format with the decision design object.
Decisions are configured in the decision designer, which enables fast, intuitive implementation of business logic by way of decision tables.
On this page, you can learn about Appian decisions and what they can do for your applications, along with some Common Uses for Decisions. For other topics related to decisions, see:
Decisions are configured with decision tables based on the open Decision Model and Notation (DMN) standard. Business users and application developers alike can quickly configure business rules in the familiar decision table format using industry standard logical operations.
Testing your decisions are as easy as configuring them. The decision designer empowers you to continuously test and debug your decision inline as you are designing it by giving you rapid feedback on what a set of inputs will evaluate to and visualizing how your decision gets to that result.
In addition to allowing fast and intuitive configuration of your decisions, the decision designer helps you create smarter decisions with a host of validations and recommendations that help make sure your decisions will work correctly.
These include:
Decisions are easy to use without sacrificing the power you've come to expect with Appian. A number of advanced features allow for achieving complex use cases.
These features include:
As part of the Appian platform, decisions are available for use anywhere, across all your applications.
For example, you can:
With their easy configuration and extensive feature set, decisions can be used in a variety of different ways within your applications. You can use decisions to simplify other areas of application design like task assignment, dynamic process execution, record or action permissions, or even to determine a list of items.
This section highlights some common scenarios in applications today that require logic and describes how Appian decisions can be used to simplify the design and implementation of these use cases.
It is very common for different types of case or request management applications at a business to require specific levels of approval. Since decisions can output Appian Objects and be called from anywhere (included processes), the entirety of the approval logic can be stored in a single place in an easy-to-read format.
Below is an example of a purchase request approval decision that determines what group of users need to approve a purchase request before it is finalized.
The output of this decision will be the group that we'll want to assign the approval task to so we can go ahead and call this decision directly in the Assignment tab of the User Input Task node:
There are times where you might want a decision to return more than just a single type of value.
For example, you might have an interface where users apply for a credit card. Using the information they provided you can decide whether they get approved for the card or not, but you can also determine what message to display on the next page of the form, all from a single Decision. Having more than one output type in a decision is called a compound output.
Your decision could look like this:
Notice how the decision's output above is a dictionary consisting of two fields, isApproved
and notification
.
The first field is a boolean value to determine whether the application should go to the approval step or rejection step and the second field's value is a message to display on the interface with any details pertaining to the credit card approval decision for that user.
In the examples above you can see how decisions, using the powerful features like Appian object output types and compound outputs, can reduce the complexity of your application logic. The example below will use both features to take an even more complex case and simplify it dramatically.
Many applications require the ability to route processes based on a variety of data inputs, the routing might consist of many different possible flows. If we wanted to create a process that routed car insurance claims based on information about the driver such as the region they live in, their age, and whether they are a high risk driver while also flagging the driver as high risk for future claims processing, we might implement it in Appian like this:
With decisions, we can consolidate all of this logic into one central place. The below decision takes information about the driver and then determines which regional claims process should be executed and determines all of the process parameters that should be passed into that process, such as, which insurance agent should be assigned to the claim and whether the driver should be flagged as "high risk" the next time they file a claim.
Using this decision with the Start Process smart service, we can pass the decision's result into the smart service to dynamically determine which process to start and what parameter values to pass into the process. The routing process model above can be simplified to just a single script task that calls the decision and a Start Process smart service node.
Decision Tables in Appian