All these filter types are layered in the sequence below:
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.
(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