Decision Framework: Configuration

Destinations

Destinations are the decisions that your configuration can arrive at. For example, you might have "approved", "denied", and "pending" destinations. You can have as many destinations as you need.

You must designate one, and only one, destination as the default destination. To do this, including the property "isDefault": true in the destination's configuration. If no paths return true, the default destination is chosen. If a path returns true, the default flag is ignored.

Decisions are represented in a JSON configuration as shown below. Note the first destination is the default destination in this example.

{
  "destinations": [
    {
      "id": "approved",
      "isDefault": true
    },
    {
      "id": "denied"
    }
  ],
  ...
}

Paths

Paths are the way you arrive at a destination. They consist of an id, a destination (which corresponds to a destination's id), and a JsonLogic condition property.

If condition evaluates to true, the destination will be selected when processing occurs.

• id can be any string you choose.
• destination must be the id of a destination which you configured in the destinations array.
• condition must be a valid JsonLogic configuration.

Paths are represented in a JSON configuration like this:

{
  ...
  "paths": [
    {
      "id": "hardFail",
      "destination": "denied",
      "condition": {
        "===": [ { "var": [ "txn.propertyMap.hardFail" ] }, true ]
      }
    }
  ],
  ...
}

Putting it together

Key Concepts:

• There may be one or more paths to a single destination.
• Destinations always require a path, unless they are the default destination.
• When a path's condition returns true, the destination is chosen.
• If there are multiple decision rules, use decisionType to simplify logic.
• Use txn. or data. to access current values on which to base decisions.

For example, if you want to always approve an application unless the txn.hardFail property is true, you can set the default destination to be approved, and create a path to denied. Consequently, the approved destination does not require a path to be chosen.

You can also add a decisionType parameter to the call and check it via params.decisionType which controls when the rule should be applied. In this case, the data variable data.application.documentSigningURL is not set until we are at the "esign" step, so it can be ignored until the appropriate decision step is reached.

Using the examples in the previous sections, the configuration file might look like this:

{
  "destinations": [
    {
      "id": "approved",
      "isDefault": true
    },
    {
      "id": "denied"
    },
    {
      "id": "waiting"
    }
  ],
  "paths": [
    {
      "id": "hardFail",
      "destination": "denied",
      "condition": {
        "===": [ { "var": [ "txn.propertyMap.hardFail" ] }, true ]
      }
    },
    {
      "id": "Signature Document Generated",
      "destination": "approved",
      "condition": {
        "and" : [
          {
            "!=": [ { "var": [ "data.application.documentSigningURL" ] }, "unavailable" ]
          },
          {
            "==": [ {"var": [ "params.decisionType" ] }, "esign" ]
          }
        ]
      }
    },
    {
      "id": "Signature Document Not Generated",
      "destination": "waiting",
      "condition": {
        "and" : [
          {
            "==": [ { "var": [ "data.application.documentSigningURL" ] }, "unavailable" ]
          },
          {
            "==": [ { "var": [ "params.decisionType" ] }, "esign" ]
          }
        ]
      }
    }
  ],
  "version": "24.2.0"
}