Understand how Appian Handles Decisioning Concepts

RE: Understand how Appian Handles Decisioning Concepts

Stefan Helzle — Wed, 19 Apr 2023 06:11:52 GMT

A NBA/NBO concept does not exist in Appian. Instead, you have the freedom to use the available building blocks to implement what you need.

RE: Understand how Appian Handles Decisioning Concepts

JUMMIDI VINAY — Wed, 19 Apr 2023 06:11:44 GMT

Hi Sanchit Gupta,

thanks for response ,

Basically our question here not about Customer Categories. we would like to understand how does we handle NBA(Next Best Action) or NBO(Next Best offer) to customer in Appian BPM tool.

As BPM developer, i had worked other BPM tool where it does have the separate developer studio to configure NBA/NBO and its associated configurations. Now i would like to do the similar implementation in Appian too

RE: Understand how Appian Handles Decisioning Concepts

JUMMIDI VINAY — Wed, 19 Apr 2023 06:07:54 GMT

Hi Stefan,

thanks for response ,

Basically our question here not about creating decision tables or expression. we would like to understand how does we handle NBA(Next Best Action) or NBO(Next Best offer) to customer in Appian BPM tool.

RE: Understand how Appian Handles Decisioning Concepts

davel001150 — Mon, 17 Apr 2023 15:23:58 GMT

If the decision point comes in a process model, you'd use the XOR gateway. A user is either frequent or not frequent, and can't be both simultaneously, so XOR.

RE: Understand how Appian Handles Decisioning Concepts

davel001150 — Mon, 17 Apr 2023 15:22:22 GMT

I honestly wonder if this isn't way overthinking.

It looks like you only have 2 categories of users: frequent and non-frequent. (You could have 3 if you wanted, including former-frequent if there should be special deals to get them ordering a lot like they once were.)

It looks like you only have 2 categories of offers: those for frequent, those for not frequent. (Could possibly have 3.)

Behold, the if() function.

if(

local!ordersInPastMonth > 12 [I don't know what constitutes a frequent user, but whatever business rule it is],

a!update(ri!customer, "status", "frequent"),

{}

)

Then elsewhere in the code, if(ri!customer.status = "frequent", rule!offersForFrequent(), rule!offersForNotFrequent() )

You can also use curly brackets to cause a list of things to result from a clause in the if statement. All these if true, all those if false.

You could go to Decision object, but I honestly don't even see how all that is necessary. If function works quite well for most circumstances, then there's always a!match after that, and then you can decide between Decision or complex expression if it's more than a!match can handle. This case doesn't even seem like a!match sized.

RE: Understand how Appian Handles Decisioning Concepts

sanchitg0002 — Mon, 17 Apr 2023 07:49:17 GMT

You can categorize your customers into different categories on the basis of their count of successful orders. Then you can create a decision which will take categoryType as input and in result give a list of offers.

We need more details about the actual use case...

RE: Understand how Appian Handles Decisioning Concepts

Stefan Helzle — Mon, 17 Apr 2023 07:44:18 GMT

In general, simple decisions can be made using decision tables. More complex ones use expressions.

While I miss some details in your explanation, a design could be to use an expression to fetch the data from DB. Then use a foreach to feed each into a decision table. Next, take the result and create Coupon Record items as required. Call these expression in a process model to store the data back to the DB.