How to Let an Application Request a Tableau Report Package

An application can request an existing Tableau report package through the Advanced Tableau Report Scheduler (ATRS) API and track the resulting run. The application handles the user's request, while ATRS prepares and delivers the reports according to the saved package.

Imagine an adviser finishing a quarterly account review in an internal portal. The customer needs two follow-up documents: a service summary and a list of open actions. Asking the adviser to download both Tableau views and assemble an email interrupts a conversation that is otherwise complete.

A Request Account Pack button can keep that follow-up in the same workflow. The adviser sees the account, quarter and approved destination, submits the request, and can return later to find out what happened.

The button needs more than a successful submission response. If one report fails, or the adviser closes the page while preparation continues, the portal should still connect the original request to an understandable outcome. This example follows one fixed demonstration package from the account review to the delivered files before introducing more variable requests.

Begin with a package configured for one approved demonstration account and quarter, with an internal destination. Run it in ATRS and inspect both reports before connecting the portal. That gives the developer a known result to request and the reporting owner a reference for what the button should produce.

Check that the service summary and open actions tell the same account story. They should use the intended scope and quarter, with a clear explanation if one shows the closed quarter while the other shows actions still open today. A package can contain two valid reports that are confusing together.

The portal also needs to authorize the business request. A signed-in adviser is not automatically entitled to every account or destination. Offer only the approved choices for that person, rather than exposing arbitrary package identifiers or recipient fields.

Keep three references distinct in the application's record. Its own request reference identifies the adviser's action; the ATRS package ID identifies the saved reporting configuration; the returned ExecutionId identifies one run. This lets an operator find the right work when the adviser asks, “Where is my quarterly pack?”

When expanding beyond the fixed demonstration, verify how account and quarter values will reach the reports. Supported separate configurations or an appropriate data-driven design may suit the requirement. Do not assume the execution call accepts business fields that its contract does not expose.

If two users can change one shared configuration, prevent their requests from overwriting each other's values. Separate supported configurations or a controlled queue can keep each account's preparation and execution together. The practical requirement is simple: one adviser's request must not change the customer represented in another's files.

Connect the portal's backend to the API service on your ATRS installation, using its approved address and authentication. The documentation website describes the API; it is not the server that runs your reports. Keep credentials in the backend rather than exposing them in the user's browser.

Retrieve the approved package's identifier and confirm that it identifies the package itself, rather than one report inside it. For an on-demand asynchronous execution, the documented operation is POST /api/Schedule/ExecuteScheduleAsync.

The following illustrative body selects package 201. Replace that placeholder with the real approved package ID; the account, quarter and destination are already configured in this first demonstration.

{
  "ScheduleType": "package",
  "UniqueId": 201,
  "RunBy": "Account Portal"
}

On acceptance, retain the returned ExecutionId against the portal's request record. The adviser can now see that preparation has started and return to that same record after leaving the page. Acceptance means the work has been queued, rather than that both files have reached their destination.

Choose the on-demand operation deliberately. The separate scheduled-time execution path advances the next scheduled run, so it is not interchangeable when the adviser simply wants an additional pack now. Confirm the recurring schedule's intended behavior independently of this button.

Use the retained execution reference to monitor the same run with GET /api/Schedule/GetExecutionStatus?ExecutionId=RETURNED_EXECUTION_ID, replacing the placeholder with the actual returned value. Check at a controlled interval and give the portal a defined waiting deadline.

Interpret the result as well as the status. A Completed status can contain a failed ResultJson, so the application must inspect the reported outcome and error details. Verify the intended output and delivery before telling the adviser that the account pack is complete.

Translate that evidence into useful language. “Preparing account pack” describes accepted work still in progress. “Request needs review” is more honest than “Delivered” when the result is failed or uncertain. Keep the fuller technical details behind the request reference for the operator.

If the adviser closes the page or a status check times out, resume monitoring the known execution when they return. The browser's wait ending does not establish that the backend work stopped. Repeated clicks can return to the active request according to the portal's own duplicate-handling rule.

A lost submission response is more difficult because the application may not have received an ExecutionId. Retain the package, account and submission time, then reconcile the original activity before resubmitting. The API contract does not provide an idempotency-key guarantee, so another call could create another delivery.

Cancellation also cannot promise to recall an email or file already delivered. If only one report or destination failed, show the request as needing attention and give the operator the original execution and missing scope. That preserves the account context while they decide how to complete the follow-up.

Test the whole interaction at the internal destination. Request the demonstration pack, follow its progress and open both received files. Compare their account, quarter and contents with the approved sample, rather than stopping when the application receives a successful HTTP response.

Then exercise the moments that could confuse an adviser. Click again while a request is active, leave the page and return, and interrupt a status check. The user should still find the same known work and understand whether any further action is needed.

Once the fixed package works, test the supported design for varying accounts with two contrasting examples. Request them close together and inspect the actual files for each. A correct account label on the portal screen does not prove that shared reporting values remained separate during execution.

Introduce a controlled export or destination failure too. The portal should report what is known, and the operator should be able to trace the incomplete part without blindly repeating the whole pack. Include the uncertain-submission case in the recovery procedure so a temporary connection problem does not automatically send another customer email.

Finally, ask an adviser to use the feature during a realistic review. They should recognize the pack, know where it will go and find its outcome later. Keep an approved sample and ownership notes for both the application and reporting configuration, since either can change independently.

Explore the ATRS Tableau report automation API with one approved pack and the follow-up your user is trying to finish. The useful result is a customer document request that stays understandable from the first click to the final delivery.