To instantiate a new process instance, first we must submit a new application to the business process. Similarly to working with Business Central, this initial step is performed by submitting all relevant data via a form for processing:

Figure 5.3. Dashboard Application

Once an application has been submitted, the data is verified against a set of rules responsible for things like checking for a valid property price, down payment, social security number format, income, amortization, etc. If the validation fails, the application is moved into the Data Correction task, where the information can be reviewed, amended, and resubmitted to the process for continuation.

Initially, as is the case with each task category, the task itself is unassigned. While a group has already been specified by the business process, in this case the broker group, a specific user belonging to the group must claim and start the task in order to complete it. In more complex use cases, task delegation and oversight functionalities by supervisory or managerial roles are possible, but for the purposes of this application, only basic self-assignment and completion has been built in. The image below shows three Data Correction tasks, two which have already been claimed with one of those being in progress, thus disabling the manipulation of other tasks until the currently worked one is either stopped or completed:

Figure 5.4. Data Correction Tasks

Once data correction has been performed, or if correction is not required for an application, the next step is to reach out to the Credit Service web service and get the information for the current applicant. This step is performed via a WebService task and, as far as the Dashboard is concerned, will largely go unobserved unless failures occur during the service call or response. Should errors occur, the relevant error information is relayed to the Troubleshoot tab of the dashboard to aid with diagnosing and solving any issues that arise:

Figure 5.5. Troubleshoot (Credit Service Errors)

Like the credit service task, the next few parts of the application process are seamless as far as the dashboard is concerned. First, a few calculations are performed to determine what offerings should be available for the applicant. The Mortgage Calculation step prices a mortgage by first calculating a minimum interest rate, based on only the length of the fixed-term mortgage (i.e., APR) and the applicant’s credit score. This is followed by a look at the down payment ratio and the APR is adjusted upward if less than 20% is provided. Finally, jumbo mortgages are identified and result in yet another potential increase in the mortgage APR.

While the lending risk is already reflected in the calculated interest rate, there are also cases where the lender refuses to provide the applicant with a mortgage. One such case is the front-end ratio for the mortgage application exceeds the 28% threshold. Calculating the front-end ratio is a simple matter of determining the monthly mortgage payment (the process ignores other housing costs) and dividing it by the applicant’s income. For simplicity, this calculation is performed in a script task. Following this, the process allows an application to either move on to the appraisal and/or approval phase, or go back to the broker for Down Payment Adjustment.

Once an applicant has been deemed unqualified given a specific scenario, it’s still possible to avoid losing a business opportunity by exploring alternative ways to qualify the mortgage applicant. One simple solution is to request a larger down payment. This step in the process can be thought of as iterative. The broker may continually increase the down payment and re-submit the application for qualification in hopes that it may continue, or they may submit the same down payment twice in a row (i.e. no change in the most recent iteration) to signify that an upper limit has been reached and the application should process to financial review.

Figure 5.6. Down Payment Adjustment

While the business process frequently solicits input from users, most logic decisions so far have been automated. It is common for most business processes to have some sort of manual override. In the loan application use case, a manager may have the authority to approve a mortgage application that does not meet the standard criteria. As a last resort before declining the application, a user task grants the manager group the ability to approve a mortgage previously flagged during the Down Payment Adjustment task and allow it to proceed to appraisal and approval. They may also choose to deny the mortgage, at which point signifies an end to the process, meaning that the process instance will no longer to be visible on the dashboard or associated with any remaining tasks.

Figure 5.7. Financial Review

Once a borrower has been qualified for a loan, if an appraisal is not already present, the value must be collected prior to a final approval. This last step has a possibility of two outcomes.

The first possible outcome is that the appraisal could be sufficiently valued at over the sale price of the property, at which point the application gets final approval and completes the process. Should this occur, the process instance will no longer to be visible on the dashboard or associated with any remaining tasks. In an extended use case, this application approval would likely trigger a separate business process that continues to another team or department for follow-up, but in this limited use case, the approval signifies the end.

The second possible outcome, wherein the appraisal is not sufficiently valued above the asking price of the property, the application will traverse back in the business process to the point of Mortgage Calculations and Borrower Qualification for recalculation and outcome pending the newly garnered information.

Figure 5.8. Appraisal

Once a final state of approval or denial is reached, the application process is complete. As alluded to previously, the process instance related to the finalized application will no longer be visible for tracking within the dashboard as all related work has been performed. As a final exercise for the reader, consider adding a summarization table to the Dashboard Overview which uses the available API classes to track and list those process instances which are no longer in an active state and displays the outcome of the application process.