This article describes in detail all the steps that need to be performed to make content discoverable, route access requests, and grant the resulting access.
This playbook implements the decisions made in the companion Best Practices & First Principles: Element Discoverability article.
- Decision 1 — what users see: Curated Categories vs. the Entire Catalog.
- Decision 2 — how access requests will be routed (Access Request Profiles, Custom App, Access Request API, Within Metric Insights, or External webpage).
- Decision 3 — what an approved request grants (the Element alone, or its whole Category)
1. Make Entire Catalog Discoverable
Who:
- Make Individual Elements Discoverable –> System Admin, Admin, or a Power User with Edit Access to the Element
- Setting System Variables –> System Admin
- For each Element, open its Element Editor and go to the Access & Ownership section:
- Toggle on Make Discoverable to Users Without Access.
- Adjust the preview image blur if the default is not right for this Element or upload a custom image.
- Set RESTRICT_DISCOVERABLE_CONTENT to "Y" to be able to choose which Groups may discover content under this Category/Subcategory. This enables the Content will be discoverable to the following Groups control on Access & Ownership tab of Category/Subcategory Ediors where you can select specific Groups.
- Set NEW_CONTENT_IS_DISCOVERABLE to "Y" to make Make Discoverable to Users Without Access enabled by default. This only affects newly created Elements. Existing ones still need Discoverability turned on individually.
2. Choose How Access Requests Will Be Processed
1. Access Request Profiles (recommended for new integrations)
Who: System Admins, Admins, and Power Users with the Manage User Access Requests Privilege
- Go to Content > Content Center > Profiles and click New Profile.
- Enter a Profile Name.
- Choose a Type: Freshworks, or ServiceNow once you are on v7.2.2 or later.
- Enter the API URL and API Token for your service desk endpoint.
- Customize the JSON request body template, inserting placeholders as needed: {{user_email}}, {{user_name}}, {{user_display_name}}, and {{user_id}} for the requesting user, and {{element_name}}, {{element_id}}, {{element_url}}, {{element_type}}, and {{category_name}} for the requested content.
- Save the profile, then assign it to one or more Categories.
- See Configure Access Request Profile for how to configure one.
2. Custom App
Who: System Admins, Admins, and Power Users with the following Privileges:
- Create/Edit Custom Apps
- Build Apps Using HTML
- Create/Edit App Layouts
- Create/Edit App Templates
- Go to Content > Apps and add a new App.
- Give it a name and URL name.
- Proceed to the Code tab to add HTML, CSS, and JavaScript, and embed objects. For access-request purposes, this is where the JavaScript calling the destination platform's API lives.
- Upload Assets: images, JavaScript, and CSS assets.
- Add Variables and Entities as needed.
- See Custom Apps Workflow Playbook for how to build one.
3. Access Request API
Who: System Admins
- Go to Admin > System > System Variables.
- Set "ACCESS_REQUEST_URL" to the <URL> set as an endpoint to process your company's Access Requests.
- Set "ACCESS_REQUEST_VIA_WEBPAGE" to "N".
- Set "NEW_CONTENT_IS_DISCOVERABLE" to "Y".
- [Commit Changes]
- See Access Request Overview for the setup.
4. Within Metric Insights (default)
Who: System Admins
- Go to Admin > System > System Variables.
- Set "ACCESS_REQUEST_VIA_WEBPAGE" to "N".
- Set "NEW_CONTENT_IS_DISCOVERABLE" to "Y".
- Set "SEND_ACCESS_REQUEST_DIGEST"TO "Y" or no requests will be sent.
- NOTE: No Notification Schedule is used for Access Request Digest; it will be sent when the next Schedule is run (this is usually Immediately).
- [Commit Changes]
- See Access Request Overview for the setup.
5. External webpage
Who: System Admins
- Go to Admin > System > System Variables.
- Set "ACCESS_REQUEST_URL" to the <webpage> set to process your company's Access Requests.
- Set "ACCESS_REQUEST_VIA_WEBPAGE" to "Y".
- Set "NEW_CONTENT_IS_DISCOVERABLE" to "Y".
- [Commit Changes]
- NOTE: Custom Access Denied Messages and Access Request Emails set on the Element or Category Editor are ignored in this flow. The request is sent directly to the webpage URL.
- See Access Request Overview for the setup.
3. [Optional] Customize Access Requests
1. Rename or Remove the [Request Access] Button
Who: System Admins
- Go to Admin > System > System Variables.
- Set ACCESS_REQUEST_BUTTON_TEXT to the new value.
- NOTE: If this field is left blank, the button will be removed.
- [Commit Changes]
2. Customize the Access Denied Message on the Element Editor
Who: System Admin, Admin, or a Power User with Edit Access to the Element
- Go to the Element Editor and open the Access & Ownership tab.
- Enable Use Custom Access Denied Message.
- Enter the message in the "Access Denied Message" field.
- NOTE: The field supports rich text. Use the "/" key to insert headings, lists, and images, and select text to format it.
- [Save]
3. Customize the Access Denied Message on the Category Editor
Who: System Admin, Admin, or a Power User with Edit Access to the Category
- Go to Content > Categories and click the necessary Category Active Name link.
- Open the Access & Ownership tab.
- Enable Use Custom Access Denied Message.
- Enter the message in the "Access Denied Message" field.
- NOTE: If no message is set at the Element level, this message is used for all Elements the Category contains.
- [Save]
4. Set Who Receives Access Request Emails
Who: System Admin, Admin, or a Power User with Edit Access to the Element
Element level:
- Go to Content > Elements and access the necessary Element Name Link.
- Open the Access & Ownership tab.
- Enter an address in Access Request Email.
- NOTE: This overrides the default of emailing every user flagged as a Support Admin with "Receive Access Notifications" enabled on their User record.
- [Save]
Who: Admin, or a Power User with Edit Access to the Category
Category level:
- Go to Content > Categories and click the necessary Category Active Name link.
- Open the Access & Ownership tab.
- Enter an address in Access Request Email.
- NOTE: This address is used for every Element in the Category that does not set its own.
- [Save]
4. Fulfill Access Requests
This is where Decision 2 is applied.
- Requests routed to Access Request Profiles, an External webpage, or Access Request API are fulfilled outside Metric Insights.
- If requests route to the internal Requests queue (within Metric Insights option), an Admin, or a Power User with the Manage User Access Requests Privilege, opens Requests and grants one of:
- The Tile;
- The Element;
- The Element and all its Dimension Values;
- The entire Category.
- If your grant model is Group-to-Category, the most common model where requests route externally, approval does not happen in this queue either. It happens by adding the user to the Active Directory or identity provider group tied to that Category, and Metric Insights picks up the resulting access at the next directory sync. Loop in whoever owns group structure and identity sync before you commit to this model, not after, since they own the mechanism the grant actually depends on.
- If access is meant to be synchronized from the source BI platform, such as granted directly on a Tableau workbook, for platforms where that platform rather than Metric Insights owns permissions, confirm with the documentation for that specific connector, since it varies by platform.