Understand how Appian Handles Decisioning Concepts

Certified Lead Developer

Hi team,

I have a flow where in which I have to create a offer or Coupon to a set of customers who have that eligibility.

Example:

In Swiggy or Zomato (Food Delivery App) , Some coupons like Welcome or Save60 offers are Available for New customers.

but if the customer  who frequently make orders should get some different Offers so for that 

1. I  have to make a dataset of customers who make orders frequently.

2. create some different offers for those dataset.

3.enable that offers in some channel.

This is how I did when I Implemented with different BPM tool those are done by Decisioning capabilities of that Tool.

Now iam trying these same flow in Appian . Can i get any help in understanding  how these are done in appian as  I am new to this , I couldn't able to get any decisioning Rules other than Decision (Table).

I want to know how datasets & Channels are configured and how offers are created.

Mainly I have to understand how Appian Helps in Solving Decisioning Concepts like in above case.

Thank you,

J Vinay

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    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.

Reply
  • 0
    Certified Lead Developer

    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.

Children
No Data