Best Of
Re: Pivot Woes - Losing Rows causes total to change
When you pivot in Domo, the pivot expects the incoming dataset to already be defined with the fields you want to pivot on. If you include extra fields, the pivot will collapse those rows and cause things to dissapear.
The "Group By" forces the dataset to the right fields before you pivot. You are aggregating (SUM, COUNT, AVG, etc) all the details. Which produces one row per Dept + Month + Actual/Budget so that the pivot doesn't have to aggregate.
Re: Your First Look at the Domopalooza 2026 Main Stage
Let's go!! Can't wait for my first DP 🙌
Re: Your First Look at the Domopalooza 2026 Main Stage
I will make sure to find you during one of the days, gotta make sure I meet the legendary @Data_Devon in person!
Re: Top N Filter Not Working as Expected in Multi-Series (Grouped) Bar Chart
Ahh.. If you are using the nested bar chart, you can accomplish this without any special fields.
Remove the filtering and sorting and then go to chart properties - general and choose Sort on Totals Descending and Maximum Items 5. These two properties act differently than the Limit Rows and Sorting features and should get you what you want. You can see my screenshots below using the Example Sales Data.
Re: "I Just want the numbers" - Accomodating Domo detractors
To Colemen's point, I'll plug "Dashboards that Deliver" as a good read for this. The first 11 chapters are all about practical steps to define the purpose, profile the users, and prototype with the users involved to make sure the final product really meets their needs.
One thing they push, is before jumping to the technical implementation (Domo dashboard, Google Sheet, static email, etc.) create some sketchy prototypes of what you think the product should look like. (literal sketches, or wireframes, or simple PPT). Show them to the potential users, get feedback, and iterate. You're more likely to get high quality feedback on a low-tech prototype and you'll be more likely to make big changes because the lift to change it is lower.
Re: "I Just want the numbers" - Accomodating Domo detractors
Users can kind of be bucketed into different user types. Sort of like customer profiling, you can think of it like internal customer profiling. Your customer profiles will be somewhat unique to your company. They may look like:
- Tech forward (embrace Domo, want to do more with it, hungry for new features)
- Resisters (prefer the old way. Spreadsheets, powerpoints, etc…)
- Casual participants (view a couple of cards or apps, log in weekly)
I'd recommend going through an exercise to profile your customers and consider how you might approach each profile differently. For example, for the Resisters - which is the group your post is trying to serve, you may need to consider Scheduled Reports using Report Builder. Or using the Powerpoint plugin to create monthly slides. Or using the Google sheets plugin / writeback to update a spreadsheet. Or explore the new Worksheets feature in Domo. I've found that that gets them to dip their toe in and start slowly using Domo features. The hope is that they evolve into a different profile that uses more of Domo, but if they don't, at least they are still benefitting from Domo in some way.
You can't approach each user profile the same way, or you will likely fail. Domo has a lot of content types and different features because the needs of users are all different.
Re: "I Just want the numbers" - Accomodating Domo detractors
Your users’ concerns about Domo being “too complicated” aren’t really a platform issue—it’s a consumption issue. It comes down to how people receive and interact with data. When you’re working with large datasets and shared aggregations, spreadsheets just aren’t the right long-term tool, even if they feel familiar.
Domo’s real value is accuracy, security, and automation. It doesn’t have to mean dashboards and cards for every audience. For some users, the best interface can simply be an email or a spreadsheet-style output generated from governed data. I’d look at using a workflow to deliver those emails directly, assuming there’s no PII or sensitive personal data in the results.
Re: OData Connector - account creds and "data tag" question
Yes, you would be entering the username and password of your OData account. Domo will use this information to access the endpoint.
As for the data tag, I would try leaving it blank since it isn't required and then refine it if you can see that information in the data once it is pulled into to know how to better refine your connector. It appears that OData uses tags to refine your request:
OData uses specific "tags" or annotations within its metadata and data payloads to convey additional information or control behavior. These are typically prefixed with @odata . in JSON payloads or represented as attributes in the OData metadata namespace within XML CSDL.
Re: App Studio share a specific page with a person or user not the entire app
I periodically check back to see if this idea has any movement. App Studio provides plenty of benefits beyond the normal dashboards but the inability to permission access to certain pages within an app is a significant drawback to making a widespread organizational change towards Apps. As mentioned by users before on other threads this leads to duplicate Apps and clutter. Ideally, we want to use Apps to optimize organization with the pages and tabs options available within App Studio.
Do we have any kind of update on implementing this ?






