Best Of
Re: Errors caused by Timezone, Where can I adjust it?
There are 2 types of timezone settings in Domo.
Anyone can define their personal time zone in Domo to determine when they receive alerts, notifications, and scheduled reports. Admin-level users can define a company time zone for the entire instance to standardize how visualizations display.
If there is a company defined timezone, Domo assumes that all data loaded in is in UTC.
To set the company time zone, you must be an Admin or have a custom role with the following grant enabled:
(Admin-level) Manage All Company Settings — This grant permits the user to manage company metadata, authentication rules, security, publishing, and more.
Go to Admin>Company Settings>Company Overview>Formatting>Time Zone.
Since Domo expects that all input DATETIME values are in UTC, note the following:
- DATETIME values are not converted to UTC during import from self-managed DataSets (such as Excel, Box, Google Sheets, or file upload). Data in these sources must be stored in UTC before import.
Re: Errors caused by Timezone, Where can I adjust it?
When Domo imports data, it's assumed to be within UTC, then when the data is visualized, it's translated to the timezone configured in your instance company settings. You can leverage an ETL with a formula tile and a CONVERT_TZ function to change the timezone of a timestamp if necessary.
Re: Get timestamp from workflow step
Awesome! thanks a lot for your help. This is just the answer that I was looking for.
Re: Drilling from Table Card
Completely agree @MichelleH . I can't tell you the number of times where I've had users click on a value, and the assumed behavior is that they will drill into the records that make up that aggregate value. This would be a nice UX enhancement.
Re: Card Sharing
When you share a dashboard with users, all the cards on that dashboard inherit the sharing settings of the dashboard by default. So, if you shared the dashboard with a group of users, they should have access to view all the cards on that dashboard.
However, when you add a new card to an already shared dashboard, it doesn't automatically inherit the sharing settings of the dashboard. You need to explicitly share the new card with the same users or groups who have access to the dashboard if you want them to see it.
New feature release 05.22.2024
🚨 NEW PRODUCT ENHANCEMENTS 🚨
This release includes new capabilities that improve ease of use, monitoring, alerts, security, and more.
Here are the top five announcements from today's release:
💻 App Studio — Now integrated with Domo Sandbox and with Publish in Domo Everywhere!
⏩ Workflows — Automatically monitor workflow progress updates with notifications, get increased visibility with new sub-setting Task Creator Access, and more!
🔔 Alerts Sending Scheduled Reports — Get timely and relevant insights when they matter most!
📊 DomoStats — Four new reports are here for Roles, Role Grants, Groups, and Group Members (BETA)!
🛡️ Column Masking (BETA) — Simplify sensitive data protection and management!
Learn more here:
Re: Using beast mode to compare strings
@Mark Puddephatt You can use the INSTR function to return the starting position of the email address within field2. If field1 is contained within field2 it will return a number greater than 0.
case when INSTR(field2,field1) > 0 then 'Looks good' else 'Looks bad' end
Re: Using beast mode to compare strings
I'd probably do something like
case when instr(upper(`field2`), upper(`field1`)) > 0 then 'Looks good'
else 'Looks bad'
end
Re: Get timestamp from workflow step
There are lots of ways to do this. The most important thing is just to find a way that works and isn't computationally overloading.
In this case I would absolute recommend a code engine function.
Here video on making that exact function:
And here is the code that I review in the video:
———————————————-
http://const codeengine = require("codeengine");
function getTimeStamp() {
let timeStamp = Date.now();
console.log(timeStamp);
return timeStamp;
}
module.exports = { getTimeStamp };
Division By Zero - Be Aware - Failed IFERROR, IFNULL, and GROUPBY
When you're performing calculations over 100s of millions or records sometimes you come across division by zeros in which you're hoping the software you're using would manage accordingly, I ran into a scenario in an ETL scenario where it lead to having more than a 10% revenue shortfall in my numbers.
Generally in Domo if there is no data or if there is an error it will return a NULL in the output variable; however, if it is a division by zero, several functions fail to work with the output.
Figure 1: Input and Output
- Ratio = Num / Denom
- Ratio IFERROR = IFERROR(Num / Denom, 0 )
- Ratio IFNULL = IFULL( Num/Denom , 0)
- Ratio Backfill IFERROR = IFERROR(IFERROR(Num / Denom, 0 ),0)
In Figure 1 you can see in row 4 that the Ratio of Num and Denom yielded a blank calculation, however, both the IFERROR and IFNULL failed to backfill with the assigned zero.
Compared to Row 6 where the Ratio is also blank, but the IFNULL was able to backfill with zero. Not that a blank / blank for Domo is not necessarily an error, hence it did not meet the criteria for Ratio IF ERROR result of 0.
The real problem came when it was time to Group BY.
Figure 2: GroupBY Node
When I grouped by Products and sum Ratio and Ratio IFERROR, Product Y failed to sum in Figure 2 Row 3 because of the blank in row 4 (Division by Zero) from Figure 1, as opposed to Product Z which also had a blank cell in row 6, but was able to sum as seen in row 1 in Figure 2.
As a workaround, I used a case statement to check the denominator before computing the ratio.
case
when Denom = 0 then 0
else Num / Denom
end
Domo is aware of the issue, but be aware that IFERROR, IFNULL, and GROUP BY fails at managing division by zero errors.
Think about it this way, if Product Y was 1 million records and just 1 of those 1 million records had a division by zero, the sum of all 1 million records would result with a BLANK.
joe