New Automation Capability - Service Order Update Notifications

Encompass 23.3 included support for lenders to send a webhook notification to an Encompass Partner Connect (EPC) partner indicating that an order needs to be updated. These notifications are configured in Encompass Workflow Rules, and can be triggered on a variety of change events on a loan, including completion of one or more Milestones, field value changes, addition of an attachment to an eFolder location, and more.

📘

For more information, see Workflow Rules. Encompass 23.3 introduces the first phase of the Update Service Order feature, with additional features targeted for Encompass 24.2.

How Does It Work?

At a high level, Update Service Order notifications are reasonably easy to set up.

1. Partners add a new feature flag to their EPC product to indicate support for receiving and processing Update Service Order notifications from Encompass Workflow Rules.

2. Lenders configure their Workflow Rules to include a Resulting Action of Update Service Order and select the Partner’s EPC Product from the list of activated EPC Products that support the receiveAutomatedTransactionUpdates feature flag.
3. When a loan change is saved that matches the Triggering Event details on the Workflow Rule, EPC will send a webhook notification to the webhook listener registered on the specified EPC Product.

4. The Partner then processes the webhook to retrieve the updated transaction object and execute an update to the service order.

Update Service Order Use Cases and Planning

The simplest use case for the Update Service Order flow is one where a single order is placed per loan, and that order is updated multiple times using the same request type throughout the lifecycle of the loan. Fraud is a good example - these integrations generally support only a single update action type, which is to rescore the loan based on the loan data in the current request file. A partner implementing support for Update Service Order notifications does not need to determine what changed on the loan or which kind of action to take on the order. They simply format the ”rescore” request from the loan data and resources included in the updated Transaction object and execute the update as any other.

In a slightly more complex use case, consider one where two actions are supported - rescore and send invoice, with the latter intended to be executed after the loan has closed (loans falling out are ignored in this explanation). In this case, the partner will need to determine the nature of the update to the loan in order to take the appropriate action on the order.

These uses cases can potentially both be supported with the functionality delivered in Encompass 23.3, but careful coordination with the lender is required for success. Some event notification details can be retrieved by executing the meta.payload.reference above will vary based on the Triggering Event defined by the lender in their Workflow Rule, but only two triggering events currently support this additional detail. Consider the three meta.payload.reference payloads below:

Assuming you’re not going to do a diff on the Transaction payloads to figure out what changed, which is not recommended, you will need to rely on the detail in the event to determine how to process the update. The payload in Figure 1 is the result of a field value modified triggering event, while the payload in Figure 2 is the result of a file added triggering event. The contents indicate what changed, but not what action is expected to be taken by the partner beyond updating the order. This is where coordination with the lender is important - if you code your integration to expect field update details but the lender decides to use a different triggering event your application will not work properly.

In this two-option use case, a partner could potentially opt to process any update notification as a “Rescore” except for one indicating that a loan had closed. There are several ways that this might be done, but all will likely require checking the updated loan data on the transaction request. Potential options include checking HMDA Status [1393] for a final disposition status or maybe checking the last completed milestone for one that indicates the loan is closed. Note that milestones are named by Lenders in their Encompass instance, though, so you will have to store which values indicate closed. Whatever you decide, these expectations would need to be clearly documented for the Lender, so that they know what to do if they want to trigger the automatic delivery of the invoice to the eFolder when the loan is closed.

Enhancements Planned for Encompass 24.2

Programmatically interpreting these event notifications and correlating them with update actions that you support can be tricky. More complex use cases require careful consideration to ensure your automated flows function as needed with the platform features available now. In Encompass 24.2, two key enhancements are planned that will add support for more complex use cases. A short summary of these features is below, and more details will be available as Encompass 24.2 availability nears.

• Multiple Order Specification - A new field will be added to the Resulting Action configuration to specify which order to be updated: All Orders, Last Order, or Active Orders. EPC will send Update Service Order webhook notifications for each qualifying transaction based on this setting. Note that the behavior in 23.3 is that a webhook notification is sent for all orders.
• Service Events - Partners will have the ability to register one or more Service Events on their product, such as “Rescore” and “Send Invoice”. These Service Events will be included in the Resulting Action options, where the Lender can specify which Service Event should be included in the Update notification sent by EPC. In this way, you can define update actions that you support and Lenders can tie those actions to workflow rules that they define.

Final Note

As of the time of this publication, there are no EPC products in production with receiveAutomatedTransactionUpdates enabled. To avoid confusion, the Update Service Order feature is only available upon request until at least one partner product is available in production with support for this feature. If you would like access to the Update Service Order resulting action in your instance, please contact your Account Manager.