Tableau Server does not have the built-in ability to halt a subscription based upon exception logic.

I believe there are 3rd party tools out there that could handle this but I don't know which ones exactly, however, someone may chime in with a recommendation.

An alternative is to use VizAlerts.  I don't know how you would implement it as you would need to redo your report to check validity itself.  Also, this is unsupported so in the long run it may not be worth your effort.

In its current form VizAlerts could work, but the report would need to be a single view / dashboard, and the criteria for detecting issues for the data would need to be fairly simple (though the next version, coming very soon, will support multiple dashboards in a single email!)

Detecting issues where the extract(s) did not run properly for the report could be done. But doing that check in addition with actually checking values in the data that you did have would be trickier. And in the end, even though it might work, would it be worth the hassle? Maybe not. One thing you could do is add a sheet to the dashboard that connects to the data source the dashboard uses and shows a KPI indicator of some kind to indicate whether people should question the report or not (green = "ok", red = "this report has issues"). That might be easier than making the entire report conditional.

I've gotten some grey hairs (and probably lost some) over the fact that subscriptions can't be stopped based on other criteria.

A huge part of what attracted me to VizAlerts was the ability to have the following workflow:

- update the extract

- do some data validation

- if the data is good, send out the views

- if the data is bad, *don't* send out the views and notify me

With the new functionality in VizAlerts (full disclosure here - Matt wrote the original version of VizAlerts and I wrote a whole bunch of the code for the new version) I'm now able to do this, here's what I've been implementing:

a) Each Tableau data source has a column in the view (generated using GETDATE() or similar function depending on the source) that identifies the last time the view or query was run. I use this because we can evaluate that column in Tableau calculated fields, unlike the Last Updated/Extract Refresh Time that's available to put in worksheet Titles & Captions.

b) A Tableau calculated field is used to indicate whether the datetime from a) is good or not. For example I've got one extract refresh each morning where the data can't be more than an hour old or it's useless. In some cases that calculated field will also include logic for checking total number of new rows for today, etc. This is to handle cases I've run into where the extract refresh works fine but the data hasn't been fully updated for today due to upstream problems.

c) The VizAlerts trigger view (this is an Advanced Alert) is built using a separate data source with the list of alerts to be delivered and a Tableau data blend back to the source from steps a) and b). The good/bad field from b) is used to filter the trigger view. If the data is good then the filter allows the subscribed alerts to be sent out. If the data is bad then the filter removes those from the trigger view and alerts aren't sent out.

d) There's an additional VizAlerts trigger view (or maybe a row in the first view, I'm still working out details) that only lists the Tableau admins (i.e. me and the other guy in the office) that also uses the field from b) but in reverse, so the admins are only alerted when the data is bad. In my case the email address I use will be of the form xxxxxxxxxx@txt.att.net so I get an immediate text notification of the failure.

Toby and/or Matt (I'm forgetting who) have created the SQL logic to identify extract failures, that could be used to create additional alerts and/or feed into the above process to halt views before they are sent out. I'm pretty jazzed about the possibilities with VizAlerts to save me from having to clean up the mess when an upstream process fails to deliver the expected data and views go out with bad data.

Jonathan

Toby and/or Matt (I'm forgetting who) have created the SQL logic to identify extract failures, that could be used to create additional alerts and/or feed into the above process to halt views before they are sent out.

Matt's version:  Example: Email users whose extracts fail to refresh

My version:  Re: Alerts you've created, Alerts that you want

Even better, it's both!

Another, completely different idea which would require some coding /  scripting on your part:

• Create a schedule which never fires: In other words, create the schedule and then turn around and immediately disable it.
• Attach all of your "Should only fire upon successful extract refresh" tasks to this schedule
• Write a little code / script which checks the backgrounder_jobs table of Tableau's metadata store (more info here: Workgroups Database )
• Run a query which returns the results for your extract refresh job,
• Assuming that finish_code = 0 (completed w/o problems), use TabCmd to manually execute the schedule (runschedule) you disabled. In your situation, "disabled" means it won't execute at whatever cadence you set up in the schedule page itself...however, a disabled schedule can always be manually executed via the Tableau portal or TabCmd