expression rule vs decision

Hi Krisk,

The documentation clearly mentions the details of the decision tool.
docs.appian.com/.../Appian_Decisions.html.
I prefer using this when compared to Expression rules.
1. Easy of Configuring the business rules when compared to Expression rules.
2. Easy to debug.
3. Easily Understandable to the other developers.

Apart from the above User can configure dynamic process execution based on the set of businessrules. This will avoid complex process model design with XOR gate and with the help of this, we can avoid the changes to PM and publishing that PM.

I would suggest to dive deeper in to that link so that you will get good picture of it.

You can create a rule folder for these and store them in that folder.
You can also call the decision rule like any other expression rule.
docs.appian.com/.../Decisions.html

Where are these decision rules are going to stored. Do we have access these tables -- I'm not sure where they are storing these, lets see other practitioners are aware of these.

First link is not working.

Thanks

An updated link: docs.appian.com/.../Decisions.html

I agree with Chandu , there are many scenarios where we need to write lots of logic to implement if-else-if condition and it also decreases the readability of code .It also provides notes column for documentation purpose.

Decisions sound like a good idea on paper, and I'm sure there are a ton of real-world use cases, but every time I've sat down to implement something using a decision, i've ended up having to bail out and do it in a traditional expression rule, either because decisions aren't expressionable, or just plain not flexible enough. I'd love to hear how others have gotten around this, becuase maybe I've been missing out.

Hi krisk,
Expression rules are mainly used to build the business logic.Expression rules can be reused across multiple objects throughout the system.There are 2 ways to test the rule in the expression rule designer adhoc testing and test cases.Expression rules commonly validate that a value is what is expected in a process or interface. It is also used to manipulate a complex data type or Appian object input which could result in varied outputs. Where as for Decision:

Decision: 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.
("Decisions can be exposed to certain users in a limited editing mode that allows these users to update the business rules of the Decision but not change the structure of the Decision (to limit the affects of all the other application objects using the Decision").

I would suggest you to create your own expression rule and decision by following the steps which were mentioned in the documentation, so that you will get to know the difference in detail.

Thanks,
ravalik

Hi krisk,



One of the use cases where we implemented a Decision table was to set the "required", "disabled" and few other properties of UI form components.

The UI form consisted of several fields that required user indexing. Based on user selection of a couple of fields some fields had to be mandatory and some other fields had to be disabled and so on...

A decision table was created that takes two fields as input and then returns multiple boolean values, each of which indicate a certain property (required/disabled/etc.,) for a SAIL component.

The Business Analysts in the team were given access to this decision table to configure the scenarios as per the business requirement.

Since using a decision table is straight forward and real-time, it is very convenient to maintain business logic and adapt to frequent requirement changes.



Regards,

Sunil Zacharia

I agree with Mike.
I recommend / use decision tables when they are 'clear cut' and replace a 'simple nested if'. When I need to do more complex things (need things to be expression-able, I use expression rules.

Decision Tables are a step to give more power to the 'Citizen Developer'. So, in workshops with the business, they are great. In actual implementation, I use them where very straight forward.

Just to add to this - worth considering that decision tables give zero audit history for decisions other than the version history, so if knowing what the settings were in the past is important, decision tables may not suit. That said, it's possible to use something like from/to (implementation) dates so that a setting is used depending on the date that is passed in, but this may not suit all implementations.

Hi ,
When we have many factors which are influencing value of a variable and writing them in if else code becomes lengthy,then its always better to write decision rule. Decision rule has better readability and easily adaptable to changes in requirement. Decision rule can be called in any expression rule .
Thanks
Namrata