Encompass User Management Guide

• Model type: role-based
• Description: Encompass uses a Persona-based permission model. Each user is assigned one or more Personas, which are predefined or customized role templates that control access to screens, fields, loan folders, reports, and administrative functions. Field-level access can be configured within personas. Organizational hierarchy (branches, divisions) further scopes data visibility.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: Persona-level with field-level and folder-level access controls. Administrators can create custom personas and restrict or grant access to individual screens, fields, and loan folders.

1. Log in to Encompass as an Administrator.
2. Navigate to Encompass > Admin > User Management.
3. Click 'New' or 'Add User' to open the user creation form.
4. Enter required user details: Login ID, name, email address, and password.
5. Assign the user to an organizational hierarchy node (e.g., branch or division).
6. Assign one or more Personas to define the user's permissions.
7. Configure additional settings such as loan folder access, reporting groups, and licensing options as needed.
8. Click 'OK' or 'Save' to create the user account.

Required fields: Login ID (username), First Name, Last Name, Password, Organizational hierarchy assignment, Persona assignment

Watch out for:

• Login IDs must be unique across the Encompass instance and cannot be changed after creation.
• A user without a Persona assigned will have minimal or no functional access.
• Users must be placed within the organizational hierarchy; placement affects which loans and data they can see.
• Email address is required for certain notification and eFolder features.

• Can delete users: Unknown
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Log in to Encompass as an Administrator.
2. Navigate to Encompass > Admin > User Management.
3. Search for and select the user to be deactivated.
4. Uncheck or toggle the 'Active' status for the user account.
5. Save the changes. The user will no longer be able to log in.

Watch out for:

• Deactivated user Login IDs cannot be reused for new users; the account persists in the system.
• Administrators should reassign open loans from a departing user before deactivating the account to avoid workflow disruption.
• Some integrations or automated tasks configured under the user's credentials may fail after deactivation.

• Where to check usage: Encompass > Admin > User Management (filter by Active users to view current seat consumption)
• How to identify unused seats: Administrators can filter the User Management screen by last login date or active status to identify accounts that have not been used recently. No automated unused-seat reporting tool is documented in official help.
• Billing notes: Encompass is sold on a subscription basis with custom enterprise pricing. Seat counts are negotiated at contract time. Deactivating users frees seats for reassignment within the contracted count. Contact ICE Mortgage Technology account management for seat additions or contract changes.

Every app tied to a departing employee carries risk until that account is deactivated - Encompass does not permanently delete users, so the operational task is toggling the Active status off, not removing a record. Administrators should reassign open loans before deactivating;

integrations or automated tasks running under that user's credentials will silently fail after deactivation. Login IDs cannot be reused once created, which compounds offboarding overhead when replacement hires need accounts that mirror a prior naming convention.

Bulk user operations are not well-supported in the standard admin UI. Large onboarding events - new branch openings, acquisitions - require either manual entry per user or API use, since no documented bulk-import tool exists in the console.

Persona configuration adds another layer: the interface is reported by administrators as complex to manage at scale, particularly when many role variations exist across divisions.

Community evidence is not specific enough to quote or summarize yet for this app.

Manual administration is workable for organizations with stable headcount and infrequent role changes. The Persona model is powerful but demands upfront investment in configuration - every user must have both a valid Persona and a correct org-node placement before they have functional access.

Teams with high loan officer turnover, multi-branch structures, or frequent persona changes will find the manual process increasingly error-prone at volume.

TPO users are managed through a separate module (TPO Connect) with distinct licensing; do not assume internal user management workflows apply to external originators. Confirm seat counts against contracted limits before bulk onboarding, as Encompass is sold on a custom subscription basis and seat additions require account management engagement.

Bottom line

Encompass user administration is reliable for steady-state operations but surfaces real friction at scale: immutable Login IDs, non-recyclable deactivated accounts, and a Persona configuration layer that requires careful upfront design.

Every app and workflow in the loan pipeline depends on correct Persona and org-node assignment - gaps here produce access failures that are not always obvious to diagnose.

Organizations managing frequent headcount changes or multi-branch structures should evaluate whether the manual console alone is sufficient or whether API-driven provisioning is warranted.