How Do You Send Tableau Reports After Data Refresh, Including Bridge?

Start by asking what “after data refresh” means for North’s stock-close report. If the workbook uses a single extract on a published connection, Tableau can send its native subscription after the eligible scheduled refresh. That avoids guessing a later email time and is a good fit when the reader needs the resulting PNG or PDF snapshot.

Follow the Tableau subscription workflow: open the intended view, save a Custom View if filters are required, then choose Watch > Subscriptions. Select the recipients, current view or workbook and PNG/PDF output. Where eligible, choose When Data Refreshes. Recipients need View and Download Image/PDF permissions, and subscribing others depends on the caller’s role and ownership.

Keep successful data readiness, refresh completion and the finished report connected.

If the frequency is unavailable, inspect the connection model before changing schedules. Tableau’s subscription troubleshooting guidance lists Bridge refreshes, multiple extracts and live connections as reasons the option is unavailable. With mixed connections, an available option can follow the published extract refresh rather than the Bridge refresh, so confirm which update actually triggers it.

For the native North sample, compare the delivered stock-close date and totals with the intended completed extract. A successful extract refresh does not select the business-date filter, and it does not establish that a separate business approval occurred. Keep those requirements visible when deciding whether the native route is sufficient.

Bridge adds a specific boundary. Tableau Bridge connects Tableau Cloud with private-network data and can support live queries or scheduled extract refreshes. It does not turn every completed refresh into a native subscription trigger. Tableau’s Bridge alert guidance explicitly excludes refresh-initiated subscription emails for Bridge extract sources.

For the Bridge version of North’s close, distinguish the warehouse load from the Tableau extract update. A warehouse completion record written before Bridge has finished is too early to release the PDF. Have the responsible data process or integration establish successful completion of the correct extract and its intended business period before producing the reporting-ready signal.

A later timed subscription may be adequate where a business accepts the risk and monitors refresh completion. It remains a time-based choice. If the requirement is “never send the previous close as today’s report,” a fixed delay by itself is insufficient. Keep a missing or failed readiness check visible to its owner rather than classifying it as a valid empty report.

Configure one North report and a restricted test destination first. Use the linked Tableau account, correct Item Path, PDF output and the approved 18 October 2026 business-date input for the controlled sample. The account needs the appropriate Tableau access, export permissions and licensing; the ATRS service identity needs access to the readiness source and destination.

Create an Event-Based Schedule using a supported database or file condition and select the existing report schedule as its action. If both warehouse completion and extract readiness are required, design the condition so both are established. ANY and ALL combinations have different meanings; use ALL when every selected condition must hold. If the event is intended to be the only automatic trigger, disable the report’s independent timed run so it cannot bypass readiness.

The ATRS refresh task targets a selected Tableau extract. Its completion wait is distinct from an elapsed pause or a Bridge completion signal.

When ATRS should request a supported Tableau extract refresh as part of the job, the General Custom Tasks guide documents Refresh Tableau Datasource. Select Workbooks or Datasources, the Tableau account and Item Path, and enable Wait for refresh completion up to with a suitable limit in seconds. Configure Custom Tasks → Schedules in the event’s Execution Flow so the refresh comes before report production. Check the installed version against the ATRS extract-refresh release notes before setting up this task.

For North’s Bridge case, keep Bridge responsible for its configured refresh path. Have the data owner verify completion and publish the reporting-ready signal, then use that signal to release the report. Configure an additional ATRS refresh task only if it is required and supported for that source. Agree the handoff with the data owner and test that exact path.

Run a new controlled load, open the resulting PDF and compare its date and stock totals with the completed source. Also test absent readiness, failed refresh and a refresh that exceeds the wait. A wait limit alone does not establish that downstream delivery stops; verify the required failure behavior in the installed version before enabling recurrence. The ATRS Tableau refresh, export and delivery workflow brings these configuration and exception checks together.

A developer can make the handoff explicit without assuming that “refresh requested” means “report ready.” For example, an organization-owned integration can write a reporting-readiness record only after it has verified the correct North warehouse load and Tableau extract completion. This is an illustrative database design, not a built-in Tableau or ATRS table:

SELECT LoadId, SourceKey, BusinessDate
FROM ReportReadiness
WHERE SourceKey = 'NorthStockExtract'
  AND BusinessDate = '2026-10-18'
  AND WarehouseLoadSucceeded = 1
  AND TableauExtractSucceeded = 1
  AND Processed = 0;

The source key, unique LoadId and business date identify what the report may consume. The integration owns how it verifies the success fields; setting a flag when a refresh is merely submitted would defeat this design. If Bridge is involved, the owner must establish actual completion through the supported monitoring or integration path for that deployment. Keep the evidence behind the readiness decision.

Use the fixed source and date only for the controlled sample. Before recurrence, define the advancing-period rule and make the report’s actual inputs match it. Merely returning BusinessDate in a condition query does not automatically bind the report to that date. Retain the load ID with the intended schedule, period and resulting file so a later operator can trace the handoff.

The Event-Based Schedule documentation distinguishes Detect New Records Only from Any Matching Records. Configure new-record detection before creating the test record. For a matching-record query such as this one, define how successfully processed work stops matching and how failed or uncertain delivery is recovered. Marking Processed too early can lose work; leaving it eligible after a successful send can repeat it.

Test a duplicate signal and recovery after a partial run. Reconcile the report history and destination before resubmitting uncertain work. If your application owns the complete export-and-send sequence instead, keep the same source, period, success and recovery checks there. The useful guarantee comes from verified behavior across the stages, not from an API accepting a refresh request.

Use the native post-refresh subscription for an eligible single-extract snapshot. For Bridge, multiple dependencies or an external approval, document the actual completion evidence before choosing how report delivery starts. Inspect both the normal result and the delayed or failed path.

Evaluate the ATRS Tableau report scheduler when the job needs a maintained readiness condition, refresh sequence and configured report delivery. Bring one data source, its completion evidence and the intended file. Confirm the behavior for your connection type and installed version with that concrete job.

Considering ATRS for reports that must follow completed data? Share the guide with the data owner and operations team to review deployment, access and the full reporting handoff.

Download the ATRS Internal Evaluation Guide