Collapse All Expand All

Event Processing enables administrators to pair predefined events and actions together. Events and actions are “self-contained” entities that provide institutions with the flexibility to perform crucial tasks at an appropriate time in the application lifecycle. When a defined event occurs, the corresponding action automatically fires. 

For example, the cross-sell processing action can be tied to application approval event. In this example, the approval of an application triggers cross-sells to generate in the background while a user continues processing the application.

The Event Processing page in System Management (System Management > Origination > Event Processing) enables administrators to maintain and customize event processes for their institution. This page displays a list of all system-defined and custom event/action pairings configured in the Lifecycle Management Suite, and provides administrators with the functionality to configure event processes to meet their institution's business needs.

• Event Pair Attributes
  • General
  • Events
  • Actions
  • Rules
• Creating Event Pairs
• Editing Event Pairs
• Deleting Event Pairs
• Business Example
• System Defined Pairs

Event Pair Attributes

Each event pair contains attributes that are organized into a series of tabs. The defined attributes determine the functionality of each pair.

General

The General tab allows a user to provide basic information about the event and action pairing. Users are also able to enable/disable an event and action pairing within the General tab.

The following fields are available in the General tab:

Field	Description
Name	Enter the name for the Event.
Description	Enter a description for the Event.
Active check box	Select the Active check box so that the Event pair is active in an application.

Events

The Events tab is where an Event can be assigned. An administrator is able to assign a system-defined or user-defined Event. Once an Event is chosen, the administrator can choose to edit the event type for the specific event and action pair being created.

The Events Tab contains a toolbar at the top of the screen that allows users to perform the following actions:

Icon	Description
	Allows a user to add an event to the Event Processing pair.
	Allows a user to edit the event assigned to the Event Processing pair.
	Allows a user to delete an event from the Event Processing pair.

Adding Events

• Clicking  opens the Select Event Type window. Use the Event Type drop-down to select the event that triggers the ensuing action.
  
  
• The following is a list of system-defined Events:

Event	Description
Account Number Pre-Generation	Raised whenever the Generate Account Number functionality is called during the application process; when Generate is manually clicked in the Loan Account Number section of the Change Account/Loan Number screen, the Generate Account Number action is fired, or during the disbursement process.
Application Approved	Raised whenever an application is approved (Auto or LO Approved).
Application Created	Raised whenever a new application is created in the Lifecycle Management Suite.
Application Declined	Raised whenever an application is declined.
Application Disbursed	Raised whenever an application is disbursed.
Application Pre-Decision	Raised prior to decisioning an application.
Application Pre-Disbursement	Raised prior to disbursing the application.
Application Opened	Raised whenever an existing application is opened.
Collection Added	Raised whenever a collection is added. For example, Applicants, Addresses, and References.
Collection Removed	Raised whenever a collection member is removed.
Comment Added	Raised whenever a new comment is added on an application.
Counteroffer Change	Raised whenever an application counteroffer has changed.
Credit Report Request Started	Raised prior to requesting a credit report.
Custom Event	Raised at a time determined by a custom event code. While this event type is available as standard functionality, the required event code is custom to each institution. If interested in using this functionality, please contact a Temenos Account Manager.
Decision Removed	Raised whenever a decision is removed from a previously approved or declined application.
Decision Suggested	Raised whenever a decision is recommended on an application.
Document Attached to Application	Raised whenever a document is attached to an application. This event is triggered each time a document is attached to an application. If desired, a rule can be written to stop the action from executing if the Document Source does not equal a certain value, such as that of a particular third party connector. For more information, please see the Send Notifications to Notification Group rule template example in this guide.
Document Pre-Generation	Raised during the Document Generation process, prior to documents being generated.
Field Changed	Raised whenever a field changes.
Next on Workflow Screen	Raised whenever Next is clicked on the Workflow screen.
Pre-Create Member Account Number	Raised upon execution of the Create Member Account Number action, manual generation of a member account number within the Change Account/Loan Number screen, or when an application is disbursed.

Select the desired event and click  to finalize the event selection.

Most events are straightforward, however, events such as Collection Added, Collection Removed, Field Changed, and Next on Workflow Screen require additional input.

Collection Added or Removed Events

Field Changed Events

Next on Workflow Screen

Editing Events

• Administrators are able to modify an existing event by clicking  in the Events tab within the Event Processing pair.
• Make the desired modifications. Once the modifications are complete, click .

Deleting Events

• Administrators are able to delete an existing event by clicking  in the Events tab within the event and action pairing.

Actions

The Actions tab provides administrators with the ability to assign a system-defined or user-defined Action to an Event.

The Actions tab displays a toolbar at the top of the screen that allows users to perform the following actions:

Icon	Description
	Allows a user to add an event to the Event Processing pair.
	Allows a user to edit the event assigned to the Event Processing pair.
	Allows a user to delete an event from the Event Processing pair.

Adding Actions

• Clicking  opens the Select Action Type window. Use the Event Action drop down to select the action that is triggered by the previously selected event.

• The following is a list of system-defined Actions:

Actions	Description
Auto Blacklist IP	If an IP address has been blacklisted, this action automatically sets the IsIPBlacklisted flag to true on all applications that have the same blacklisted IP address. The IsIPBlacklisted flag is available for addition to screens and rules in the Lifecycle Management Suite.
Auto Disburse	This action automatically disburses the application if: The application is not locked by a Lifecycle Management Suite user. If the IsLoanReadyForDisbursement flag is selected. If the application is locked by a Lifecycle Management Suite user: The auto disburse action stops. A notification stating "the application is ready to be automatically disbursed" is added to the application.
Create Member Account Number	If the application is for a non-account holder, this action automatically creates and returns an account number to the Lifecycle Management Suite for the application's primary applicant based on the following logic: If the Host Supports Person Account Number Auto-Generation parameter on the Solution.Origination page has a value of "Yes," and the Account Origination module is not active, the Lifecycle Management Suite executes code to create person account using Get New Member portion of interface specified as the Disbursement Method. If the Host Supports Person Account Number Auto-Generation parameter on the Solution.Origination page has a value of "No," the Lifecycle Management Suite stops executing the action. If the primary applicant is a current account holder, and the value of the NewMembership field is Create New Member Account, a new member account number is created for the primary applicant in the core. When a new member account is created, the primary applicant's account number is set to the new account number in the application and the value of the NewMembership field is set to New Member Account Created. Additionally, queue routing rules execute if the application is not currently in process by a user.
Evaluate Region of an IP	This action automatically compares the applicant's current IP address to a database housed at Temenos. This database contains all IP ranges for the United States to determine if the IP address is domestic or foreign. If the IP address falls into the IP range for the United States, the IP_REGION_TYPE lookup field is set to Domestic on the application in the Lifecycle Management Suite. If the IP address falls out of the IP range for the United States, the IP_REGION_TYPE lookup field is set to Foreign.
Execute Application Queuing Rules	Executes the configured queuing rules.
Execute Code	Execute system-defined or custom code to perform certain actions. This is also used to inform third parties about changes to the application.
Execute Counteroffer Processing	This action attempts to create counteroffers based on the parameters, comments and stipulations configured within the rule logic authored to automatically create counteroffers.
Execute Fees During Next Calculation	Indicates that fees are out of date. Usually paired with “Field Change” or “Collection Member Added” events to indicate to the user to reassess the application fees.
Execute Rules	Executes the configured rules. The rules executed via this action are able to perform the following actions: Update data on the application Send Emails Users are not able to return messages since the actions are processed asynchronously.
Generate Account Number	This action assigns a new loan/suffix based on the following logic: If the Host Supports Account Number Auto-Generation parameter on the Solution.Origination page has a value of "Yes," and the Account Origination module is not active, the Lifecycle Management Suite executes code for the interface specified as the Disbursement Method. If the Host Supports Account Number Auto-Generation parameter on the Solution.Origination page has a value of "No," the Lifecycle Management Suite stops executing the action. Additionally, queue routing rules execute if the application is not currently in process by a user.
Generate Documents	This action generates new loan documents. As part of this action, the following processes occur: Document Selection Rules execute to assign the document set to the application. Checks if the IsLoanReadyForDisbursement flag is selected. Checks that the assigned Document Set was not already generated for the application. As part of this check, the document delivery method is also verified to allow the same version of a document set to be re-generated when the versions include different delivery methods. Sends appropriate flag to IMM based on Document Delivery Method. Executes queue routing rules if the application is not currently in process by a user.
Notify of Required Loan Calculation	Returns a notification which indicates that the calculations are out of date.
Process Cross-sells	This action generates the cross-sells for the application. If creating a custom rule to process cross-sells, it is recommended that the StopCrossSellAction rule is assigned to the event pair in order to prevents cross-sell opportunities from generating on applications and child applications.
Process Stipulation Rules	This action processes stipulation rules based on configured event types. When triggered, all stipulation rules assigned to the application type execute.
Pull Credit	This action initiates credit report processing for the applicants associated with the application. Credit reports are pulled according to the defaults configured in Loan Application Types.
Request MLA Search Only	This action initiates a military status search for the applicants associated with the application. MLA searches are performed according to the credit bureau use order configured in Loan Application Types and the Military Covered Borrower Check parameter on the Equifax, Experian, and TransUnion Origination connector pages.
Search Core for Applicant	This action initiates a search within the core for existing account records, if the applicant has indicated they are not currently an account holder within the Continue as Guest panel in Virtual Capture. This action prevents a new account record from being created for the applicant if they already have an account with the financial institution. This action runs once for each applicant on the application where Is Customer is false and searches the core for any existing accounts for the applicants based on the TIN. The Search Core for Applicant action does not automatically retrieve applicant information, such as demographics, assets, and liabilities, from the core. To import applicant information after the Search Core for Applicant action is executed, an Update from Core action can be performed either manually via the workspace or automatically through Event Processing. However, if an Update from Core is performed during the virtual application process, a security risk may be exposed, as the Update from Core action can provide a fraudulent applicant with account numbers and other secure information. The following table outlines how an existing applicant is found in the core, including the possible scenarios that can occur as a result of the search, and the information that is updated within the Lifecycle Management Suite: Search Core for Applicant Functionality Number of Search Results Scenario 1 Scenario 1 Fields Updated Scenario 2 Scenario 2 Fields Updated Multiple The LMS selects the first account from the core where the applicant is Primary and the account is not closed. Applicant > Account Number = Member/Customer Number from the core Applicant > Source Account Number = Member/Customer Number from the core Applicant > Person Number = Person/Individual Number from the core (if applicable) Applicant > Is Customer = True If there are no accounts that meet the criteria for Scenario 1, the LMS selects the first account from the core where the applicant is Joint and the account is not closed. Applicant > Account Number = Null/blank Applicant > Source Account Number = Member/Customer Number from the core Applicant > Person Number = Person/Individual Number from the core (if applicable) Applicant > Is Customer = False One The applicant is Primary and the account is not closed. Applicant > Account Number = Member/Customer Number from the core Applicant > Source Account Number = Member/Customer Number from the core Applicant > Person Number = Person/Individual Number from the core (if applicable) Applicant > Is Customer = True The applicant is Joint and the account is not closed. Applicant > Account Number = Null/blank Applicant > Source Account Number = Member/Customer Number from the core Applicant > Person Number = Person/Individual Number from the core (if applicable) Applicant > Is Customer = False No accounts returned or all accounts are closed A notification is added to the application in the LMS indicating that data could not be located or all accounts are closed in the core for the supplied TIN. N/A N/A N/A Error is returned A notification is added to the application in the LMS indicating that an error occurred during the Search Core for Applicant process. N/A N/A N/A
Send Comment To CUDL	Updates CUDL with the current application information. By default, a system Event and Action pair causes this to happen when a CUDL application has a comment.
Send Comment To Dealertrack	Updates Dealertrack with the current application information. By default, a system Event and Action pair causes this to happen when a Dealertrack application has a comment.
Send Comment To RouteOne	Updates RouteOne with the current application information. By default, a system Event and Action pair causes this to happen when a RouteOne application has a comment.
Send Counteroffer To Dealertrack	Updates Dealertrack with the current application information. By default, a system Event and Action pair causes this to happen when a Dealertrack application has a Counteroffer.
Send Counteroffer To RouteOne	Updates RouteOne with the current application information. By default, a system Event and Action pair causes this to happen when a RouteOne application has a Counteroffer.
Send Decision To CUDL	Updates CUDL with the current application information. By default, a system Event and Action pair causes this to happen when a CUDL application is Decisioned.
Send Decision To Dealertrack	Updates Dealertrack with the current application information. By default, a system Event and Action pair causes this to happen when a Dealertrack application is Decisioned.
Send Decision To RouteOne	Updates RouteOne  with the current application information. By default, a system Event and Action pair causes this to happen when a RouteOne application is Decisioned.
Send Disbursement To CUDL	Updates CUDL with the current application information. By default, a system Event and Action pair causes this to happen when a CUDL application has been Disbursed.
Send Disbursement To Dealertrack	Updates Dealertrack with the current application information. By default, a system Event and Action pair causes this to happen when a Dealertrack application has been Disbursed.
Send Disbursement To RouteOne	Updates RouteOne  with the current application information. By default, a system Event and Action pair causes this to happen when a RouteOne application has been Disbursed.
Store Decision History	This action stores the decision information on the application. Once stored, a record of the decision is displayed within the Decision History panel.
Update From Core	This action updates an application with the most up-to-date information from the core.

• Select the desired action and click  to finalize the action selection. 

More than one action may be added to an event/action pair. If action priority is a concern, it is recommended to pair multiple actions to an event as opposed to creating two separate event pairings. When more than one action is added, the pairing is treated as an “And Statement,” and are triggered simultaneously. If an event occurs, all actions trigger. If multiple events and multiple actions are paired, all actions trigger if one event occurs. For example, a user may choose to have two actions fire when an Applicant is added. One action may be "Pull Credit," and the other may be a rule which prompts the Lifecycle Management Suite to not pull credit if the applicant is less than 18 years old. If these actions are not contained in the same Event pair, the actions may not fire in the intended order. Pairing these Actions within one Event ensures that priority is handled as intended, as long as Actions are ordered properly within the Event.

Most actions are straightforward, however, actions such as Execute Code, Execute Counteroffer Processing, Execute Rules, and Update From Core do require additional input.

Execute Code Actions

Execute Counteroffer Processing

Execute Rule Actions

Update From Core

Editing Actions

• Once an Action is chosen, the administrator can choose to edit the action type for the specific Event Processing pair being created by clicking  in the Actions tab within the event and action pairing.
• Make the desired modifications. Once the modifications are complete, click .

Deleting Actions

• Administrators are able to delete an existing Action by clicking  in the Actions tab within the Event Processing pair.

Rules

The Rules tab allows the administrator to set qualifiers for the Event Processing pair. Rules can be assigned to each event and action pair to add clarification and control over the application of actions. These rules can be created under the “Event Processing” category to indicate if the action(s) should be executed.

A list of available rules appears under the Available Rules box. Assign the desired Event Processing rule(s) to the event and action pairing.

Creating and Event Pair 

To create an event and action pair:

• Click .
• Add the General attributes.
• Select the Event attribute(s).
• Select the Action attribute(s).
• Assign the applicable Rule attributes.
• Once all attributes have been identified, click .

Editing and Event Pair

To edit an existing event and action pair:

• Select the desired event and action pairing and click .
• Update the desired attributes. 
• Once all attributes have been updated, click  to finalize the Event Processing modifications.

Deleting and Event Pair

To delete an existing event and action pair:

• Select the desired event and action pairing and click .
• Clicking Delete prompts the user to verify that the event and action pairing is to be deleted.
• Click OK to confirm the deletion.

System Defined Events and Actions

 

 

---

©2018 Temenos Headquarters SA - all rights reserved.

Send Feedback