Documentation

Embed

Filtering Options

Client-side filters

This specific file in the public folder shows examples of convenient client-side JS API filters.

  • This listens for click events on the embedded content and passes them back up to the host page for cross-system links.
  • It also completes the bi-directional passing of context by letting the host page push filters down into the embedded content without refreshing the iframe like pfilters.

To get started using JS API filters reach out to your Domo Account Representative to make sure the feature is enabled and then check out the demo video below:

URL Parameters

Transparent Background

Many embed customers customize the dashboard background color or image to make embedded content feel native.

 

With this URL parameter, making the background totally transparent can make embedded content seem even more native to the host page.

Here is how an embedded dashboard looks when the background is the host page is black and the URL parameter is set to true (?transparentBackground=true)

 

 

Here is how that same embedded dashboard looks when the background transparency is set to false (?transparentBackground=false)
 

 

P Filters

This article in the Domo knowledge base shows examples of even simpler convenient URL parameters called “Pfilters” (parameter filters).

  • These follow the same pattern of defining a column, operand, and value to filter.
  • They can even be created and persisted automatically when embedded content links to other embedded content while maintaining the items that have been clicked previously.

All these filter types are layered in this sequence:

SECURE FILTERS

1. Personalized Data Permissions (PDP)
Documentation: SSO and PDP
Definition: Older SSO integration reliant upon cookies for individual accounts for each viewer
Use case: Forced row-level security defined in the Domo interface that cannot be seen nor edited by viewers
Warning: Browsers are expanding their 3rd party cookie blocks. The best practice is to use Programmatic Filters to stay future-proof.
Note: If this older method must absolutely be used for personalization, protect yourself from embed viewers tracing the iframe back to the instance and seeing extra cards and pages beyond the embedded content. This is done by creating a dedicated instance for external use cases, applying the Whitelabel V1 template of feature switches, and embedding from there instead of your main internal instance.

2. Server-side Programmatic Filters
Documentation: Programmatic Filtering
Definition: Newer SSO integration with cookie-less auth through a single service account for all viewers
Use case: Forced row-level security defined in server side code that cannot be seen nor edited by viewers
Warning: This will shift contracts from user/viewer pricing to impression/view pricing since a single service account acts as proxy for all viewers.
Note: No dedicated external instance is required for this approach since the viewers will not have access to the client ID and secret of the service account. Therefore they cannot trace the iframe and gain access to the Domo instance.

CLIENT-SIDE FILTERS

3. JS API Filters
Documentation: JS Sample Code Repo-JS API Filters
Definition: Client-side approach here contrasts from server-side approach above because these are meant to be visible and editable for viewers. The filters applied via the embed API through event ports and listeners. Changes applied to multiple pieces of embedded content without forcing iframe refresh. Also supports bi-directional context passing (where click events on the embedded content can also be passed back to the home page for cross-iframe or cross-page drills, links, and interactions.)
Use case: Newer approach to applying external filter controls from the host page (like drop down menus outside of the iframe)
Warning: Pfilters and the JS API are not a secure replacement for Programmatic Filters because the client-side parameters can be seen and changed by viewers by either glancing at the URL or inspecting the content. These should only be used for filters that aid exploration.

4. Pfilter URL parameters
Documentation: Using Pfilters to Apply Filters from URL Query Parameters to Embedded Dashboards
Definition: Simpler setup in URL params instead of client side code like JS API filters. However, pfilters are slightly slower because they force an iframe refresh to apply the filter logic. They use the same filter pattern (column, operand, value) as client-side JS API and server-side Programmatic Filters.
Use Case: Older approach to applying external filter controls.
Warning: Pfilters and the JS API are not a secure replacement for Programmatic Filters because the client-side parameters can be seen and changed by viewers by either glancing at the URL or inspecting the content. These should only be used for filters that aid exploration.

INTERFACE FILTERS

5. Page filters
Documentation: Applying Page-Level Filters (with_Filter_Views)
Definition: Top filter bar of embedded cards and dashboards similar to what is available in the full Domo instance
Use Case: Ad hoc filter creation by the user when the creator does not know all the slices the viewer might want to explore
Warning: Page filters are available in dashboard embed, but saved filter views are still in beta so they are not targeted for support in dashboard embed until later in 2021.
Note: As emphasized in the layer sequence above, these lower priority filters can only return results within the subset of rows made available by PDP or Programmatic Filters

6. Interaction filters across cards
Documentation: Applying Card-to-Card Filters
Definition: Slicer cards similar to the cross-card interactions available in the full Domo instance
Use Case: These are the simplest filter interaction for viewers. They are ideal when the content creator already knows the filters will want
Note: As emphasized in the layer sequence above, these lower priority filters can only return results within the subset of rows made available by PDP or Programmatic Filters