Best Practices & First Principles: Element Discoverability
This article provides a strategic overview of the Discoverability feature in Metric Insights. It outlines what Discoverability is, the roles involved, and the architectural requirements for implementing a discoverable data environment.
Discoverability Model
Discoverability is used to allow users to initiate a governed access request to content directly from the Tile, even if they don't yet have Permission to view it, reducing the administrative burden on support desks.
The Discoverability model enables:
- The Catalog as a comprehensive index: Users view Tiles for certified or high-value content regardless of their current access permissions.
- Granular visibility control: Discoverability can be scoped at the Category or Subcategory level, not just per Element — so you can make an entire Category discoverable only to selected groups, with its own custom messaging.
Required Administrator Roles
| Role | Responsibilities |
|---|---|
| System Administrator | Configures the global access request flow. Manages system-wide Discoverability variables and security settings. |
| Data Steward/ Category Owner | Determines which Elements, Categories, or Subcategories are eligible for Discoverability. Defines custom messaging and Tile blur levels. |
| Power User/ Approver | Manages the access request screen. Evaluates user requirements and grants Permissions or Privileges to specific Elements or entire Categories. |
| System Administrator/Access Request Profile Administrator | Creates and manages Access Request Profiles (via the Content Center Profiles tab), which determine how requests are routed depending on the target system. |
Recommendations Before Implementation
Prior to enabling Discoverability, evaluate the following technical and governance requirements:
- Establish Certification Standards: Limit Discoverability to "Certified" content. Allowing discovery of draft or unverified objects reduces the reliability of the search index.
- Determine Blur Levels (optional): Configure the preview image blur based on the sensitivity of the data visualization. The objective is to confirm the existence of a Report (e.g., showing a chart structure) without displaying specific data values to unauthorized users.
- Define the Request Pathway: Determine how access requests are routed and what the requester actually sees. Consider:
- Who needs access to what: identify which users or groups require access to specific Elements or Categories, and who is responsible for reviewing those requests.
- What the request screen displays: the custom message shown to the user, and what action the request button triggers.
- Where the request goes: whether it's handled by internal notifications to individual Element owners, or routed through an external workflow tool, or requires a Custom App that integrates with a third-party system.