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:
Patch Release
Release7.2.5.31
release7.2.5.31.72531.be13d28
September 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.
Last updated
Was this helpful?