applications

No menu items for this category
Collate Documentation

Reverse Metadata Application

The Reverse Metadata Application ensures real-time synchronization of metadata changes. Once installed and configured, any updates made to selected assets in Collate—such as descriptions, tags, or owners—are automatically in real-time propagated back to the source systems. There’s no need to trigger the application manually. This live sync ensures Collate remains the single source of truth while all connected systems stay up to date and compliant with governance policies.

ConnectorsUpdate DescriptionUpdate TagsUpdate OwnersCustom SQL SupportDocumentation
Athena✅ (Table)Link
BigQuery✅ (Schema, Table)✅ (Schema, Table)Link
Clickhouse✅ (Table, Column)Link
Databricks✅ (Support all)✅ (Support all)✅ (Database, Schema, Table)Link
MSSQL✅ (Schema, Table, Column)✅ (Database, Schema)Link
MySQL✅ (Table)Link
Oracle✅ (Table, Column)Link
PostgreSQL✅ (Support all)✅ (Database, Schema, Table)Link
Redshift✅ (Support all)✅ (Database, Schema, Table)Link
Snowflake✅ (Support all)✅ (Schema, Table, Column)Link
Unity Catalog✅ (Support all)✅ (Support all)✅ (Database, Schema, Table)Link
Trino✅ (Table, Column)Link
Tableau✅ (Dashboard, Chart)✅ (Dashboard, Chart)✅ (Dashboard)Link

With this application, you can automatically sync metadata changes such as:

When you update the table or column descriptions in Collate, these changes will get updated in the selected data assets based on your defined logic.

Example:

  • The customer_orders table in Collate has the description updated to: "Stores historical order transactions from all regions."
  • This updated description is written back to the customer_orders table using the configured channel as per your defined logic.

You can assign ownership (individuals or teams) to data assets in Collate and sync this information back to the data source.

Example:

  • You assign John Doe as the owner of the table customer_data in Collate.

  • This ownership info is saved in the original system’s metadata, making it easier to identify responsibilities and understand data flow.

  • Team ownership is currently not supported in the reverse metadata sync process. Support for syncing team-based ownership may be introduced in future releases.
  • The owner update functionality currently supports syncing only a single owner back to the source system.
  • If an entity in Collate has multiple owners, only one owner will be propagated during the reverse metadata sync.
  • Support for syncing multiple owners is planned for future enhancements.

Tag metadata (like PII, sensitive, finance-related, etc.) applied in Collate can be sent back to the source system to enforce governance policies.

Example:

  • You apply the tag PII.Sensitive to the XYZ data asset.
  • If the logic is defined, this tag will also be updated in the corresponding data asset in the source system.
  • Automated Metadata Propagation: Sync metadata updates (tags, owners, descriptions) from Collate to source systems without manual intervention.

  • Configurable Channels:
    Create multiple sync channels to define exactly which asset or metadata types to sync. Once configured, changes sync live — no manual action needed.

Use SQL templates to customize update behavior per connector.

VariableDescriptionContextType
databaseThe identifier of the database or catalogAlwaysString
schemaThe identifier of the schemaAlwaysString
tableThe identifier of the tableAlwaysString
columnThe identifier of the columnAlwaysString
descriptionRefers to the descriptionDescription updateString
ownerThe identifier of the owner being added or removed. This value can be a username or an email and depends on the source system.Owner updateString
tag_keyThe key of the tag being added or removed (Classification)Tag updateString
tag_valueThe value of the tag being added or removedTag updateString
tagsRefers to a list of tags (e.g., BigQuery). Example: [('my_tag', 'value'), ('env', 'prod')]AlwaysList[Tuple[String, String]]
  • Maintain consistent metadata across Collate and Database by syncing SQL-based description updates.
  • Improve data discovery by propagating column-level comments from Database back into Collate.
  • Strengthen governance by capturing ownership changes in Database through SQL and syncing them to Collate.
  • Enhance metadata visibility by syncing Database tag updates (e.g., PII.Sensitive) into Collate.
  • Drive metadata accuracy by reflecting schema description changes in Database directly within Collate.
  • Unify metadata management by capturing SQL-applied labels in Database and syncing them automatically to Collate.

Use the following SQL templates to filter your database operations and automatically trigger reverse metadata sync when these queries are executed.

SQL Variable:-

example:-

This query updates the database description. When executed, it can trigger a reverse metadata update for description fields.

SQL Variable:-

example:-

Use this to assign ownership of a table. You can specify email addresses, such as those under a particular domain, to trigger reverse metadata for ownership fields.

SQL Variable:-

example:-

This sets or updates schema-level labels, such as sensitive classifications. Useful for tagging metadata like PII & sensitive, to automatically trigger reverse metadata for Tags fields.

  1. Navigate to Settings > Applications.
Install Reverse Metadata Application

Install Reverse Metadata Application

  1. Click Add Apps and install the Reverse Metadata Application.
  2. After installation, configure the synchronization channels as described below in screenshot. The Filter section allows you to define which assets should be included in a sync channel by applying conditions based on tables: the service, database or schema they belong to, their name, owners, domain, and even by Custom Properties!
Configuration

Configuration

In the Above screenshot, a filter is set to update descriptions only when the tag is "Sensitive." This helps keep all sensitive tag descriptions in sync. At the same time, reverse metadata runs automatically.

Each sync process is managed through a channel.
You can define multiple channels for different services or metadata types.

FieldDescription
Channel NameA name for identifying the sync channel.
FilterUse the UI Query Filter Builder to define the scope of the metadata updates. You can filter by properties such as service, schema, database, owner, domain, or custom attributes.
Update DescriptionsEnable to sync updated entity descriptions from Collate to the source.
Update OwnersEnable to sync owner assignments from Collate.
Update TagsEnable to sync tag assignments (e.g., PII) to the source system.
Sink ServiceOptional. Specify a target service where metadata changes should be synced. Currently supports security services only. The service name must match exactly with the service name configured in OpenMetadata.
SQL TemplateOptional. Specify a custom SQL template for updates.

The Sink Service parameter allows you to redirect metadata changes from one service to a different target service. This is particularly useful when you want to maintain metadata consistency across different systems.

Scenario: You have a Trino service configured in OpenMetadata, but you want to sync all metadata changes to your Apache Ranger security service for centralized governance.

Example Channel Setup:

FieldValue
Channel Name"Trino to Ranger Sync"
FilterService: trino_prod
Update Tags✅ Enabled
Sink Serviceranger_service

How it works:

  1. You update a table tags in the Trino service within Collate
  2. The reverse metadata application detects this change
  3. Instead of syncing back to Trino, it syncs to the specified Ranger service
  4. The Ranger service receives the updated metadata and applies governance policies

Important Requirements:

  • The sink service name must exactly match the service name configured in OpenMetadata
  • Currently, only security services are supported as sink services
  • Ensure the sink service has the necessary permissions and configurations to receive metadata updates
Scheduling

Scheduling

Users can monitor the running state of workflows, and in case of a failure, use the options below to clean them up:

  • Run Now:- This lets you manually initiate a cleanup operation for failed workflows. This option will only be used to clean workflows. They will not trigger reverse metadata. It is an automatic synchronization.
  • Scheduled Run:- This automatically re-runs cleanup operations based on a defined schedule (e.g., daily or weekly).

The Run Now option currently does not trigger any reverse metadata workflows. It is intended for manual cleanup of failed operations only.

Support for batch reverse metadata execution via Run Now is planned for future releases. This note is added to help set clear expectations for users.

Recent Runs

Recent Runs

In the Recent Runs tab, users can monitor the results of all workflow executions. Detailed logs are available for each run, making it easy to review outcomes and troubleshoot any failures.