DOMO Best Practices You Should Know
Go Big, Do More, With Less. In this article, we share examples show how you might organize an enterprise-level company’s data management with DOMO.
PDP (Personalized Data Permissions)
You can create a customized experience for users and groups in your Domo by setting PDP (Personalized Data Permissions) policies on DataSets. These policies allow you to filter data in DataSets for specified users and groups. Those users and groups then see only the data pertinent to them when viewing KPI and Sumo cards with PDP policies applied.
For example, you might have a card showing a map with data for two regions in the U.S — West and East. You could create two PDP policies — one for the “West” region and one for the “East” region. For the “West” policy you would select those salespeople working in the West region, and for the “East” policy you would select those salespeople working in the East region. If Larry, a salesperson based in Washington, then opened the card, he would see data only for the states in the West region — all states in the East region would appear with no data.
Dataset and Dataflow Name
This makes it easier to find the dataflow or dataset you’re looking for. Domo’s data center has two distinct areas: “Dataflows” and “Datasets,” and you’ll often find yourself switching back and forth between those areas. Trying to remember different names for the same dataflow can often make things more confusing than necessary.
If your dataflow has more than one output, we recommend using dataset names that are similar to the name of the dataflow.
Pick The Right Tool
Domo provides 3 methods for transformation: MySQL and Magic ETL. Before beginning your transformation development, think carefully about which tool will be best for you in the long run.
The latest version of Magic ETL runs very fast. It’s also great for less technical analysts since it’s drag & drop. However, a single SQL command can often take multiple steps within Magic ETL. If your Magic ETL dataflow has more than 30 action boxes, consider switching to SQL.
You’ve picked the right tool, and now it’s time to consider how to structure your dataflow. How can you avoid repeating logic in different places across Domo?
Parallel Consumption
When adding logic into a dataflow, always assume that you’ll want to re-use it for different reasons in the future. Make each dataflow a “micro-process” where it accomplishes a specific result rather than doing everything at once. Split up your logic into multiple dataflows when necessary. This keeps each segment of logic isolated and allows for re-using a set of prepared data, without re-writing the logic.
Don’t Go Overboard with Aggregations
You can aggregate your data to increase run-time speed, but don’t over-aggregate it by removing too many dimensions. It’s better to leave dimensions inside of your dataset even if you don’t need it at the moment. Domo’s dataset capabilities are fast and can pull out specific columns as needed. Leaving extra fields in your dataset will simply save time in the future if you want to expand the slicers & dicers that are available on your dashboard.
Append Instead of Joining
At Search Discovery, we call this the “spine method.” Instead of joining data horizontally (left join, inner join, etc.), stack the datasets on top of each other, using the shared dimensions as the backbone.
This method works best for situations where you’re running a calculation that combines different sets of data. In this example, we want to compare Cost vs Clicks. By having them stacked on top of each other, the Domo charts will be able to calculate it on the fly for each campaign.
Leverage Native Database Methods
You can treat your SQL dataflows as if they were standard database engines. This means you can use the SQL native methods for optimization.
In MySQL, make sure to include indexing. Domo even has the option built-in for you, but you have to “enable” it by selecting which field is the index.
Recursive/Snapshot Magic ETL DataFlow
A “recursive” or “snapshot” DataFlow is a DataFlow that uses itself as an input.
DataFlows (neither SQL nor Magic ETL types) cannot append data natively like connectors. However, if you need to create a DataFlow that appends data, you can do so by running it once and then using the output as part of the input for the next run. This way, every time the DataFlow runs, it includes the data from before and also appends the new data onto itself.
Follow this step to create Recursive/Snapshot Magic ETL DataFlow.
Using Federated Dataset
Domo’s Federated Dataset model allows you to use data from your existing data lakes and data warehouses without duplicating it in Domo, enabling faster implementation and lower maintenance and overhead costs. It looks like a normal Dataset. It displays row counts and the schema, but the actual data is not copied to Domo.
This ensures that your data remains protected in your on-premise environment. Only the subset of data that you query is passed to the Domo cloud, after which it is immediately deleted from memory after being processed.
Domo caches the results of queries when possible to be as efficient as possible. Cache settings are configurable in the Federated adapter.
However, before using this solution, be aware of the following:
Query performance depends on the configuration of the customer’s data warehouse, its performance profile and the query load it experiences. This is managed outside of Domo.
Domo’s Federated Dataset cannot handle any of the following:
- ETL, including Data Science actions (as an alternative, you can create views within the on-premise DataSet.)
- Dataset Alerts (Card Alerts are supported on Snowflake federated DataSets.)
- Data Fusions
- Aggregate window functions within a Beast Mode.
