Can Customers Request Tableau Reports from Our Own Application?

Imagine a customer preparing an account review in your service portal. The order and activity information is there, but getting the monthly report still means sending a message and waiting for an analyst.

Your portal can provide a request action backed by ATRS. The application identifies the customer and the report they are allowed to request; ATRS produces and delivers the saved Tableau Cloud job.

That division keeps the customer’s normal workflow in your application and the report preparation with the reporting team. It also gives support a particular request to follow when the customer asks where the file has gone.

Conceptual illustration: A customer application connected with its reporting workflow.

Embedded interactive Tableau content may meet a different need when the customer must explore a dashboard and has the appropriate access. A static monthly report is a separate deliverable.

For that report, decide which choices the customer should have. An extra copy of an approved period may be enough initially. Broader options such as changing recipients or scheduling dates need validation and ownership in the backend.

ATRS can maintain a single report or a package with its formats and destinations. Start with one approved customer job before exposing a larger catalogue or letting the portal create and edit schedules.

Choose one customer’s working monthly report in ATRS and use a test destination. Open its received file with the account owner and establish the customer selection, period and output the portal action should represent.

Add the request action to your application and resolve it on the backend to that approved ATRS job. Record the customer’s operation before submitting it, then save the returned execution reference with the request.

Show a useful status while the job runs. When the result and your required delivery evidence are available, tell the customer what is ready. A file saved to a server folder is not automatically a customer-download link; the application needs its own authorized file-delivery route if that is the experience it offers.

Try two customers and an uncertain response before releasing the feature. One customer must not be able to inspect another customer’s report or execution. Repeated clicks should not create uncontrolled extra deliveries.

Prepare and verify the report’s supported parameters in ATRS before connecting the portal’s request action.

After authorizing the customer, the backend submits the approved job once and retains its execution reference. The portal can then follow that same request without exposing the reporting token.

The example below runs an existing single-report job. Package creation and customer-specific schedule edits use their own complete documented workflows.

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

{
  "ScheduleType": "report",
  "UniqueId": 101,
  "RunBy": "Customer portal report request"
}

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

The customer can request the monthly service report while preparing the account review, and the analyst can spend time on the questions behind the figures.

Start with one authorized customer job and a received sample. Use that familiar report to build and evaluate the ATRS-backed request in your application.

Explore ATRS customer-portal reporting