The concept of using decision logic to manage questionnaires is probably not a reach when you consider the complexity those types of user experiences may entail. Think about all of the possible routes and paths; a series of questions may lead a user. For example, with an online tax submission application, one of the questions may be, “What state are you filing in?” Based on the response, the next set of questions may be different for someone who answers with Florida versus Illinois. That response might then determine a series of questions specific to filing in that state. Now apply that same logic to every other question. Are you married? Are you filing jointly or separately? How many dependents are you claiming? Do you have capital gains to report? Did you make charitable donations? Ultimately, in this example, the individual going through this process wants to know how much am I getting back or how much do I owe.
Behind the scenes, the decision logic can operate at two levels. The first level is to manage the flow of the questions that comprise the questionnaire, and the second level would be the more “traditional” form of decision logic, like validating data, performing lookup operations, executing calculations, etc. all to arrive at the outcome.
Let us use a different example to see how this would play out for an insurance underwriting application. As with all projects that you create using InRule, it always starts with the data model. Here is the list of entities we might use for this process.
The Application is linked to an Applicant, Health Information, and Health Questions, each represented by their entity. Health Questions is a collection of the Question entity.
The Applicant will include the personal information for the individual associated with the Application:
The Health Information entity includes the following fields:
And the Question entity will include these fields:
The rules might be implemented using the following rule set design. The execution would begin with the Start rule set. Note the second rule under Start called RunHealthSurvey. This will make a call to the HealthSurvery rule set, where we’ve implemented a couple of questions to gather the health information of the Applicant.
Using Vocabulary to create custom templates for the questionnaire rules, we might end up with something like the following:
We want to check if the question regarding the Applicant’s height is in the questionnaire. If not, we will add it and specify the category of the question (Height) and the prompt we want to display back in the front-end application (Please enter your height in inches). Since this will be an iterative execution model, i.e., the rules will repeatedly run until the questionnaire is completed, we also need to put in checks to see if the Applicant has provided an answer. For example, the first time these rules run, it will add the Height question. The second time these rules run, we will see if the applicant provided an answer for the Height question. If so, we take their answer and move it into the appropriate field (Height Answer) in the Health Information entity. We would repeat this for every question we want to include in the questionnaire. Once all of the questions have answers, the remainder of the rules will execute to determine the status (approve/deny), the resulting classification (Preferred, Standard, etc.), calculate the rate, and the monthly premium.
Now that we have defined the decision logic and the questionnaire in the rule application, how do we implement it from the business application? When using an MVC (Mode-View-Controller) design, the View would iterate through the collection of HealthQuestions. Again, the first time the collection would be empty. The second time we would have one question (Height). The applicant would provide an answer, and that would trigger the second question.
Here is a sample front-end where clicking the Process button initiates the first execution of the decision logic resulting in the Height question. When the user enters their height, it will then trigger the second execution of the decision logic.
There is quite a bit more we could incorporate into this design pattern. This post showed a linear question flow, i.e. question #1 leads to question #2, et al., but a questionnaire would most likely have conditional branches in the logic to redirect to other question sets or to even skip questions if they are no longer applicable based on a previous response. We could also manage the list of possible answers for each question so that the user is restricted in their response. Over time, the question sets may change, so how do we design it in such a way as to easily add, remove or update questions? Using irAuthor, that complexity can be reined in by allowing the owners of the decision logic and the survey process to manage both within a single rule application.
