The User Information tab displays by default. Certain fields within this section can be included within letter and email templates. The following fields display within the User Information section in the tab:

Within the Framework Authentication section, define the sign-in method of the new user. If System is selected, the user is required to enter in a username and password to sign into the Lifecycle Management Suite. The administrator must define the password in this section.            

• Check the Force password on next login box to prompt the user to change their password on their next login.
• Check the Password never expires box to allow the password never to expire.

• Select the Windows authentication method to allow users to sign in using the Windows Authentication icon on the sign-in page. If this option is selected, the system validates their Windows ID and password as their sign on information for the Lifecycle Management Suite. Enter their Windows Account in the Windows Account field. The format for the windows account is always DOMAIN NAME\username.

Within the Host Authentication section, define the Host ID, Host ID 2, and Host Password for the host system.

These settings are only for the DataSafe, Summit, Symitar, and XP2 Origination host systems.

Within the Company Information tab the following sections display: Company Information and Organization Structure.

The following fields display within the Company Information section:

The fields within the Company Information section are for informational purposes only.

Within the Organization Structure section, define how the user is to be grouped for easier reporting purposes. These fields are defined in System Management > Field Configurations.

Within the Personal Information tab, define the new user’s personal information. The following fields display in this tab:

The fields within the Personal Information section are for informational purposes only.

Within the Collections Settings tab, set collection standards for the new user. These fields are used by administrators to track collection performance.

The following fields display within this tab:

Field Name	Description	How contributes to User Performance
Daily Work Hours	Identifies the number of hours per a day that the user is expected to work.	N/A
Total Calls per Hour	Identifies the number of calls that a collector is expected to make per hour.	Used to determine: Target Number of Calls for Collector Production Dashboard and User Performance Dashboard. (Total Calls Per Hour x Hours Worked= Target Number of Calls)
Target % Contacts	Identifies the percentage of calls placed by the user expected to result in a successful, valid contact.	Used to determine: Target Number of Contacts for Collector Production Dashboard and User Performance Dashboard.  (Actual Calls x Target % Contacts= Target Number of Contacts)
Target % Promises	Define the percentage of successful promises the user must meet.	Used to determine: Promises Made Target for Collector Production Dashboard (( Target % Promises x Contact Count)/100= Promises Made Target) Target Number of Promises for User Performance Dashboard. (Number of Contacts x Target % Promises= Target Number of Promises)
Target % Promises Kept	Define the percentage of successful promises kept the user must meet.	Used to determine: Target Number of Promises Kept for Promise Monitor Dashboard. ((Target % Promises Kept x Due Count)/100= Target Number of Promises Kept)
Max Promise Days	Identifies the maximum number of days a collector can define for the time period in which the total promise must be fulfilled. For example, if the max promise days is set to 30 days and the user sets the promise to be completed in 45 days, the promise goes to management for approval.	N/A
Max First Payment Days	Identifies the maximum number of days in advance that a collector can schedule the first promise payment. For example, if the max first payment days is set to 10 days and the user schedules the first payment in 20 days, the promise goes to management for approval.	N/A
Max promise payments	Identifies the maximum number of payments in which a user is able to divide a promise payment. When an end-user is running the Promise to Pay workflow step, this determines the maximum amount of promise payments the user can select from the Number of Payments drop-down. For example, if the max promise days in System Management > Solution > Collection is equal to 4, and the user sets up 5 payments, the promise is deferred to management approval.	N/A
Max % Promise Tolerance	Identifies the maximum percentage of the total promise amount that a user can accept to satisfy the promise payment. A promise payment can be short without being considered broken as long as the payment meets the discount requirement specified here. For example, if the max % promise is 10% and the total promise amount is $1,000, the promise payment can be satisfied if the borrower pays $900.    If no discounting is permitted, then the value in this field should be set to “0.”	N/A
Min Promise Value As % of DQ Amount	Identifies the minimum % of the total promise amount that the user is allowed to accept. For example, if this setting is set to 10% and the total DQ amount is $10,000.00, the minimum promise that the user can take is $1,000.00. Otherwise the promise is sent for manager approval.	N/A

For additional information on User Performance, please see the User Performance Web Part topic in the User Guide.

Within the Security Groups tab, assign the new user to a Security Group. The Security Groups that are available are defined in System Management > Groups > Security Groups.

A user can be assigned to multiple security groups.

Within the Permissions tab, manage the new user’s access to several features throughout the Lifecycle Management Suite.

This tab contains two columns: Function and Permission. Click under the Permission column in the corresponding row of the screen and a drop down appears. Change the value in this drop down to change the user's access to the screen. The following are permission options that are available through the permission drop down:

• None: If selected the user does not have permission to view or execute the feature.
• Change: If selected the user has full access to the feature. User can view and edit.
• View: If selected, the user has the ability to view the function but does not have the ability to change or execute it.

Below is a list of all the permissions that can be customized by the administrator and their description.

Collections
Name of Permission	Description
Event Processing: Allows a user to create and maintain event and action pairings.	None = Event Processing screen within System Management is not available to user. View = Event Processing screen within System Management can be viewed but not edited by user. Change = Event Processing screen within System Management screen can be viewed and edited by user.
Recovery Approval: Allows a user to view and process pending charge offs within System Management. This permission is only available to institutions using the Lifecycle Management Suite's Recovery module.	None = Users do not have access to the Recovery Approval page in System Management and are not able to respond to charge-offs pending approval.   View = Users have access to the Recovery Approval page in System Management but are not able to accept and/or reject charge-offs. Change = Users are able to both access the Recovery Approval page in System Management and process pending charge-offs.
Rules Management: Allows a user to access the Rules Management application. The Rules Management application allows users with proper permissions to view and create rules to apply in various contexts throughout the system.	None = Users do not have access to the Rule Management page in System Management > Collections, and do not have the ability to view/open the rules manager in various other areas in the system that utilize the rules integration.   Change = Allows users access to the Rules Management application throughout the system.
Workspace: Allows a user to perform various functions within the person workspace, such as writing comments or working a queue, as well as grants the user permission to use the Search feature within the Ribbon Bar.	None = Users are not able to perform various functions within the workspace, such as posting a comment, or working a queue, and can not access workspaces from the Queues, Views, and/or Dashboards page. When set to None, the user is also unable to use the Search feature; therefore, the  is disabled in the Ribbon Bar.   View = Allows users to view comments and queues in the workspace, but not work queues. When set to View, users are able to access workspaces from the Queues, Views, and/or Dashboards page, and 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 = Allows users to perform various functions in the workspace, such as posting a comment, and working queues. When set to Change, users can access workspaces using the Search feature, as well as from the Queues, Views, and/or Dashboards page, and are able to perform all functions for the selected account or person in the workspace. In addition to having View or Change permission for the Workspace, a user must also be assigned to the specific queue, view, or dashboard in order to open the workspace for the account or person. 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. For institutions that use both Account Servicing and Origination: There are two separate permissions that control the Search feature for the Account Servicing categories and Origination categories; therefore, 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, the Origination Workspace permission under the Application Processing category controls the Search feature for the Origination modules. 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, and the user is not able to open applications from the Queues, Views, and/or Dashboards page.

Within the Screens tab, assign available screens to the user. If a screen is assigned, the user has access to the screen in the left navigation panel when a person/account is open in the workspace.

If the security group the user is assigned to has access to the screen, by default the user has access to the screen even if they do not at the user level.

The screens and boxes that display on the User Edit screen are determined by the enabled module. For example, if loan origination is not active, origination screens are not available to be assigned and the Available and Assigned Origination Screens boxes do not display on the Screens tab.

In the Workflows tab, workflows can be assigned to “None,” “View,” or “View & Execute.” If a workflow is assigned to None, the user is not able to view the workflow history associated to the workflow nor execute the workflow. If assigned to View, the user can view the workflow history associated to the workflow but cannot execute it. If assigned to View & Execute, the user can view the workflow history and execute the workflow on an account, case, or person.

If the security group the user is assigned to has access to the workflow, by default the user has access to the workflow even if they do not at the user level.

In order for a user to have access to a workflow on an Area, the following criteria must be met:

For each Workflow, security can be set on the Area and the User or Security Group level. This security only applies when a user enters the Workspace of an Area. For example, if a workflow is not assigned to an Area, the workflow does not appear in the Area regardless of the security applied to the workflow.

When assigning a workflow to an Area or assigning Users and Security Groups to a workflow, there are three levels of security:

None is the lowest level of security and View & Execute is the highest level of security.

In the Dashboards tab, assign available dashboards to the user. If assigned the user is able to open the dashboard from the dashboard icon in the Lifecycle Management Suite ribbon.

If the security group the user is assigned to has access to the dashboard, by default the user has access to the dashboard even if they do not at the user level.

In the Views tab, assign available views to the user. If assigned, the user is able to open the view from the views icon in the Lifecycle Management Suite ribbon.

If the security group the user is assigned to has access to the view, by default the user has access to the view even if they do not at the user level.

In the Reports tab, assign available reports to the user. If assigned, the user has the ability to view/run the reports from the reports icon in the Lifecycle Management Suite ribbon.

If the security group the user is assigned to has access to the report, by default the user has access to the report even if they do not at the user level.

In the Areas tab, assign available areas to the user. These assigned areas are available to the user in the Areas drop down in the workspace.

If the security group the user is assigned to has access to the area, by default, the user has access to the area even if they do not at the user level.

In the Categories tab, assign available categories to the user.

User Credentials enable administrators to assign user specific IDs required for certain functionality throughout the Lifecycle Management Suite.

Credentials may be used as a prerequisite when activating certain connectors within the Lifecycle Management Suite. For more information on whether credentials are needed, refer to the individual Connector Guides.

Administrators can add and remove credentials for a user by means of the Credentials toolbar. Once a credential is added, the below attributes may be assigned in the grid displayed:

Field	Description
Type	Select the type of user credential being added for the user. Credentials may be system-defined or specific to a connector. System-Defined Credentials: License Number - Used to identify the user that creates a loan application. This value is stored on an application when it is created. NMLS - Used to identify the users that have obtained an NMLS license.
ID	Provide a user ID.
Password	If necessary, provide a password for the user. While a password is not required for NMLS or License Number functionality, a value must be entered in the Password field in order to save the Edit User window. For the NMLS and/or License Number Credential, enter a dummy character within the Password and Confirm Password fields in order to save the User settings.
Confirm Password	If necessary, resubmit the password defined in the Password field.

In the Notification Groups tab, assign available notification groups to the user. If assigned, the user has the ability to receive notifications when a comment is added to an application via email or from the Notifications icon in the ribbon bar.

Restriction Codes are used to identify accounts containing personal information for individuals employed by or related to a financial institution.

This section allows System Administrators to restrict users from accessing specific accounts within the Lifecycle Management Suite. System Administrators can assign codes to a user that grant the user access to accounts that are restricted. Additionally, System Administrators can prevent users from accessing a person's account by adding the person's identifier to the Restricted Persons Grid.

Restricted Account

Account Restriction allows access to restricted accounts to be controlled on an account by account basis. Permissions are set on each user to give access to restricted accounts.

To enable Account Restriction in the Lifecycle Management Suite, click the "Enable Account Restriction" checkbox on the Security Tab under the Administrative Settings screen.

The restriction level on an account is determined by the Account Restriction Code field in the Lifecycle Management Suite. If Account Restriction Processing is enabled in the Lifecycle Management Suite, then a user must be given the appropriate permissions in order to view restricted accounts.

By default, all users have access to accounts with a 0 or no Account Restriction Code. To give a user access to restricted accounts, go to System Management > Users > Create/Edit > Restrictions for the user and enable access under the Account Restriction Access section.

The possible values in the Restricted Access field on each account are 0-6. The numeric values represent the following types of restricted accounts.

(0) Normal
(1) Restricted
(2) Sensitive
(3) Employee
(4) Employee Family
(5) Employee Sensitive
(6) Employee Sensitive Family

In order for a user to view an account with a Restricted Access level of 1 or higher, the user must have an Account Restriction Access of equal or greater value. For example, if an account has a Restricted Access level of 3, then a user must have a 3, 4, 5, or 6 entered in the "Restriction Code 1" field in order to view the account.

Restricted Person

System Administrators can restrict persons from a user which prevents that user from gaining access to the person’s account workspace. When a person is restricted all of the person's related accounts, cases, and tickets are restricted.

If a user is in a workspace and the secondary on a person's account is restricted, the account does not display in the workspace.

• To add a person’s account, the System Administrator must select Add from the Restricted Persons grid.
• A screen appears asking for the Person Identifier of the person you wish to prevent the user from seeing. Insert the Person Identifier and select Confirm. Once Confirm has been selected, the person’s name should appear under the Person Identifier.
• If that is the correct person that should be restricted from that user, select Save. The Person Identifier is added to the grid. To remove accounts, highlight the account and select Remove.
• If the user does not have the appropriate permissions, the user is given a message as shown below stating that they do not have access to the account. This message appears when users search for a user that they are restricted from viewing or when working a queue.

In order to view an account, the user must be allowed based on both the Restriction Code and Restricted Persons.

Lending Settings enables administrators to assign Application Sources and Restricted Account Types to a User.

At the top of the Lending Settings tab, a multi-grid containing the following tables control which application sources users are able to process applications for:

Use the multi-grid controls to assign or un assign the desired application sources.

At the bottom of the Lending Settings tab, a multi-grid containing the following tables control which restricted account types users are able to process applications for:

Use the multi-grid controls to assign or un assign the desired restricted account types.