Filtering Options

Personalized Data Permissions (PDP)

Documentation: Creating and Deleting PDP Policies

Definition: Outdated 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 instead of PDP 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.

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.

JS API Filters

Documentation: JS API Sample Code Repo

• Outputs: The JS API listens for click events on the embedded content and passes them back up to the host page for cross-system links and interaction analytics.
• Inputs: The JS API also completes the bi-directional passing of context by letting the host page push filters down into the embedded content
• Controls: The code above can be triggered by any external menu in the host page

Here are some examples of external drop-down filter controls we used while building Domo’s COVID-19 Tracker:

 

 

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.

Use case: Newer approach to applying external filter controls from the host page (like drop down menus outside of the iframe). Changes can be applied faster 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.)

Warning: JS API (here) and Pfilters (below) 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.

Note: The main pre-requisite is population of the “Embed Authorized Domains” whitelist. This whitelist drives a CSP (content security policy) which ensures these bi-directional signals are only sent in ports for sites you approve:

 

 

The demo video below shows how the events are displayed with specific references even if multiple iframes are included in the same page:

 

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.

Page filters

(and named filter views)

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.

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