> For the complete documentation index, see [llms.txt](https://docs.ovaledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ovaledge.com/release7.2/hotfix-releases/release7.2.5.x/release7.2.5.31.md). # Release7.2.5.31 This release introduces key enhancements and bug fixes across Home, Data Catalog, Data Quality, Lineage, LMDF, Connectors, Data Access, and Users & Roles, improving notification consistency, catalog visibility, data quality execution, lineage accuracy and performance, masking policy management, and Data Catalog usability. **Key Highlights** * **Notifications**: Fixed outdated notification templates so that the latest saved template content and variables are reflected in triggered Teams notifications. * **Data Catalog**: Resolved missing connector codes in the Codes tab, ensuring available codes are displayed correctly for supported connectors. * **Data Quality**: Fixed execution failures for Number Validation rules, ensuring rules run successfully for columns across tables within the same schema. * **Lineage**: * Enhanced DBT lineage generation to prioritize compiled SQL for accurate table- and column-level lineage, with depends\_on used as a fallback when compiled SQL is unavailable. * Added support for wildcard file names in ADF pipeline lineage, enabling source files referenced during pipeline runs to be correctly identified. * Resolved Informatica lineage build failures caused by an incorrect SELECT 1 WHERE 1=2 addition in Source Qualifier SQL Override queries, ensuring successful lineage builds with source tables correctly connected to their respective mappings. * **LMDF**: Added bulk masking policy synchronization, enabling masking policies to be assigned to multiple table columns and synchronized with DAM and source systems when configured. * **Connectors**: * Improved DBT lineage build performance for large manifest files, including projects with 1,000+ models. * Enhanced Oracle lineage processing to identify source tables accessed through database links in dynamically executed Package Body Code SQL statements. * **Data Access**: Added support for migrating masking policies across Snowflake connections and OvalEdge environments, automatically associating policies with corresponding objects in the target environment. * **Users & Roles**: Fixed an issue where an empty Active Filter prevented data from loading in Data Catalog, ensuring the catalog opens with the expected data displayed. Release Details:
Release TypeRelease VersionBuild <Release. Build Number. Release Stamp>Build Date
Patch ReleaseRelease7.2.5.31release7.2.5.31.72531.be13d28September 30, 2026
## Notifications ### Fixed **Fixed Outdated Teams Notification Templates** In Teams Notifications, an issue where updated notification template variables were not reflected in the triggered Teams notification has been resolved. After the notification template was updated and saved, Teams notifications still displayed the previous template content. The notification process has been fixed to ensure the latest saved template content and variables appear in Teams notifications. ## Data Catalog ### Fixed **Resolved Missing Connector Codes in Data Catalog** In Data Catalog, an issue where codes were missing for several connectors in the Codes tab has been resolved. The Codes tab now correctly displays the available codes for supported connectors. ## Data Quality ## Fixed **Fixed Number Validation Rule Execution** In Data Quality, an issue where Data Quality Rules using the built-in Number Validation function failed to execute and returned an error has been resolved. The issue affected rules created for columns in different tables within the same schema. The rule execution process has been fixed to ensure these rules run successfully without errors. ## Lineage ### New & Improved **Improved DBT Lineage Using Compiled SQL** DBT lineage now prioritizes the source tables and SQL references available in compiled\_code when building table and column lineage. This helps capture lineage based on the SQL generated by DBT after processing its model logic. The following enhancements have been implemented: * Source tables referenced in compiled\_code are used to build table-level lineage. * Compiled SQL is used to derive column-level lineage. * compiled\_code is prioritized when it is available for a DBT model. * When compiled\_code is unavailable or empty, the system uses the tables listed under depends\_on to build lineage. * The fallback approach ensures lineage continues to be generated for models that do not contain compiled SQL. **Support for ADF Pipelines with Wildcard File Names** ADF pipeline lineage now supports source JSON files that use wildcard file names configured in the storage settings. This addresses cases where the file name is referenced during pipeline execution but is not directly defined in the pipeline configuration. The following enhancement has been implemented: * Source JSON files with wildcard file names are now recognized during ADF pipeline lineage processing. * File references available through pipeline runs are considered when identifying the source and target relationships. * The supported pattern is based on the sample files and use case provided by the Customer/Client. ### Fixed **Resolved Informatica Lineage Build Failure** In Informatica, an issue where the Source Qualifier SQL Override query incorrectly added SELECT 1 WHERE 1=2, causing the query to fail during lineage building, has been resolved. After removing the extra query, the lineage build succeeded, but the source tables were not connected to their respective mappings. The SQL handling has been corrected to prevent the extra query from being added. The lineage now builds successfully and connects the source tables to the correct mappings. ## LMDF ### New & Improved **Bulk Masking Policy Synchronization Through LMDF** LMDF now supports bulk assignment of masking policies to multiple table columns and synchronizes the assigned policies with the DAM and corresponding source system. This eliminates the need to configure masking policies individually for a large number of columns. The following enhancements have been implemented: * Users can upload table-column and masking-policy mappings in bulk through LMDF. * Masking policies are automatically assigned to the specified table columns during the LMDF process. * Masking policy assignments are synchronized with the DAM. * The assigned masking policies are also applied to the corresponding columns in the source system when Sync to Source is enabled. * Updated masking policy information is reflected consistently across the relevant OvalEdge screens. * Bulk processing reduces the manual effort required to manage masking policies across multiple columns. ## Connectors ### New & Improved **Improved DBT Lineage Build Performance for Large Manifest Files** DBT lineage builds have been optimized to improve processing performance for large manifest.json files. The enhancement addresses performance issues observed during lineage validation and improves the ability to process projects with a large number of DBT models. The following enhancements have been implemented: * DBT lineage processing is optimized to handle large manifest files more efficiently. * Performance bottlenecks in lineage build processing have been addressed. * Processing has been improved to support DBT projects with 1,000+ models. * Resource-intensive processing is optimized to reduce overall lineage build time. * Lineage builds are now better suited for large DBT projects, helping reduce delays during lineage validation and delivery. **Oracle Lineage Support for Database Links in Package Body Codes** In Oracle Package Body Codes, lineage is not generated for source tables accessed through database links when the SQL statements are executed dynamically using EXECUTE IMMEDIATE. This can result in missing lineage between remote source tables and the target tables referenced by the package. With this enhancement, Oracle lineage processing has been improved to identify source tables referenced through database links in dynamically executed SQL statements. This enables lineage to be captured for applicable static table and database link references within Package Body Codes. ## Data Access ### New & Improved **Migrate Masking Policies Across Snowflake Connections** Advanced Jobs now support migrating masking policies configured for the same object across different OvalEdge environments, such as Development and Production. This allows the masking policy configured in the source environment to be carried over to the corresponding object in the target environment. The following enhancement has been implemented: * Masking policies can be migrated along with the corresponding objects across OvalEdge environments. * The masking policy is automatically associated with the matching object in the target environment. * Manual reconfiguration of masking policies after migration is no longer required. * The migration is supported through Advanced Jobs or the applicable OvalEdge migration mechanism. ## Users & Roles ### Fixed **Resolved Empty Active Filter in Data Catalog** In Data Catalog, an issue where an empty Active Filter was applied automatically prevented data from being displayed. Users could not remove the filter from the Data Catalog view. The issue has been resolved by correcting the default filter behavior so data displays as expected when opening the Data Catalog. *** Copyright © 2026, OvalEdge LLC, Peachtree Corners, GA, USA. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ovaledge.com/release7.2/hotfix-releases/release7.2.5.x/release7.2.5.31.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.