Change Management
Change Management helps stakeholders understand what has changed from the previous version to the latest version, who is impacted, and how processes or permissions are affected. This ensures smooth adoption and reduces operational risk.
Home
Object names can now include hyphens (-) and underscores (_), with validation controlled through a centralized backend configuration.
What Changed
In All Objects (All Data Catalog Objects, Tags, Terms, Data Products), previously, hyphens (-) and underscores (_) were not allowed in object names due to hardcoded validation rules enforced in the user interface, APIs, and LMDF uploads. When users entered these characters, the application displayed a static error message indicating that special characters, including hyphens and underscores, were not permitted. This restriction made it difficult to preserve commonly used naming conventions, such as "Prefix - Term Name".
Now, hyphens (-) and underscores (_) are supported globally in object names. Validation is driven by a backend configuration key, system.disallowed_characters, which centrally controls restricted characters. If a user enters a disallowed character, the application dynamically displays a standardized validation message that lists the restricted characters based on the configured value. APIs and LMDF ingestion processes follow the same validation rules, ensuring a consistent naming experience across the platform.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Expanded Support for Hyphens and Underscores in Object Names
Browser Extension
The Browser Extension issue-reporting experience has been updated to improve navigation clarity and provide additional context when reporting issues.
What Changed
In the Browser Extension, the Report option displayed a generic label, required users to manually provide the source URL when reporting an issue, and did not support image attachments. Now, the Report option has been renamed to Report Issue. The active browser URL is automatically captured when users initiate issue reporting, and users can attach up to 3 images to provide visual evidence. Menu labels have also been updated to provide a clearer experience for registered and guest users.
Affected Users: Registered Users, Guest Users, and Browser Extension users.
👉 For more details, see Enhanced Issue Reporting Experience.
askEdgi
Administrators can now control whether workspace data can be shared with AI services using the share.data.ai setting.
What Changed
In askEdgi, previously, AI-powered features that required workspace data processing were available without centralized control over data sharing. Now, administrators can use the share.data.ai setting to control AI-powered capabilities across askEdgi.
Affected Users: All Users.
👉 For more details, see AI Data Sharing Control.
Recipe-generated tables are now automatically saved in the Recipe Output folder for easier access and reuse.
What Changed
In askEdgi, previously, recipe-generated outputs were available only during recipe execution and were not systematically stored in the workspace. Now, all intermediate and final output tables generated during recipe execution are automatically saved in the Recipe Output folder.
Affected Users: All Users.
👉 For more details, see Auto Persist Recipe Generated Tables into Recipe Output Folder.
Workspace data is now managed using configurable retention policies with support for on-demand data reload.
What Changed
In askEdgi, previously, workspace data remained available until it was manually removed. Now, datasets are automatically purged after the configured retention period. Metadata, catalog references, and chat history remain available after the data is removed. When a dataset is purged, users can use the Reload option to restore the dataset from its source and continue their analysis.
Affected Users: All Users.
👉 For more details, see Data Reload Enhancement for Workspace.
Users can now reference governed assets directly in prompts using @mentions.
What Changed
In askEdgi, previously, the system relied on prompt interpretation and retrieval processes to identify relevant datasets, glossary terms, and other assets. Now, users can type @ and directly select supported objects such as catalog assets, business glossary terms, data products, tags, live sources, and workspace assets. askEdgi uses the selected objects as the analysis context, improving accuracy and reducing execution time.
Affected Users: All Users.
👉 For more details, see Context References Using @Mentions.
Recipe execution now provides a cleaner and more organized user experience.
What Changed
In askEdgi, previously, recipe execution displayed all execution steps and intermediate outputs directly in the chat, making it difficult to focus on the final result. Now, recipe execution displays only the final output by default while showing the progress of each step during execution. Users can expand execution details to review intermediate steps and outputs when needed. Recipe-generated outputs are also automatically saved in the workspace for future use.
Affected Users: All Users.
👉 For more details, see New Recipe Execution Workflow.
Data Catalog
Governance roles are now displayed in a consistent order across the Data Catalog, improving usability and alignment with the Security module.
What Changed
In Data Catalog, governance roles were previously displayed in a non-standardized order in certain areas of the application. The sequence of roles varied across screens, with roles such as Steward, Owner, and Custodian appearing in different orders, resulting in an inconsistent user experience. Additionally, role labels in some areas used plural or inconsistent naming conventions, reducing clarity.
Now, governance roles are displayed in a consistent, standardized order across all affected areas of the application, following the sequence: Owner → Steward → Custodian. This update applies only to screens where inconsistencies existed, preserving implementations that already followed the correct order. Role names are also displayed consistently in singular form, improving clarity and ensuring a more uniform user experience.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Standardized Governance Role Display Order
Data Products
Governance roles for Data Products can now be managed independently within the Security module.
What Changed
In Data Products, previously, there was no dedicated configuration to manage Data Product-specific governance roles. Governance roles were inherited from general configurations, resulting in inconsistent role visibility across Data Product screens and limited control over which roles were applicable. Administrators could not enable or disable roles specifically for Data Products, customize role labels or descriptions, or manage role behavior independently from other modules. Changes made to governance roles in modules such as Data Catalog or Business Glossary did not always reflect consistently in Data Products, and disabling roles could disrupt dependent workflows, such as subscription approvals.
Now, a dedicated Data Products section is available under Security → Governance Roles, allowing administrators to centrally manage governance roles for Data Products. Administrators can enable or disable roles specifically for Data Products and update role labels and descriptions to align with Data Product requirements. Governance role settings for Data Products are managed independently of Data Catalog and Business Glossary configurations. Enabled roles are consistently displayed across the Data Product Registry, Summary pages, and Data Domain security interfaces, while disabled roles are removed from all Data Product screens and selection lists. If a disabled role is configured as an approver in a Data Product workflow, the system automatically assigns the Owner role to ensure the workflow continues without interruption.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Configurable Governance Roles for Data Products
Business Glossary
Service Requests now partially fulfill updates when description fields exceed character limits, allowing valid fields to be updated while capturing skipped fields in job logs.
What Changed
In Business Glossary, previously, service request fulfillment failed completely when a Business Description exceeded 10,000 characters. As a result, none of the requested updates were applied to the object, including other description fields that were within the supported character limit.
Now, if a description field or custom field in a service request exceeds its allowed character limit, the request is marked as Partially Fulfilled. Fields within the supported character limit are updated successfully, while fields exceeding the limit are skipped. The job logs clearly identify the fields that were not updated, providing better visibility into partial fulfillment outcomes and reducing the need for manual investigation.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Long Text Values in Business Glossary Service Requests
Data Quality
The Data Quality Dashboard now displays all service requests associated with an object, providing a complete view of data quality issues and remediation activities.
What Changed
In the Data Quality Dashboard, previously, only service requests generated from Data Quality Rules were displayed. Manually created service requests were not included. Now, all service requests associated with an object, including manually created requests, are displayed in the dashboard.
Affected Users: All Users
👉 For more details, see Display All Service Requests in the Object Dashboard.
Lineage
Bridge Advance Job now replaces raw lineage parsing errors with categorized error buckets, enabling clearer failure interpretation while still preserving full technical details for troubleshooting.
What Changed
In the Bridge Advance Job module, previously, lineage parsing failures were displayed as raw technical exceptions and stack traces directly in the UI, making it difficult to interpret the actual cause of failure and slowing down troubleshooting.
Now, lineage parsing failures are categorized into structured error buckets such as unsupported SQL syntax, missing source objects, and connection-related failures. These error buckets are displayed as the primary failure message in the UI, improving readability and standardizing error interpretation across migration jobs.
Users can access complete technical details through a Details (icon) interaction, which reveals full logs, stack traces, and contextual metadata. This ensures simplified error visibility by default while still supporting deep diagnostic analysis when required.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Lineage Parsing | Error Bucket Categorization
Connectors
Bridge Status Revamp now provides complete visibility into NAR download and deployment failures, ensuring precise failure-stage identification and improved troubleshooting during bridge update operations.
What Changed
In the Bridge module, previously, bridge status transitions were inconsistent and lacked contextual clarity, with no clear distinction between user-triggered, system-triggered, or external actions.
Now, a standardized Status and Mode framework has been introduced to ensure consistent interpretation of bridge lifecycle events. The system defines uniform statuses such as Running, Warning, Stopped, Restarting, Updating, and Inactive, providing a clear representation of bridge health across all scenarios.
Each status transition now includes a Mode indicator that identifies the trigger source, such as Auto (User) for UI-driven actions, Auto (System) for automated monitoring and recovery processes, and Manual for external or OS-level interventions.
Heartbeat monitoring has been standardized with defined thresholds to drive real-time state evaluation, ensuring accurate transitions between Running, Warning, and Stopped states. Restart and update workflows now include structured progress tracking, delay detection, and failure handling with deterministic transitions.
Recovery logic ensures automatic restoration to the Running state once a healthy heartbeat is detected after degradation or downtime, improving operational continuity and visibility.
Affected Users: Administrators, Authors, Viewers
👉 For more details, see Bridge Status | Enhanced Status Visibility and Failure Tracking
File Connector Data Tab now correctly restricts row display to 500 when DuckDB is enabled, ensuring consistent and optimized data preview behavior across file connectors.
What Changed
In the File Connector (Data Tab) module, the row limit for data preview under DuckDB-enabled mode was previously configured inconsistently, resulting in the Data tab displaying up to 5000 rows instead of the intended system standard.
This behavior has now been aligned to the expected configuration, and the Data tab will display a maximum of 500 rows when DuckDB is enabled (set to true). This ensures consistent data preview behavior across all file connectors and improves performance by limiting the volume of data rendered during file inspection.
This update ensures predictable and optimized data rendering in the Data tab while maintaining consistency with the intended system design.
Affected Users: Administrators, Authors, Viewers
Copyright © 2026, OvalEdge LLC, Peachtree Corners, GA, USA.
Last updated
Was this helpful?