Best Of
Magic ETL - Selectable Preview OR EXCLUDE from Preview
The ability to select specific blocks to run as a preview.
Case: In an ETL we have several workstreams and outputs. I want to be able to select a specific area to exclude or include from a preview.
Considerations: Will always need to have the source data to preview, but select a path to only preview.
Period Over Period use as interactive filter only filter to the Date Range set in Analyzer?
I have a Period Over Period Grouped Bar with:
x = Last Day Month
y = Sales
Date Range = This Year
Graph by = Quarter
Compare to: Year Over Year, 1 year ago, 2 year ago, 3 year ago
When clicking a historical quarter such as 2024-Q2 on my Period Over Period Grouped Bar chart, the App filter is resolving to the current year equivalent (2027-Q2) rather than the selected period.
Any other options that I can show same period over the years and users can select any period shows in the card to filter/drill into that relatively easy to implement?
Jupyter Compute Tier management
Currently the Jupyter Compute Tier management is set on an individual user level. Ideally we'd like this to at least be configured on either a role and/or group level to make this as scalable as possible.
Thank you!
Re: Can an "orphaned" output dataset be re-added to a dataflow?
Can you explain more about #3? That sounds interesting.
Re: Clear Filters button while keeping one page filter selected in App Studio
There's currently no "exclude this one filter" option in the Clear Filters interaction itself.
However, instead of setting the button's interaction to Clear Filters, try setting it to Open content → Open page in app, and pick the current page as the destination — leaving Persist filters unchecked. This reloads the page to its default state rather than blanking it out. Since your Month filter's "latest month" behavior comes from a default Filter View (the Beast Mode + Filter View approach from that community post), reloading the page should re-trigger that default, while Region/Country/Language/Search Surface fall back to unfiltered.
Native Support for Snowflake Iceberg Tables
We would like Domo to add native support for Apache Iceberg tables managed through Snowflake across its Snowflake integrations, including Cloud Amplifier / federated connections where applicable.
As organizations increasingly adopt Iceberg as part of their data lakehouse architecture, more datasets are being exposed through Snowflake as Iceberg tables rather than traditional Snowflake-native tables. These tables should be treated as first-class data sources within Domo.
Ideally, Domo should support:
- Discovering and browsing Snowflake Iceberg tables alongside standard Snowflake tables.
- Creating Domo datasets directly from Iceberg tables without requiring workarounds such as views or intermediate tables.
- Using Iceberg tables through Cloud Amplifier / federated connections and pushdown queries.
- Preserving the same filtering, schema discovery, permissions, and query capabilities available for standard Snowflake tables.
Business Value
Supporting Snowflake Iceberg tables would allow organizations adopting open lakehouse architectures to continue using Domo without duplicating data or creating Snowflake-specific copies solely for BI consumption.
This would:
- Reduce unnecessary data movement and storage duplication.
- Allow Domo to work directly with modern Snowflake lakehouse architectures.
- Improve interoperability between Domo, Snowflake, and open table formats.
- Make Cloud Amplifier more valuable for organizations standardizing on Iceberg.
- Future-proof the Snowflake integration as Iceberg adoption continues to grow.
The ideal experience would be for a Domo user to connect to Snowflake and interact with an Iceberg table exactly as they would with any other supported Snowflake table.
Clear Filters button while keeping one page filter selected in App Studio
I have an App Studio page with several dropdown filters: Month, Region, Country, Language, and Search Surface. The Month filter defaults to Latest Month, and I need at least one month to always be selected on this page.
(For additional context, I’m implementing the latest-month default and displaying the latest available month based on the approach described in this community post.)
I also have a button using the Clear Filters interaction. Currently, clicking it clears all page filters, including Month. This causes the cards to aggregate across all months, which is not desirable.
Is there a way to configure the Clear Filters action so that it clears Region, Country, Language, and Search Surface, but leaves the Month filter unchanged or resets it to Latest Month?
I looked at using a persistent filter for Month, but that doesn't work well for this app because other pages contain monthly trend views where I don't want a single Month selection to persist and filter the trend.
Ideally, I need page-level behavior where Month remains selected or resets to Latest Month, while Region, Country, Language, and Search Surface are cleared.
Is this possible in App Studio using Clear Filters or another approach?
Multiple Grand Totals
Right now we are not able to add multiple grand totals in a card. If we were able to do this, reporting in Demo would be much better. In other words I could use Domo instead of Excel for some of the projects I work on if we could enable multiple grand totals on a card.
Re: Help us make PDP better?
To start, I think this forum should be a place for open discussion, not surveys. I'm not going to use the Smartsheet form. Let's talk here.
And when I say "us," I'm referring to the community.
For the past few months, I've mostly stayed silent on the forum. During that time, I've watched the discussions decline and the questions become less frequent, while the forum has increasingly started to feel like a request site rather than a place for conversation. I'd like to see if we can change that.
Whether you're a Domo Coach, a longtime contributor, or hiding behind User_XXXX, I'd genuinely like to hear your voice—not an echo of mine. After this post, I intend to go back to being a mostly silent participant and let the community take the conversation wherever it goes.
With that said, I'll start.
I personally don't use PDP in Domo, even though controlling data access by user is a primary need for our company. When I initially set up our environment, I evaluated PDP and ultimately recommended that we use a different approach for our external users.
Sorry Dan, but I'm probably not the PDP success story you were hoping to hear from.
—
I want to start with something more fundamental than PDP itself.
When a customer tells you that a feature is confusing, difficult to administer, and ultimately something they have chosen not to use, I don't think the right starting point for the product manager is to explain why the implementation is actually good.
That's not a neutral position from which to evaluate the product. It immediately puts us into a discussion where I have to convince you that there is a problem before we can even discuss how to solve it.
If the goal is genuinely to improve Domo, I think the more useful question is:
Why did a customer who has a very obvious need for this feature decide it was easier not to use it?
Our use case could hardly be simpler.
Imagine a company with 100 locations. Employees at Location 17 should see Location 17's data. Someone responsible for Locations 17, 18, and 19 should see those three locations. Someone at the corporate level may need to see everything.
That's not an unusual or complicated permissions problem.
From our perspective, Domo took that very simple business rule and turned it into a much more complicated system of PDP policies, datasets, groups, permissions, exceptions, and administrative rules that we have to understand and maintain.
The problem isn't that PDP can't technically accomplish this.
The problem is that Domo made us think about security in Domo's terms instead of our business's terms.
I shouldn't have to think:
"What PDP policies does this user need on these datasets?"
I should be able to tell Domo:
"John belongs to Location 17."
That's the business rule.
Domo should take care of translating that business rule into the appropriate data restrictions.
If John moves from Location 17 to Location 22, I should change 17 to 22 in one place. I shouldn't have to think about every dataset, dashboard, policy, group, or other place where that change might have consequences.
That's what makes PDP frustrating to us (me). The administrative model doesn't correspond naturally to the way organizations actually work.
And with security, complexity isn't merely an inconvenience.
Complexity creates risk.
If a dashboard is difficult to build, someone gets annoyed.
If a security model is difficult to understand, someone can see data they aren't supposed to see.
So I think the standard for a permissions system should be unusually high. An administrator should be able to answer two questions immediately:
What can this user see?
Why can they see it?
If answering either question requires tracing policies across datasets, groups, roles, and exceptions, then I would argue the permissions system has failed an important usability test, regardless of how technically capable it may be.
That's why I wouldn't begin the conversation by defending PDP. I'd begin by asking why customers with an extremely straightforward need for row-level security can look at PDP and conclude that the safer and easier option is simply not to use it.
To me, that's the product problem worth solving.
Variables Have Been Broken for Months
Adding a new value to an existing variable is not possible. If you add the value, click save and navigate away, it has not actually been saved. If you click save twice, you can actually see the new value disappear.
Is anyone else experiencing this issue? I'm hoping someone has found a workaround.
I reached out to Domo support back in June and they confirmed the bug and are releasing a fix in September, but it has been almost two months and still have another month to go. Meanwhile, there seems to be nothing I can do.
chapman


