Community Resources
Participate
Learn
Support
User Groups and Events
We’re excited to share the improved Collibra Community ! Based on feedback from our members, we’ve made big improvements to enhance your experience and make it easier to collaborate, find information, and stay connected. What’s new? A modern, updated design for more straightforward navigation A better forum experience with improved discussion filtering A more robust customer user group experience for deeper engagement Improved email communications and notifications to keep you informed A new Welcome Center to help members get started Note: As we update the back-end, your points and badges will not be available on the platform until mid-to-late 2025. Once complete, your gamification information will be restored. What’s stayed the same? The Community URL, email ([email protected] ), and login process remain unchanged. All discussions, knowledge base article,s and resources are still available If you have any questions, please reach out to [email protected] . We’re here to help! Please see this post on how to start a discussion We can’t wait for you to explore the new Collibra Community! Best, The Collibra Community Team Hey there, How bad would it be performance-wise (or otherwise) to have ~150-200 multi-day workflows running at one time? For context, I'm considering whether we should build complex, multi-day approval workflows in Collibra vs. another tool. Coming from an Appian background, my approach has always been to store request state (created, approved, returned for revision, etc.) in a record/database entity, and use "workflows" only to move the request between states (kicking a new workflow off when someone takes action, and completing it when the action is finished & new request state is written to the database). Is this a common practice with Collibra workflows as well? If not, have you seen/heard about any performance issues that may come from hundreds of workflows sitting in memory for days at a time? Thank you! Reporting Specifications I want to Build out my reporting specification in Collibra hand it to a Tableau builder dude Tableau report is subsequently built and harvested into Collibra, along with lovely lineage to Redshift My Q is, what asset types do you use to build the report specification? This is a business asset so it feels wrong to use Data Product b/c while Blue like Report, it takes inputs and outputs (both data assets). Data Set & Data Element, but again both are data assets whereas a report specification is a business construct. I could use Report, with Business Terms, Metrics & KPI for the report grain/constituents. Then; relate the Report to the actual Tableau blue assets (Dashboard or Worksheet) via OOTB Business Asset groups Business Asset. if keen, relate the functional grain to the Tableau Data Attribute via Business Asset represented by Data Attribute. I ask also b/c we have legacy Report Catalogs with Tableau reports built manually as Report and Report Attributes that I want to keep, because our business users get confused by the Tableau Op Model.... so it's easier to leave them there and just relate them to the harvested Dashboard etc. In the end the conclusion was KISS Specifications > Business Term Business data points in the Specification > Business Term (and Metrics, where relevant) Anyway, keen to hear what others have done.
