TABLEAU QUESTIONS

Why Did My Tableau Subscription Email Fail or Not Arrive?

Everyone else has Monday’s sales update, but your manager’s inbox is empty. Sending another copy feels quicker than finding out what happened, until several versions begin arriving.

Advanced Tableau Report Scheduler (ATRS) can keep its Tableau Cloud report generation and destination results together, helping you recover the delivery the reader actually needs.

THE DIRECT ANSWER Locate the missing step before sending again
REQUIREMENTS AND LIMITATIONS Match the evidence to the right correction
END-USER WORKFLOWS Inspect and recover an ATRS report delivery
DEVELOPER AND API WORKFLOWS Track an ATRS delivery request through its actual result
CHOOSE YOUR NEXT STEP Confirm the received report and next scheduled run

THE DIRECT ANSWER Locate the missing step before sending again

Your manager asks where the weekly sales report has gone. A colleague received it, the meeting is approaching, and the first instinct is to press send again.

Pause long enough to find the expected occurrence. The reporting owner can see whether it was due, queued, suppressed because the view was empty or unable to render. The mail administrator can follow the same message if it reached the sending stage.

That avoids treating every quiet inbox as the same failure. A waiting job needs a different response from a missing attachment or a message held by the receiving system.

Native Tableau administration may provide everything needed to repair that subscription. When ATRS produces the report, investigate its own job and destinations so the recovery follows the delivery the manager was expecting.

Native subscription jobs, suppression and mail evidence

Check the expected recurrence and time zone, recipient membership, saved view and empty-view mode. An intentionally suppressed empty result is different from an unsuccessful job.

The Tableau Cloud Jobs page and Task Details provide queue, run, failure, delay or cancellation evidence. A pending job may still run, so establish its state before requesting another copy.

Retain the recipient, subject and occurrence time for the mail administrator. A sending-service acceptance response is separate from receipt in the intended mailbox; investigate the receiving route when appropriate.

Further guidance: Tableau’s background-job guidance

Use the manager’s address, report and occurrence time to keep the investigation specific. A colleague’s successful copy helps compare the same weekly update.

If the source failed, repair the report preparation. If the sending route rejected the email, use that error with the mail administrator. If it was accepted, continue with the receiving system rather than create another report immediately.

ATRS adds useful detail when the recurring job has several outputs and destinations. A saved archive may have succeeded while email failed; the reporting owner can use that information to choose the recovery.

The aim is to give the manager the intended report without repeating deliveries that already worked for other readers.

Native troubleshooting and delivery requirements

Stale or missing embedded credentials and temporary source unavailability can prevent rendering. On Tableau Server, complex views can also encounter the configured rendering timeout; investigate the recorded error before changing a wider setting.

Tableau Cloud documents five consecutive failures as the default subscription suspension threshold. Repair the cause before resuming. Resumption resets the failure count and returns the subscription to its scheduled evaluation; it does not promise an immediate email.

For Cloud mail delivery, use Tableau’s current sending-domain and IP requirements for the actual standard or custom-SMTP route. Avoid applying an outdated allowlist.

Further guidance: Server subscription troubleshooting · Cloud suspension and resume guidance · Tableau’s current delivery requirements

In ATRS, find the sales run under System Monitor → History View and expand its reports and destinations. A Partial Success is a reason to look inside the job, not assume the whole delivery failed.

Follow the failed handoff. For email, inspect the selected account and destination; for a failed report, begin with its source and output.

If the correct original file was retained, use the agreed recovery route for that copy. If it must be regenerated, keep the original reporting period so the replacement still answers Monday’s question.

Open the received recovery file with the manager and leave a record of what was resent. Then confirm the normal recurrence so the repair helps next Monday as well as today’s meeting.

Review report generation, each destination and any retained output before choosing what to resend.

ATRS history, retained files and destination recovery

System Monitor → History View records report and destination outcomes. Expand a Partial Success to see which handoff failed.

The ATRS Email Log records SMTP messages. For Exchange or Office 365, inspect the sending account’s Sent Items as appropriate and use the receiving mail trace separately. Select an authorized configured sender rather than assume a customized display address will be accepted.

Recovering an original output depends on snapshots having been enabled and that file still being retained. Enabling snapshots later cannot recover an output that was never kept. If regeneration is necessary, preserve the intended historical report values.

Review already-successful destinations and uncertain mail outcomes before repeating the whole schedule, so recovery does not resend files unnecessarily.

Further guidance: ATRS History View guide · Email destination guide · ATRS delivery and recovery workflow · Tableau report scheduler

An application requesting the sales report can keep its request reference with the returned ATRS execution identifier. That gives a colleague one reporting run to follow when the manager calls.

Before requesting another copy after an uncertain response, inspect that run and its destinations. The first request may already have delivered the file.

API example: request and follow the saved ATRS report

This example runs an existing ordinary single-report schedule. Replace 101 with its actual UniqueId, use your ATRS HTTPS address and keep the bearer token on a backend that authorizes the report request. Configure and test the report, period, output and destinations first.

POST /api/Schedule/ExecuteScheduleAsync
Authorization: Bearer <ATRS-access-token>
Content-Type: application/json

{"ScheduleType":"report","UniqueId":101,"RunBy":"API"}

GET /api/Schedule/GetExecutionStatus?ExecutionId=<returned-id>
Authorization: Bearer <ATRS-access-token>

Save the returned ExecutionId with the application request, then monitor within a defined limit. Parse the JSON-encoded ResultJson: Completed can contain Result=false. Inspect report and destination evidence before treating the delivery as successful.

The execution uses saved settings and does not supply new recipients or return the report bytes. Its identifier tracks an ATRS run, not a native Tableau subscription or mail-provider message.

After a lost response or uncertain outcome, reconcile the earlier run and destinations before submitting again. The first request may already have produced a delivery.

Further guidance: ATRS Developer Hub

Why Did My Tableau Subscription Email Fail or Not Arrive?

Locate the missing step before sending again

Follow the same Monday update

Match the evidence to the right correction

Give the manager a useful answer

Inspect and recover an ATRS report delivery

Recover the copy the meeting needs

Track an ATRS delivery request through its actual result

Leave the request with its result

Confirm the received report and next scheduled run

Contributors:

Christian Ofori-Boateng

About ChristianSteven Software