Collibra Community

Thanks to everyone who joined our first Data Products User Group session! Here's a quick summary to share alongside the recording and slides. Watch the recording here Download the slides here What we covered We walked through three phases of the data products journey — getting started, scaling, and proving ROI — with practical frameworks and live poll responses from attendees shaping the conversation in real time. Key takeaways Define before you build. A data product isn't just a table or dashboard. It needs a named owner, business context, quality rules, SLAs, and discoverability. Every data product = data + context + controls + access. Pick your first use case carefully. Look for recurring pain, existing demand, data you already have, bounded scope, a committed owner, and a win you can show off. Use a value vs. effort grid to prioritize. Nail the five foundations early. Named ownership, a governance baseline, shared semantics, a reusable template, and a central marketplace. Get these right once and every product after gets easier. Scale through a flywheel, not a big bang. Pilot → codify → expand → reuse. Launching a full marketplace before you have a proven first product is the most common way to overspend. Tie every product to a value driver. Revenue, cost, risk, or speed. If you can't connect a data product to at least one of these, pause before building. Track adoption weekly, report ROI quarterly. Leading indicators: active consumers, time to first data, reuse rate. Lagging indicators: hours saved, cost avoided, revenue influenced. What you told us The biggest bottlenecks in the room: organizational buy-in and change management, defining ownership, and getting producers and consumers aligned. What's next Upcoming topics will dig deeper into data contracts, change management, ownership models, and measuring ROI. Have a topic you want covered? Post it in the Data Products User Group in the Collibra Community.

I am working with Collibra and I need to export some datas. For a given asset (A), I have multiple related objects: for example 3 data models and 2 QRULs. When I export the data, I only get 3 rows where data models and QRULs are associated in a seemingly arbitrary or partial way. However, I would expect to get the full Cartesian product of these relationships, meaning all possible combinations between the 3 data models and the 2 QRULs (so 6 rows in total). How can I configure the export or transformation so that I get all possible combinations instead of only randomly matched pairs? Thanks for your help Daphné

Hey all, I'm developing a workflow that has the following purpose: Data stewards will select some columns that they deem necessary to add to a created data set for a specific purpose (such as... AI's use cases), and will submit the data set to this approval workflow. The data set will contain multiple columns coming from different tables, and with different approvers assigned to its columns. With that said, our idea is that the columns would be approved only by the assigned approvers and not by all stewards involved in this process. Is this feasible? If so, what would be the best approach to develop the workflow to achieve this goal? Also, imagine a situation where we have 5 approvers involved in the data set approval process, but not all of them have approved their columns. 4 of them have approved, and only one rejected it. In our process, if an approver rejects the metadata of their columns, the columns would return to a step where someone responsible for fixing them would need to do it. So, my other question is: is it feasible to return to this point, only the rejected columns, and the approved ones proceed to the next phase? Or if one approver rejected it, the entire data set will go to the "fixing phase"? Regards.

Hi, the Collibra Data Product to OSI Semantic Model marketplace workflow creates a OSI YAML file to a Data Product Port. However, when I run this, I'm getting an exception stating that the "resource type (text/x-yaml) is invalid". Is the solution for this simply to add the x-yaml mime type to the system? There's no discussion of this in the workflow documentation. Thanks

Bonjour! Voici le lien pour accéder aux slides présentés lors de notre session de ce mois. Sujet du mois : Focus sur les releases 2026.05 et 2026.06 N'hésitez pas à envoyer vos questions! https://view-su2.highspot.com/viewer/4989e085dbc1f010812b74c1a03cadcd

Signal app id ( Drops.11) , dmt vape pen, dmt carts pen online. dmt vape pens in Brussels , dmt pen online in Belgium , dmt vape cartridge.

As Snowflake transitions from service credentials to key pair authentication, our organization is encountering issues during integration with Collibra. Specifically, when launching metadata scans using the new key pair authentication, duplicate assets can appear. While managing duplicates is relatively straightforward, transferring existing asset curation (like descriptions, tags, and business associations) from the old connection to the new one poses significant challenges. Has anyone implemented effective strategies or developed tools to facilitate bulk curation transfer to the newly created assets under the new authentication method? Sharing your experiences or solutions will greatly benefit community members facing similar challenges.

Can the asset model capture metadata about relationships between assets ? specifically by modelling attributes on relationship between two assets ?

Which relation types are recommended to be used for Business Terms in the Business Glossary? It seems to be natural for me to connect also Data Entities to them, but in Guided Stewardship only Data Attributes are offered. I went over several documentation, community articles etc. but haven't found why a direct relation from Business Terms to Data Entities are not seen as best practice. Either a relation to Data Domains and thus to Data Entities or a relation directly to a Data Attribute is mentioned. Please help me to understand the reason behind! https://productresources.collibra.com/docs/collibra/latest/Content/Assets/Characteristics/Relations/RelationTypes/ref_relation-types.htm https://community.collibra.com/forum/best-practices-83/topic/help-grow-our-universal-metadata-model-6427/ This article also draws the line only the data attribute. But there could be also a business term for the sales account (which should also be clearly defined in the glossary). https://www.collibra.com/blog/the-secret-to-trusted-ai-it-s-your-semantic-layer