Hook
If you've ever wanted a Domo landing page that shows different dashboards to different users — without hardcoding anything — domo.env variables in DDX Bricks are the missing piece.
Why It Matters
Without personalization, every user sees the same dashboard list, which means either information overload or a separate page per audience segment. This approach lets you drive visibility from a dataset: add or remove a user's access by editing a row, not a card config. It also decouples the "what content exists" dataset from the "who sees what" dataset, giving you a clean separation that scales to 50+ dashboards without touching the brick's code.
What You'll Learn
- Read the current user's identity at runtime using
domo.env - Query a visibility-control dataset to filter cards per user
- Pull boilerplate card metadata (name, URL, image, copy) from a second dataset
- Compose both queries into a single
main()function that renders a personalized navigation card - Structure DDX Brick JavaScript with a bottom-level
main()entry point for readability
Building a User-Aware Navigation Brick with domo.env
The core pattern here is a two-dataset architecture. One dataset owns the content — dashboard names, URLs, images, and descriptions. A second dataset owns the visibility rules: a simple email | card_id join table you can edit without touching the brick.
At runtime, the brick calls domo.env to get the authenticated user's email, then issues a filtered query against the visibility dataset: SELECT email, cards FROM [dataset] WHERE email = ?. That filtered list drives a second query against the content dataset to hydrate the full card details.
The JavaScript is organized so that main() at the bottom orchestrates three functions in sequence:
getFilteredData(email)— returns the card IDs this user should seegetActualData(cardIds)— fetches name, URL, image, and copy for each- A render function — prints the cards to the DOM
This top-level sequencing pattern is worth adopting broadly: it makes the data flow readable at a glance and keeps each function testable in isolation.
One practical detail: the visibility dataset is the control plane. If a user should stop seeing a dashboard, you remove their row. If a new dashboard goes live, you add it to the content dataset first, then opt users in via the visibility table. No card reconfiguration, no republishing.
The full code sample — including the domo.env call and both dataset queries — is on GitHub.
