How to Let an Application Request a Tableau Report Package

An application can ask ATRS (Advanced Tableau Report Scheduler) to run an existing Tableau report package through its API, then follow that execution to its result. For the reader, this can be a simple Request Account Pack action. The application handles the reporting request while the adviser stays with the account review.

Imagine an adviser finishing a quarterly service review in an internal account portal. The next step is to send the customer a service summary and an open-action report. The portal already knows the account and quarter; asking the adviser to download two Tableau views and assemble an email would interrupt a conversation that is otherwise complete.

Follow one account pack

For this worked example, use a package already configured for one approved demonstration account and quarter. Its two reports and internal test destination are fixed during the first integration test. That keeps the first question manageable: can the application request the known pack, show useful progress and identify the completed delivery?

The example is a design for an application developer working with a reporting owner, not a claim that a customer portal already does this. The reporting owner approves the report contents and recipients. The developer makes that approved request accessible from the account workflow.

Tableau APIs provide operations on Tableau content. ATRS supplies the configured package, output and delivery instructions that this portal asks to run. The portal does not need to rebuild those instructions every time the adviser presses the button.

The first screen can be deliberately modest: account name, quarter, pack name and the approved destination. Showing these before submission helps the adviser recognize the request without exposing arbitrary report identifiers or recipient fields.

Once that complete interaction works, decide how other accounts and quarters will be selected. Those changing business values require a supported report-configuration or data-driven design; they are not additional fields to invent in the execute request.

We will follow this one pack from the button to the returned execution reference and the received files. The useful end is the adviser knowing what happened to the account's follow-up, rather than merely seeing a successful web request.

Before connecting the button, describe the request in terms the adviser and reporting owner recognize. Our example means: prepare the approved account's service summary and open actions for the reviewed quarter, then deliver them to the maintained destination.

The portal's request reference belongs to the application. The package identifier belongs to the saved ATRS package. The execution identifier will belong to one run of it. Keeping those three relationships in the application's record makes a later “where is my pack?” question much easier to answer.

Approve the first pack before varying it

Run the demonstration package in ATRS first and inspect both files. They should use the same account scope and quarter, with a clear relationship between the summary and the actions. The test destination must be internal and recognizable. That is the reporting reference the button will request.

For a closed quarterly review, decide whether the pack uses finalized figures or a current view of that quarter's records. Later corrections could make a newly generated pack differ from the first copy. The report labels should make the agreed interpretation visible.

The portal must also authorize the business choice. A signed-in adviser is not automatically entitled to request every account. Limit the offered packs and destinations to the choices the organization has approved for that person.

Let one request keep its own values

When expanding beyond the fixed demonstration pack, choose how account and quarter values reach the reports. A maintained account-specific configuration or an appropriate data-driven package may fit the requirement. Verify that design against the actual ATRS operations before exposing the choice in the portal.

Two users must not change one shared package's account value at the same time and accidentally receive each other's report. Either give their work separate supported configurations or queue the changes and execution so one request finishes its protected sequence before another changes those values. This is the practical problem behind technical terms such as isolation and serialization.

Repeated clicks need an application rule too. While a known request is active, returning to its progress is usually more useful than starting another copy. A local request reference can help the portal recognize the repeated action; it does not establish an automatic duplicate-prevention guarantee in ATRS.

The developer now connects the portal's backend to the API service on the organization's ATRS installation. The ReadMe documentation describes the operations; it is not the server that will run the customer's reports. Use the installation's approved address, access token and permissions, keeping credentials out of the user's browser.

Retrieve the approved package and retain its package-level identifier. The package includes its Tableau report members and destinations. A report inside it is not the package itself, and the portal should not guess the object from a similar display name.

Submit the approved package

The documented asynchronous operation is POST /api/Schedule/ExecuteScheduleAsync. Its selection uses ScheduleType set to package and the package's numeric UniqueId. This illustrative body uses 201 only as a placeholder for a package that already exists:

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

Replace the example ID with the approved test package's actual ID. The account and quarter are already configured for our first pack; this request does not add invented AccountID or Quarter fields. The caller's access and the portal's business checks must already allow this execution.

An accepted call returns an ExecutionId. Save it against the portal request immediately. The adviser can now see “Preparing account pack” and return to the same request record if they leave the screen.

Choose the on-demand action deliberately

The adviser is requesting an additional pack now. Do not substitute the scheduled-time execution operation merely because its name sounds similar: that path advances the next scheduled run. Check the intended recurring behavior separately from this on-demand request.

The package remains the reporting team's maintained object. The portal is calling it, rather than editing its reports or recipients as an incidental side effect of pressing the button. That separation keeps the initial integration review small enough to understand.

The developer's next task is to follow the returned execution rather than treat submission as the finished customer follow-up.

Use the returned reference with GET /api/Schedule/GetExecutionStatus?ExecutionId=RETURNED_EXECUTION_ID, replacing the placeholder with the actual execution ID. The application checks that same run at a controlled interval and retains the latest outcome.

The status response and its ResultJson need separate interpretation. A Completed status can contain a failed result. Check the reported result and error details, then verify the intended files and delivery before telling the adviser that the pack arrived.

Those are suggested application messages, not ATRS status names. They translate observed evidence into language useful during an account review. A developer can keep the fuller technical result behind the request reference for investigation.

Keep an interrupted wait attached to its request

If the adviser closes the page or a status check times out, the reporting work may still continue. Reopen the same request and resume monitoring its execution ID. A web page's waiting deadline does not cancel the backend run.

A lost submission response needs more care because the application may not yet have the returned ID. Keep the account, submission time and package reference, then reconcile the original activity with ATRS and the delivered output before starting another pack. Do not turn “we do not yet know” into an automatic second email.

Cancellation is also different from recalling a delivery. A file already written or an email already sent may remain after an attempt to stop unfinished work. The portal should describe the actual resulting state, not promise that nothing exists.

Explain a partial pack in business terms

If the service summary is available but the open-action report or a destination failed, show that the request needs review. Give the reporting operator the account, quarter, original execution and unfinished output. Recovery can then focus on what is missing rather than repeat an apparently successful part blindly.

The adviser should be able to find this request in the account history, see the quarter and recognize its current outcome. That history completes the interaction begun by the button: the follow-up remains visible even when preparation is slower than the account conversation.

Test the complete portal interaction with an internal destination. Request the pack, observe its progress, open the resulting files and confirm the intended account and reporting period.

After the fixed demonstration pack works, approve the supported account-varying design with two contrasting accounts. Each should produce its own correct service summary and actions for the intended quarter. Inspect the actual files and authorization choices, not just the account name shown in the portal.

Repeat a click while the first request is still active, then try two authorized account requests close together. The portal should return to known work or create separate approved work according to its design, without one request changing another's report values.

Resume monitoring without resubmission

Interrupt monitoring in a controlled test and resume it using the retained execution identifier. Then test an uncertain submission response with the recovery procedure. These cases establish what the user and operator see when the network is imperfect.

Exercise an export or destination failure. The portal should explain the request's state accurately and give a useful next step. Avoid showing a raw internal stack trace to the adviser or falsely claiming that a report was delivered.

Have an adviser use the feature during a realistic account review. Is the pack type clear? Is the reporting period unambiguous? Can the adviser find the result and understand whether another request is necessary?

Approve the pack with its recipients

Approve the generated pack with the people who receive it, not only the developer calling the API. A service summary and open-action report should tell a coherent account story and use the same period. The integration is complete when that useful pack reaches its intended destination, rather than when a developer has obtained a successful submission response.

Keep the reporting package's ownership separate from application deployment ownership. A workbook change can affect the generated pack without a code change; an application change can affect request values without changing the package. Both sides need an agreed acceptance sample.

Leave a concise operating note covering the approved pack, request contract, identifier mapping, monitoring deadline and recovery contact. This makes the integration maintainable beyond its first developer.

The adviser can now finish the review, request the agreed follow-up and later find the same account pack with an understandable outcome. The reporting owner recognizes its two reports, quarter and destination. ATRS handles the configured execution while the portal makes that work a useful part of the account conversation.

For an application that needs to request and track a configured pack, explore the ATRS Tableau report automation API. Bring one authorized user request, its saved reporting configuration and the outcome the application must show after execution.