Skip pulse if no results

[maxbeatty]

We have an hourly pulse that really only has results during business hours. Would it be possible to add an option to only post if the result of the question has results?

[agilliland]

How many questions are in the pulse? and what exactly is the result of the questions when there are "no results"?

[maxbeatty]

Currently, one question and its raw SQL to merge 4 columns into 3 so everything displays in Slack

SELECT b.name || ' ' || f.number AS "Thing", q.color, q.amount
FROM foo AS f
JOIN bar b ON b.uuid = f.bar_uuid
JOIN qux q ON q.ref_uuid = f.uuid
WHERE q.created_at > NOW() - INTERVAL '1 hour';

If nothing was created in the last hour, there are no results for the query which makes the pulse more noise than signal. By having an option to skip those empty queries, our Slack channel stays full of the most useful info.

[agilliland]

Got it, so in these cases there are 0 rows of actual data. So you're currently just getting hour after hour of pulses that look like this?

What about the possibility of picking the specific hours of the day you want the pulse to actually be sent? So if it's only really meaningful during business hours then set it up for 9am-5pm daily.

[salsakran]

Hmm .... it's possible that something of this nature could effectively create alerts ala #1373

[salsakran]

Hmm. Open questions in my mind:

• Is this per-pulse or per card?
• If per-pulse, do we still render empty cards?
• if per-card, do we send a pulse at all of the overall pulse is empty?
• Do we do both?
• How much does this muddy the otherwise relatively simple interface?

[maxbeatty]

@agilliland exactly 😸 I could see a schedule being useful but our hours are not set in stone which is why I started down the "is empty" path

@salsakran yep very similar to what #1373 is after. My two cents on your open questions: start with per-pulse and a single checkbox to effectively skip a beat if nothing to report. If there's more demand for more granular control (per card), cross that bridge then.

[Sumukh]

We have a similiar use case (but our hours are a bit more set in stone).

Our current pulse wouldn't qualify as completely empty (but if that's the solution that you want to implement we probably could refactor our queries to make that work)

Here's what would solve our use case:

• Something that allows to avoid sending the pulse if a specific card doesn't have data
• Fixed Times to allow sending pulses. (for example: Between 9am and 7pm)

[salsakran]

@Sumukh can you provide a little more context as to what you're trying to do with a pulse? It doesn't sound like a good fit for the notion of a "light weight way to keep tabs on metrics" (which is our working model for pusles).

[Sumukh]

Sure - we're providing metrics for office hours and pinging instructors hourly so they can see what the current state is. The pulse was to have this hourly, but it's not useful at 2am.

The pulse looks like:

• How many students are waiting for help
• how long have they been waiting?
• Historical wait times (over the last few days)

I suppose I could setup ~8 daily pulses that trigger at the right time. It seems like every other frequency has some specification. (Daily -> Time, Weekly -> Day of Week & Time, Monthly, Day & Time) - but hourly does not. Here's a low fidelity mock of what it could look like:

It's entirely possible this isn't a good fit for pulses. Ideally I'd like to use metabase for this (if not through pulses, then through via webhooks (#2298) or an API?)

[fimpfimp]

"Skip if empty" would be very useful for us too.

[fimpfimp]

@agilliland @salsakran
This is getting to be a high priority for us. If we built this "Skip if empty" feature into Metabase would you consider including it in your main branch?

[mazameli]

Seems to me like if we did this at the Pulse level, it wouldn't complicate the interface too much. I would think we'd want the toggle to be outside of the delivery mechanism sections — i.e., if you turn the skip option on, it would skip both email and Slack if you have both email and Slack turned on. I think the label could read, "Don't send if there aren't any results". We have an on/off toggle UI component that would be appropriate for this rather than a checkbox, too.

@kdoh / @salsakran — any thoughts?

[kdoh]

@mazameli Sounds reasonable to me. I'm definitely in agreement that we don't want to go down the road of per delivery channel settings.

[salsakran]

My questions/concerns from above remain

Is this per-pulse or per card?
If per-pulse, do we still render empty cards?
if per-card, do we send a pulse at all of the overall pulse is empty?
Do we do both?

@fimpfimp we'd definitely take a PR on this, but I'd like to talk out the above and make sure we're all on the same page (specifically re: UX elements) before you do a ton of work.

[mazameli]

My naïve assumption on those questions that you'd raised, Sameer, were:

• this is per-pulse
• if the toggle is on, we only send the pulse if there is at least one card with results
• we do render any empty cards in a pulse that gets sent

This seemed like the approach that involved the least amount of added knobs, and addressed what I understood as being the main thing users wanted to avoid: receiving a totally empty pulse.

[fimpfimp]

All the options discussed can work for our use case. So I think you at Metabase can decide what fits best with your vision. @mazameli 's assumptions make sense to me.

[salsakran]

Works for me.

[fimpfimp]

@mazameli
Is this the on-off component you would like to use for this?

Which section should this be placed in?

We have "Name your pulse", "Pick your data", "Where should this data go?", and "Danger zone".
I suggest having this in the "Where should this data go?" section: Below the channels toggle and above the "Danger zone" headline.

[fimpfimp]

@salsakran @mazameli @kdoh
So, turns out none in our team has experience with Clojure.

Could you produce a quotation from Metabase team for how much you would charge to build this feature for one of your releases in the immediate future?

[mfpinhal]

This is close to be finished in #4184, +1 to add this to next milestone.

[attekei]

Solved in #4690, will very likely be included in the next release