Element Discoverability & Access Workflow Playbook

This playbook implements the decisions made in the companion Best Practices & First Principles: Element Discoverability article. Complete these three decisions there before starting:

• Decision 1 — Curated Categories vs. the Entire Catalog. Determines whether NEW_CONTENT_IS_DISCOVERABLE is on or off in Step 1.
• Decision 2 — how access requests will be routed (Access Request Profiles, Custom App, Access Request API, Within Metric Insights, or External webpage). Determines which option you configure in Step 2.
• Decision 3 — what an approved request grants (the Element alone, or its whole Category), decided as a standing policy rather than case-by-case at approval time. Determines how you answer Step 6 every time a request comes in, and who else needs to be involved before you finalize it.

1. Set the system variable SHOW_ITEMS_WITHOUT_ACCESS to "Y". This is the master switch — while it is off, none of the settings in this playbook have any effect.
2. Set NEW_CONTENT_IS_DISCOVERABLE based on Decision 1:
   • Entire Catalog model: set to "Y" so that newly created Elements default to discoverable, keeping the Catalog complete without manual follow-up.
   • Curated Categories model: leave at "N" (default) so that Discoverability stays a deliberate, per-Element action (Step 3).

      Either way, this only affects newly created Elements. Existing ones still need Discoverability turned on individually in Step 3.

3.    Optionally, adjust where discoverable content shows up:

• HIDE_DISCOVERABLE_CONTENT_FROM_HOMEPAGE: hide it from the Home page specifically.
• SHOW_DISCOVERABLE_CONTENT_IN_FOLDERS: show or hide it inside folders (on by default).
• DISCOVERABLE_CONTENT_DISPLAYS_DOCUMENTS: include or exclude Documents and External Content among the discoverable tile types.

Decide how a request is handled once a user clicks "Request Access". Pick the option that matches Decision 2, and route requests into whichever platform your organization already uses for access approvals, so that Discoverability requests do not create a second, parallel process:

• Access Request Profiles (recommended for new integrations): a native, no-code way to post the request, with full context, to an external system's API, configured per Category instead of a system variable. Supports Freshworks natively today. Set this up in Step 4. NOTE: ServiceNow support is expected in v7.2.2.
• Custom App: for a workflow tool not covered natively by a Profile — including ServiceNow today, or others like Jira or an internal ITSM — build a Custom App that captures the request context and calls that system's API directly. See Custom Apps Workflow Playbook for how to build one.
• Access Request API: set ACCESS_REQUEST_URL together with ACCESS_REQUEST_URL_USERNAME and ACCESS_REQUEST_URL_PASSWORD to post the request to an existing external API (originally built for SAP GRC). Use this only if you already have such an integration in place.
• Within Metric Insights (default): set ACCESS_REQUEST_VIA_WEBPAGE to "N". Requests are logged and land in the internal Requests queue for an Admin to approve (Step 6). Set SEND_ACCESS_REQUEST_DIGEST to "Y" (the default) so that Admins who have opted in to receive access notifications get a daily digest. Workable for small deployments, but it keeps approvals outside any external request process you already run elsewhere.
• External webpage: set ACCESS_REQUEST_VIA_WEBPAGE to "Y" and ACCESS_REQUEST_URL to your form's URL. Metric Insights hands the user off to that form. It does not pass along the Element, requester, or any other context, and it ignores whatever custom Access Denied Message you set up in Step 5. Treat this as an interim option only, since users have to re-enter information Metric Insights already had.

Finally, set ACCESS_REQUEST_BUTTON_TEXT to whatever label you want on the request button (defaults to "Request Access"), or remove or rename it if content is visible without inviting a request at all.

For each Metric, Report, or other Element, open its Element Editor and go to the Access & Ownership section:

1. Turn on the Discoverability toggle.
2. Select an Access Request Group if you want to restrict who this applies to. This is hidden if requests for this Element route to an External webpage or an Access Request API instead of being processed Within Metric Insights.
3. Adjust the preview image blur if the default is not right for this Element. The default comes from DISCOVERABLE_CONTENT_IMAGE_BLURRING_DEFAULT, or 4 if that is unset. Match the level to data sensitivity — enough to show that a chart exists and its shape, not enough to read values. Custom uploaded images are never blurred.
4. Optionally, set an Email for Recipient of Access Requests to override who is notified for this specific Element. If left blank, it falls back to the Category's own recipient email (Step 4), and if that is also blank, to every user flagged as a Support Admin — not to a single "System Admin" account.
5. Optionally, enable a custom Access Denied Message for this Element (see Step 5).

Category-level settings apply to every Element beneath that Category unless the Element itself overrides them. Open the Category editor:

1. If RESTRICT_DISCOVERABLE_CONTENT is enabled, choose which Groups may discover content under this Category.
2. Optionally, set a category-wide Email for Recipient of Access Requests.
3. Optionally, enable a custom Access Denied Message for the Category (Step 5).
4. If you are using Access Request Profiles (Step 2), assign one here. A Category without its own assignment inherits the nearest enabled profile from a parent Category, so assigning one at the top of a content area applies it everywhere beneath.

To create an Access Request Profile, do this before it appears in the dropdown above:

1. Go to Content > Content Center > Profiles and click New Profile.
2. Enter a Profile Name.
3. Choose a Type: Freshworks, or ServiceNow once you are on v7.2.2 or later.
4. Enter the API URL and API Token for your service desk endpoint.
5. 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.
6. Save the profile, then assign it to one or more Categories as described above.

Once assigned, requests for Elements under that Category are sent directly to your external system's API and will not appear in the internal Requests queue (Step 6).

When a user without access clicks a discoverable tile, Metric Insights shows an Access Denied Message. It is resolved in this order, and the first custom message found wins:

1. The Element itself, if it has a custom message enabled.
2. Its direct parent Category, if that Category has a custom message enabled.
3. The nearest ancestor Category above that with a custom message enabled, walking up the content tree.
4. If nothing along the way has a custom message, a generic default message is shown, directing the user to contact their system administrator.

Enable a custom message at the Element or Category level from the same editor screens used in Steps 3 and 4. This has no effect if requests for that content route to an External webpage (Step 2), since that flow always redirects to your form regardless of any message configured here.

This is where Decision 3 is applied. Whichever model you settled on, use it consistently rather than deciding Element-versus-Category grant scope request by request.

• If requests route to the internal Requests queue (Step 2's Within Metric Insights option), an Admin, or a Power User with the Manage User Access Requests Privilege, opens Requests and grants one of:
  • This Element only: grants just the specific item that was requested.
  • This Element and all its Dimension Values: for segmented content, grants the Element plus every dimension value instead of just the one the user encountered.
  • The entire Category: grants access to everything under that Element's Category.
• If your grant model is Group-to-Category, the most common model where requests route externally, approval does not happen in this queue at all. 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.

Requests routed to an External webpage, an Access Request API, or Access Request Profiles (Step 2) are fulfilled outside Metric Insights and never appear in this queue.