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.
Re: United States Map drill odwn
This sounds like a bug with the platform. I'd recommend logging a ticket with Domo Support outlining your issue for the development team to look into.
Re: Table Colors: the most asked about feature since 2018 (and I can prove it)
This isn't just about cell colors—it's also about borders, especially border thickness and styling. These are fundamental features that have existed for decades.
It's hard to reconcile all the excitement around AI and modern analytics platforms when basic table formatting still falls short. Excel, HTML/CSS, Microsoft Word, Google Sheets, LibreOffice Calc, and virtually every reporting tool allow users to apply cell background colors, border colors, and varying border thicknesses. These aren't advanced capabilities—they're standard expectations for presenting data clearly and professionally.
Rich table formatting isn't a luxury; it's an essential part of communicating information effectively. It's surprising that such a mature BI platform still doesn't offer the level of control that's commonplace in everyday productivity software.
Domo Quarterly Newsletter: July 2026
Hi Everyone! Just sharing the news about the drop of the new Domo Customer Newsletter you can find on the Domo.com blog:
Domo Quarterly Customer Newsletter: July 2026
Wanted to throw the link in here so everyone can go take a look at a recap of the latest Domo events product releases, a customer spotlight, and more.
Re: Fix the buggiest card type in Domo: The Text Card
@ColemenWilson have you heard from Product on this in a while? You are so right (still), this card type is rough. It could be so much better!
Re: Filter Selection not working
I'd recommend logging a ticket with Domo Support as this sounds like a bug within Domo and they'd be the best resource to help with the issue.
Is the SQL Tile in Magic Broken?
I have seen multiple ETLs with SQL Tiles fail inexplicably with no changes to the ETL or underlying data. These ETLs have been running successfully for weeks or months. Is anyone else seeing this?
I first noticed this yesterday (6/15) around 3:40pm eastern
I have submitted a ticket, but I need to escalate here as this is base level functionality.
Re: April Community Forum Recap
He says he was hiding because he didn't want to surpass someone else on the all-time scoring list. ;)
Card Limitations
It has been 49 business days since @DavidChurchman posted what I consider the most significant forum discussion of 2026. And since then, I don't think a day has gone by where I don't realize I am limited by Domo cards.
The chart below is a mock-up. The numbers in the image are fake.
Challenge - can you replicate this with Domo cards - no blank bricks, no AI, as shown?
- Gauges are half circle, start at zero.
- Each gauge has a currency amount and a percent beneath it.
- Every slice (in the pie charts) show a label - even small slices
- Each pie chart has a total at the bottom and a legend on the side.
- Table chart has a horizontal bar on last column.
- Simply line chart with node (dot) at each reference point
Sample data would be something like
Fiscal Year | Category | Measure Type | Amount |
|---|---|---|---|
FY2025 | CAT1 | Budget | 35000000 |
FY2025 | CAT2 | Budget | 28000000 |
FY2025 | CAT3 | Budget | 24000000 |
FY2025 | CAT4 | Budget | 18000000 |
FY2025 | CAT5 | Budget | 15000000 |
FY2025 | CAT6 | Budget | 5000000 |
FY2025 | CAT1 | Actual | 12000000 |
FY2025 | CAT2 | Actual | 8000000 |
FY2025 | CAT3 | Actual | 24000000 |
FY2025 | CAT4 | Actual | 15000000 |
FY2025 | CAT5 | Actual | 3500000 |
FY2025 | CAT6 | Actual | 2300000 |
FY2025 | CAT1 | Remaining | 23000000 |
FY2025 | CAT2 | Remaining | 20000000 |
FY2025 | CAT3 | Remaining | 0 |
FY2025 | CAT4 | Remaining | 3000000 |
FY2025 | CAT5 | Remaining | 11500000 |
FY2025 | CAT6 | Remaining | 2700000 |




