How Do You Trigger Tableau Report Delivery When a File Arrives or Data Changes?

Imagine your service coordinator waiting for the final activity file before preparing a customer’s report. Some days the batch is approved before eight. On a busy day, the timed export runs first and the coordinator has to replace it.

The meaningful event is the approved batch becoming available. ATRS Event-Based Schedules can watch configured conditions and run an existing schedule or custom task when those conditions are met.

That lets the service team connect its real handoff with the Tableau Cloud report. The aim is a useful customer file following the approved work, rather than another attempt to guess a convenient time.

Conceptual illustration: A reporting handoff connected with the data and work it depends on.

A regular timer is enough when the activity data reliably finishes beforehand. Tableau’s native refresh-triggered subscription may also fit a suitable snapshot that simply needs to follow its supported extract refresh.

The customer’s approval is a different business event. A database record can identify the approved batch and its reporting period; a completion file can provide the signal when the producing process finishes writing it.

Agree that meaning with the application owner. A file existing does not necessarily mean it is complete, and an approval record does not by itself refresh the Tableau extract. Include the required data preparation before the report is produced.

Prepare the customer’s activity report first, with the correct batch-period inputs and a test destination. Verify that it produces the file the service coordinator expects before connecting it to the event.

Create the Event-Based Schedule and add the agreed file or database condition. Select the existing reporting job and put any required custom tasks before it in the execution flow. Keep a separate timer from getting ahead of that preparation.

Create one controlled approval and follow its report to the destination. Open the delivered file with the coordinator and find an activity record from that batch. Then leave the condition in place for another check to confirm that the handled event does not create an unwanted second delivery.

Try the missing or failed preparation as well. Once the team knows who hears about a delay and how the event is recovered, put the workflow into the normal approval routine.

Configure the event conditions around the business handoff, then choose the reporting work they should start.

Your service application may already know when the batch is approved and the required reporting data is ready. It can request the saved reporting job at that point instead of asking ATRS to watch a separate signal.

Keep that ownership clear: the application confirms readiness, and the chosen ATRS job supplies the tested report preparation and delivery.

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

{
  "ScheduleType": "report",
  "UniqueId": 101,
  "RunBy": "Approved activity batch"
}

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

The service coordinator can follow the approved batch into its customer report without watching another clock. When approval is late, the reporting routine follows that work instead of sending an early version.

Begin with one real completion signal and the file the customer needs. Use that pair to explore an ATRS event-based handoff.

Explore ATRS event-to-delivery workflows