Hook
When you build a Domo landing page, every user sees the same navigation — even links to pages they can't access. A DDX Brick that filters navigation dynamically based on actual user page permissions fixes that in a single component.
Why It Matters
A static landing page that shows restricted links creates a frustrating dead-end experience: users click, get blocked, and lose confidence in the platform. It also forces admins to maintain separate landing pages per role or group, which doesn't scale. A permission-aware navigation component reads the current user's actual page access at runtime and renders only what they can reach — one component, every role, no manual upkeep.
What You'll Learn
- Retrieve the authenticated user's page access list via the DDX Bricks API
- Conditionally render navigation links based on runtime permission data
- Structure a DDX Brick to serve as a role-aware landing page
- Understand how Jace M's template was adapted for dynamic access control
- Wire up the component so it stays current without hardcoded role logic
Building a Permission-Aware Navigation Component in DDX Bricks
The core pattern here is pulling page access data from Domo's platform context at render time. DDX Bricks run inside Domo's iframe environment, which means they have access to the current user's session — including which pages they're permitted to view. The component queries that access list, then builds its navigation links by filtering against it rather than rendering a static list.
The template shared by Jace M (Domo) provides the scaffolding: a DDX Brick that knows how to fetch the user's accessible pages and loop over them to construct the UI. The key decision point is where to do the filtering — client-side in the brick after fetching the full page list is the practical approach, since you're already inside an authenticated session and the data is available without a separate API call.
Noah Finberg's contribution was around the DDX mechanics themselves — specifically how to correctly call async operations inside the brick's lifecycle so the page list is resolved before the component attempts to render. Getting this ordering right matters: if you try to build the nav before the permission data resolves, you get a blank or broken component. The async/await pattern (linked in the description for Python context, but the same principle applies to the JavaScript DDX environment) ensures the data is ready before the DOM is touched.
The resulting component is portable — drop it into any Domo instance, configure the page IDs you want surfaced, and access control is handled automatically. Admins manage permissions in Domo's native access controls, and the landing page reflects those changes without any code updates.
