How to Start Tableau Reporting from a File or Database Event

A Tableau reporting workflow can start when a file or database condition is met, using an Event-Based Schedule in Advanced Tableau Report Scheduler (ATRS). The important design choice is what that condition means: it should identify work that is ready to report, with a way to distinguish it from work already handled.

Imagine a logistics team waiting for its carrier data. Some mornings the load finishes at 06:40; on others it finishes after 07:00. Sending the performance pack at a fixed time forces a choice between an early report with incomplete figures and a later report that everyone waits for.

A completion signal offers a better starting point when the producing process can provide one. The data team finishes its checks, marks the carrier batch ready, and the reporting workflow follows that identifiable batch.

But a file still sitting in a folder can remain visible long after its pack has arrived. If every observation releases another run, managers receive duplicate reports. The example below follows one batch through loading, approval and completed reporting to show how the trigger can support the business process rather than merely react to a visible file.

Give the batch a stable identity before choosing a condition. In our illustrative design, CARRIER-2026-10-19-A identifies one approved set of carrier data for 19 October. It tells the reporting operator which input the pack belongs to, even if processing takes longer than expected.

The upstream system could maintain that identity in a database record with a business date and state. While the data is still arriving, the state is Loading. After the required checks pass, the data owner changes it to Ready. The reporting condition then has a meaningful fact to observe.

These field names and states are an example agreement between teams, not an ATRS database schema. The producing process must actually maintain them. Calling a column Ready does not establish that every expected carrier has arrived or that its figures have been checked.

A file-based handoff needs the same care. A large file can appear before copying finishes, so its presence alone may release reporting too early. If the producer supports a completion marker or controlled final-file handoff, use that signal to express that the input is available for the agreed job.

Also establish whether ten arriving files mean ten separate requests or one complete batch. For the daily carrier pack, the team may need all ten before managers can compare performance fairly. If partial reporting is useful, the report should explain what is missing; otherwise, release it only when the whole agreed batch is ready.

Set an expected arrival window as well. An event-driven workflow can correctly remain idle when no signal arrives, while operations still needs to know that the daily pack is late.

Create and test the underlying Tableau report or package in ATRS first. Use the intended account, business date, report values and internal test destination. This gives the event a known reporting job to release and makes a later failure easier to locate.

Then configure the Event-Based Schedule with the agreed folder condition or database query. The unattended process needs access to that resource. A query that works while an administrator is logged in does not establish that the scheduled process can observe it overnight.

Where several conditions apply, ANY and ALL express different requirements. If the carrier pack requires both completed input and approval, releasing it when either is present would defeat the agreement. Choose the combination that represents the actual release decision.

Database detection also needs to fit the signal. ATRS distinguishes new-record detection from matching-record detection. A record may already exist while Loading and only become eligible later, so review the detection mode and query together. For a matching-record design, the documented approach includes updating the record so it no longer matches after handling.

Finally, place preparation and reporting in the intended execution order. Upstream approval does not itself refresh a Tableau extract. If the report needs a refresh, include that separate step and establish completion before generating the pack. Review any independent timed run too, because leaving it alongside the event could create a second delivery.

Test the same batch more than once. While CARRIER-2026-10-19-A is Loading, it should not release the approved pack. Once the upstream checks make it Ready, follow the run and inspect the output for the same business date.

After confirmed handling, the agreed process needs to make this batch ineligible for another ordinary run. In the database example, that could mean changing its state to Reported; a file-based design needs an equivalent supported rule, such as moving a processed marker out of the watched location. Neither change happens merely because these labels appear in a design note.

Observe that completed batch again. The intended result is no new pack. Then introduce a genuinely new approved batch and check that it can release new work. Together, these observations distinguish “do this work once” from “never run again.”

Next introduce a controlled reporting failure after the event has been detected. If the batch is marked processed too early, unfinished reporting can disappear from the eligible work. If it remains eligible without controlled recovery, repeated observations can create unwanted copies. Decide when the state changes and how failed work remains visible, then prove that sequence in the supported configuration.

Include an incomplete batch, a corrected batch and a planned restart in the trial. A correction should create an identifiable revision under the agreed rule, while the restart should reveal how existing and new signals are handled. These checks establish the behavior of your implementation; an event condition alone is not a guarantee of exactly one delivery.

Once the sequence works, give both teams a shared explanation of it. The data owner needs to know when to produce the signal, and the reporting owner needs to know which batch the resulting pack represents.

Keep the batch identity in the operating evidence and, where useful, the report context. When a manager asks why a pack is late, the operator can then determine whether that batch is still awaiting approval, has entered reporting or has encountered a delivery problem.

Those distinctions also improve the response. A missing approval belongs with the upstream owner; a failed export needs attention in the reporting workflow. “The report failed” gives neither team enough information when the report has not even been released.

Review the event when paths, filenames or upstream states change. A revised completion-file convention can stop the reporting trigger even though the underlying data still arrives. Keeping the reporting owner involved in such changes prevents that small alteration from becoming a missed daily pack.

Retain enough input and run evidence for investigation, using the organization's retention rules. At the same time, ensure that the watched folder or query continues to identify eligible work rather than every historical batch. A short operating note should explain the signal, expected window, repeat rule and recovery contact.

To explore event-driven Tableau refresh, export and delivery with ATRS, begin with one identifiable batch and observe it again after completion. That second observation is what turns a successful trigger into a dependable reporting process.