Enable Extract Refresh Scheduling and Failure Notification
Before your publishers can schedule extract refreshes, you must enable scheduling on the server.
While you’re enabling scheduling, you can decide whether also to enable sending email to owners of data sources or workbooks that are refreshed when those extract refreshes do not complete successfully. You can read more about these emails below. When you enable refresh failure notification, the owners of the content that has scheduled refreshes can opt out individually by changing their account settings.
Sign in as a server administrator, and select Settings.
On the General page, do the following:
Under Refresh Failure Notifications, select Send email to data source and workbook owners when scheduled refreshes fail.
To clarify, if a scheduled refresh for a particular data source fails, the email goes only to the owner of that data source, not to owners of workbooks that connect to that data source.
Under Embedded Credentials, select both options to let publishers embed credentials and schedule extract refreshes. (Automatic refresh schedules require embedded credentials so Tableau Server can directly access data.)
Note: On a multi-site server, failure notifications are a site setting, and embedded credentials are a server setting.
Managing schedules from the server
In your organization it might be more appropriate to manage embedded credentials and refresh schedules centrally from the server. If you do that, you might clear the check boxes in the Embedded Credentials section described in the steps above, so that Tableau Desktop publishers do not see schedule options during publishing.
Managing schedules centrally enables you to distribute extract refresh and subscription tasks, so you can run them when most people are offline. It also enables you to oversee which credentials are embedded in connections.
How refresh failure emails work
The email notification for a failed extract refresh lists the extract name and location on the server, gives the time of last successful refresh, the number of consecutive times the refresh has failed, and suggests the reason for the failure and possible solution.
After five consecutive failures, the refresh schedule is suspended until you or the data owner takes an action to address the cause of the failure, such as updating database credentials or a path to the original data file.
How the last successful refresh date is determined
The last successful refresh date and time are shown when that last refresh occurred within a number of days. By default it is 14 days, and this value is set in
wgserver.alerts.observed_days. If the number of days since the last successful refresh exceeds the number specified in this setting, the message in the email shows “not in the last N days.”