Encompass® configuration decisions compound over time. What starts as a small workaround in TPO Connect, a complex Word merge, or an unclear condition setting can quietly create friction across underwriting, disclosures, and funding.
When workflows feel inconsistent, the issue is rarely the platform itself. More often, it comes down to structure, clarity, and understanding how Encompass® separates roles, documents, conditions, and automation.
In a recent Ask Me Anything Encompass® | Admins & Users workshop, several recurring themes surfaced that are worth unpacking more broadly: TPO notification limitations, smarter custom field strategies, enhanced condition configuration, and the difference between document tracking and condition tracking.
Here’s what matters most.
TPO Connect Notifications and Role Limitations
One of the first questions focused on sending notification templates to a delegated TPO contact.
The challenge: internal notification templates do not easily fetch email addresses from externally mapped TPO contacts unless they are hard-coded in the original configuration. While standard TPO Loan Officer and Loan Processor roles work as expected, newly created delegated roles may not behave the same way.
The core takeaway is this: Encompass® distinguishes between internal and external users at the database level. Assigning a role in TPO Connect does not guarantee that notification templates can retrieve that email address.
When native functionality does not support the use case, lenders often rely on:
- Updating mapped email fields dynamically through business rules
- Using external automation tools
- Submitting enhancement requests directly to ICE
Understanding the boundary between what Encompass® was designed to do and what it can be extended to do saves hours of troubleshooting.
Custom Fields vs Word Merge Logic
Another discussion revisited Word merge complexity and how to simplify conditional language in custom print forms.
Instead of embedding complicated merge code inside Word documents, the recommended approach is to:
- Create a custom field
- Use a nested IF statement inside the field calculation
- Output the final formatted string
- Merge that single field into the document
This method improves:
- Testing
- Debugging
- Visibility on input forms
- Long-term maintainability
For example, combining borrower and co-borrower names conditionally can be handled entirely in a custom field calculation rather than layered merge code.
When working with numeric values, remember:
- Use Integer field types when you do not want decimals
- Decimal format settings only limit display, they do not change field behavior
Small structural decisions make long-term document management significantly easier.
Enhanced Conditions: Clearing, Roles, and UI Confusion
Enhanced Conditions sparked several important clarifications.
First, condition status behavior:
- If the Cleared box is checked in settings, that role is allowed to mark conditions as cleared
- If it is unchecked, they cannot
- Roles are controlled at the condition type level, not within the individual condition
Second, a reminder about role-based behavior: Condition permissions are tied to job roles, not specific users. If a role does not exist in the milestone template, the system can still apply its settings depending on configuration.
Third, troubleshooting status issues: If a condition appears cleared but the UI does not update properly, test the behavior in Encompass® Web and export a HAR file. This captures the backend activity and gives ICE support concrete data to review.
Moving from Standard to Enhanced Conditions
A major theme was migration hesitation.
The Condition Migration Tool allows lenders to move from Standard Conditions to Enhanced Conditions quickly. The most common mistake is trying to clean up and reorganize every condition before migrating.
Do not over-engineer the move.
Instead:
- Migrate first
- Activate only what you need
- Refine condition types afterward
Trying to perfect your taxonomy before transitioning often delays projects indefinitely.
Condition Workflow vs Document Workflow
One of the most important distinctions of the workshop was this:
Documents are not conditions. Conditions are not documents.
Documents represent files received. Conditions represent underwriting requirements.
An optimized workflow looks like this:
- Documents are marked received in eFolder
- Corresponding conditions are marked fulfilled
- Underwriters review from the Conditions tab using filtered views
This prevents underwriters from digging through File Manager unnecessarily and keeps reviews structured and intentional.
Using clear terminology such as Fulfilled instead of Received reduces confusion between document tracking and condition tracking.
Web Behavior and Custom Field Calculations
A final reminder covered Encompass® Web behavior.
Custom field calculations in Web do not refresh dynamically while moving between fields. They update on Save. This is working as currently designed.
If behavior seems inconsistent:
- Confirm in Web
- Capture a HAR file
- Submit through support with backend evidence
Understanding the platform’s intended behavior prevents chasing problems that are not actually defects.
Join Us Live
This article was inspired by our February 3 Ask Me Anything Encompass | Admins & Users workshop.
Each workshop is open to anyone using Encompass®, whether you manage personas, build rules, configure TPO, or support operations.
🎥 Watch the replay or join a live workshop at MasteringEncompass.com
Mortgage Workflow Partners Inc. Helping lenders simplify, standardize, and scale their Encompass® workflows.
Leave a Reply