Best Of
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
How can an App Studio month filter dynamically default to and visibly display the latest available m
I have a monthly dashboard in Domo App Studio where I need the reporting month filter to automatically default to the latest month available in the dataset whenever new data arrives.
My dataset already contains a Latest Available Month column derived from the maximum Month. I also created a Beast Mode called Dynamic Default Month Filter, following this general logic:
CASE
WHEN `Month` = `Latest Available Month`
THEN CONCAT(DATE_FORMAT(`Month`, '%b''%y'), ' (Latest Month)')
ELSE DATE_FORMAT(`Month`, '%b''%y')
END
So the values in the drop down filter show like below (with July 2026 as the latest month available in the dataset)
In the default Filter View, I apply:
Dynamic Default Month Filter contains "Latest Month"
This successfully filters the dashboard to the latest available month and automatically advances when a new month is added.
The problem is the filter’s display behavior. When users initially open the dashboard, the visible Month dropdown remains blank and displays Select instead of the resolved value, such as Jul'26 (Latest Month).
If the user manually selects Jul'26 (Latest Month), the numbers remain unchanged because the latest-month condition was already applied in the background. This is potentially confusing, prompting anyone to think why not pre-load the Month filter box with the latest month value filter instead of showing blank.
The desired behavior is for the dashboard to dynamically select the latest available month and show the resolved value, such as Jul'26 (Latest Month) in the Month dropdown when the page loads. It should continue updating automatically as new monthly data becomes available while allowing users to select prior months.
Is there a supported way for an App Studio filter to display the value resolved by a condition-based default Filter View, without requiring a manual monthly update?
Option to disable hover border for cards on dashboards
I believe that a recent'ish update has added a light blue border when users hover over cards on a dashboard. Having the option to disable this behavior would be a great improvement. For some cards, particularly some DDX bricks, the border breaks the sense that the card is an element on the page.
I have an album showing the difference here:
Domo provided Code Engine Package Documentation
Provide documentation on code engine packages that Domo offers and what they do. This would really help increase visibility with utilizing AI (internally, via the MCP server, and externally by viewing a knowledge base article) to build out workflows. This would especially be helpful for non-technical people that want to build out workflows.
Provide Field Definitions for Domo Stats and Domo Governance Reports
There are knowledge base articles listing out which fields are included in each report, but those fields aren't defined anywhere. Some field names can be a bit ambiguous and it would be nice to have definitions of what each field means.
Make Locked Cards and Locked Dashboards Behave Consistently for Sharing Permissions
There’s an inconsistency between how Domo handles locked dashboards vs. locked cards, and it’s creating a lot of unnecessary confusion.
When a dashboard is locked, users who aren’t the owner (and who don’t have “Manage All Cards”) can’t change who it’s shared with, which is exactly what you’d expect.
But when a card is locked, users with Edit Cards (but not Manage All Cards) can still add or remove people from the share list, even though they aren’t the owner. Support confirmed this is “working as designed,” since locking a card only protects the content, not its sharing permissions.
The mismatch feels counterintuitive, and it’s tripping up both my team and our customers. It would be great if locked cards followed the same rules as locked dashboards so sharing behavior is consistent and predictable.
PII Detection
While there is a 3rd party solution in the app store (PII Vault), I think Domo should have automated built in PII governance tools integrated into the toolkit. There could be a UI in the governance toolkit where you tick off various standard PII patterns to look for (SSN, Phone, Birthday etc) or even let you define a custom rule. Domo then scans all datasets looking for those patterns and writes out a log of potential datasets/columns that it thinks might sensitive into a table. Admins could then use this data to go review datasets and apply necessary controls around it.
Facebook Ads connector — upcoming Facebook breakdown change (effective August 6, 2026)
Facebook recently announced a change to how they handle three specific breakdowns in their Ads Insights API, and it affects the Domo Facebook Ads Insights connector. We wanted to give you a heads-up ahead of the effective date.
What's changing
Starting August 6, 2026, Facebook will require these breakdowns to be enabled per Ad Account before their API returns any data for them:
impression_device(and any breakdown combination that includes it)hourly_stats_aggregated_by_audience_time_zonefrequency_value
Until an Ad Account is enabled, Facebook's API — both synchronous and asynchronous — will return no results for these breakdowns. This is a Facebook-side restriction, not a Domo connector issue.
Does this affect you?
If you use the Facebook Ads, Facebook Ads Advanced, or the Facebook Ads Advanced Multi Account connector, and have selected any of these three breakdowns — including via the "apply to all Facebook accounts" option — you'll want to take action before August 6. If you don't use these breakdowns, no action is needed.
What to do
Enable the breakdown for each affected Ad Account in Facebook Ads Manager. This has to be done on the Facebook side, per Ad Account — Domo doesn't have a way to enable it for you.
If you have Ad Accounts you're not sure are enabled, check Ads Manager directly, or reach out to your Facebook account rep.
Questions? Drop them below or reach out to Domo Support.
One-click shortcut for "Edit in Analyzer" in App Studio
Please move "Edit in Analyzer" out of the three-dot overflow sub-menu in App Studio and make it a direct, one-click button embedded in the top-right toolbar when a card is selected.
Clicking through a sub-menu hundreds of times a day just to tweak a visualization or dataset is a massive productivity bottleneck. Pulling this option out into a visible shortcut embedded right in that top-right action menu would save developers endless clicks and significantly speed up the app building workflow.




