Decision Object output calculated value

Decision Rules cannot conduct the kinds of calculations you're describing, but Expression Rules can. Why is an Expression Rule not fit for purpose here? 

Yes, Expression rules can work but these expressions would change per client

E.g:-

Client A = 10 % FeeAmount + Surcharge + Tax

Client B = 12 % FeeAmount + Tax

Client C = 5 % FeeAmount + Surcharge 

Client D = FixedAmount+ Tax

These expression are supposed to be created by analyst

How to associate these expression rules to each client? 

How do we execute these expression rules based on client id dynamically? 

You can parameterise the Expression Rule. The calculation is conceptually always the same:

variablepercentage * FeeAmount + Surcharge + Tax

For the Clients where the Surcharge doesn't apply simply pass in 0 as the value

Where the tax doesn't apply also pass in as zero

The values that apply to each Client should be held where they can be changed so probably in a database table where they can be created/updated/read.

Thanks for the reply,

Here I mentioned few examples but actual calculations, variables and conditions would differ for each client, writing a single expression rule to support all the clients would be a difficult task and could be maintenance night mare.

is there any way I can save applicable expression rule name, variables and values in the database for each client and evaluate the expression at runtime?

Is there genuinely no abstraction that fits all the Clients? That is, a superset of all the possible parameters used to calculate for all the Clients, where you can set those that don't apply to zero? Or maybe two or three 'types' into which a Client will fit into?

Is there genuinely no abstraction that fits all the Clients? That is, a superset of all the possible parameters used to calculate for all the Clients, where you can set those that don't apply to zero? Or maybe two or three 'types' into which a Client will fit into?

we can come up with few abstractions and statically execute the abstraction based on client type with super set of parameters. 

when a new client is added we may need to add additional abstraction and update process model to accommodate the new abstraction.

It's possible you may be able to design this in such a way as to avoid having to ever make changes to the process model. An Expression rule can take arrays as parameters, and each parameter instance could be a list in its own right. So you could pass in a list that maybe looks something like this:

{
    {name: "feeAmount", value: 100, type: "seed"},
    {name: "feeAmountPercentage", value: 10, type: "percentage"},
    {name: "surcharge", value: 50, type: "addend"},
    {name: "tax", value: "150", type: "addend"}
  }

and use the fn!reduce() and write a rule that you use in the reduce that applies each value as instructed e.g. if your rule sees that type is "seed" it simply echoes back that value as the running total, if it sees the type is 'percentage' it applies the percentage to the running total, if it sees the type is 'addend;' it then adds the value to the running total. You'd have to take care to only ever have the "seed" as the first item in your list, and your calculation would be applied in strict sequence order NOT in the purist BODMAS order of evaluation.

You could also combine the functionality of decisions and expression rules. For example, you could create a decision that returns the expected fee amount, percentage, surcharge, and tax as an array of outputs. Then, create an expression rule which takes result of the decision and performs the calculation. Then, you get the best of both worlds: the ease of use of the decision and the flexibility of the expression.