New and Enhanced in System Management

Release 16.05 brings the following new and enhanced functionality to the System Management menu to take the configuration options in the Lifecycle Management Suite to the next level!

Decision Order in an Application

Institutions can now configure the decision order for applications requiring both a loan and account decision!

A Decision Order parameter has been added to the Underwriting tab in System Management > Modules > Origination to allow system administrators to configure the decision order for their institution. When an application requires both a loan and account decision, if the Decision Order is set to Loan First, the loan is decisioned prior to the account. If set to Account First, the account is decisioned before the loan.

Regardless of the module(s) active for an institution, values of Account First and Loan First appear in this drop-down, and the default value for this parameter is Loan First.

The system has checks in place during the decisioning process to verify the type of decision required for an application, and perform the appropriate action for the loan decision when an account decision is not required; therefore, if the parameter is set to Account First, but an account decision is not required, the system automatically proceeds with decisioning the loan.

The Decision process now checks the value of the Decision Order parameter in order to determine how to proceed with decisioning the application.

Time Delay for Event/Action Pairs

Event/Action pairs can now be set on a time delay in the Lifecycle Management Suite!

The Event Processing functionality now supports the ability to add a time delay to an Event/Action pair. With this new functionality, system administrators can determine the number of days, hours, minutes, or seconds that must pass before the action(s) assigned to an event/action pair are executed in the Lifecycle Management Suite.

The ability to add a time delay to an event/action pair is not supported for system-defined pairings as well as synchronous events.

To support this new functionality, the Event Processing page in System Management > Origination > Event Processing has been updated to include two tabs: Event Processing and Delayed Actions Report.

The Event Processing tab includes a list of all configured Event/Action pairs and provides the ability to create and manage pairings. A column titled Delayed also appears in the grid to identify whether or not an Event/Action pair has been configured to include a time delay.

The Delayed Actions Report tab provides an overview of all delayed event/action pairs that have executed in the Lifecycle Management Suite, and lists specific information about each pairing, such as the status of the event/action pair, the date and time of execution, and the specific object on which each pairing is run. For example, the application id.

The Event Processing configuration window has also been enhanced to include the following:

A Delay Settings Panel on the General tab to allow administrators to activate a time delay for an event/action pair and configure the length of time to be added to the event before the assigned action(s) execute.
A check box titled Synchronous on the Events tab to identify an event as synchronous.

The following additional updates have also been made in the Lifecycle Management Suite to support the execution of delayed event/action pairs:

Configuration manager has been enhanced to export and import the time delay settings configured for an event/action pair in Event Processing
A new windows service, LMS.Core.Process, and SQL Service Broker have been added to the installer to support the time delay functionality during an institution's upgrade to release 16.05.

User and Security Group Permissions for Search

The Search functionality is now tied to user and security group permissions that allow system administrators to determine which users are able to perform a search, and access workspaces in the Lifecycle Management Suite.

To support this, the following updates have been made to the Permissions tab in System Management > Users and System Management > Groups > Security Groups:

The Workspace permission for the Account Servicing modules now allows a user to not only perform various functions within the person workspace, such as writing comments or working a queue, but also grants the user permission to access and use the Search feature within the Ribbon Bar. Prior to this update, the Workspace permission appeared under the Areas category of the Permissions tab. Now, the Workspace permission is available under the Collections category.

This permission is only available for the Account Servicing modules.

A new permission titled Origination Workspace has been added to the Application Processing category of the Permissions tab. This permission allows administrators to grant users working in the Origination modules permission to use the Search feature and access the Application workspace.

This permission is only available for the Origination modules.

Reference the following table for an overview of the behavior that occurs for the Search feature when the above permissions are set to None, View, or Change:

Permission

Behavior

Workspace

None = Users are not able to use the Search feature, and the is disabled in the Ribbon Bar.

View = Users are able to use the Search feature; however, only screens and workflows that the user is assigned permission to are available in the Left Navigation Panel, and no changes can be made to any screens and/or workflows in the workspace.

Change = Users have full access to the Search feature, and are able to perform all functions for the selected account or person in the workspace.

Origination Workspace

None = Users are unable to use the Search feature, and the

is disabled in the Ribbon Bar.

View = User can access and use the Search feature; however, the selected application opens as READ ONLY in the workspace, and no changes can be made; only a comment can be added to the application while in this state.

Change = User has full access to the Search feature, and is able to perform actions within the selected application in the workspace.

For institutions that use both Account Servicing and Origination: Since there are two separate permissions that control the Search feature for the Account Servicing categories and Origination categories, it is possible that a permission may be set to View or Change for one, but set to None for the other. When this occurs, the user is only able to use the Search feature for the modules to which he or she is granted permission to access. For example, if the Workspace permission is set to View or Change, but the Origination Workspace permission is set to None, the user is able to click in the Ribbon Bar to perform a full search using the Account Servicing categories, but the Origination categories are not available to the user.

All Custom Searches configured for an institution are available within the Search window for any user who is granted permission to use the Search feature.