Build a Scheduling Portal Integration

Add Tableau report scheduling to your portal while your backend controls credentials, approved reports, recipients and access to each schedule.

Start with one workflow: an authorized user runs a working schedule, or creates a schedule from a working template for an approved Tableau view and PDF destination. Add other workflows after verifying their full configuration and output.

Architecture

Keep ATRS client secrets and tokens on the backend. Expose defined application actions rather than a generic proxy for arbitrary ATRS routes and request bodies.

Before you begin

• Configure ATRS and a backend API client using installation and authentication.
• Choose an approved working schedule/template and test destination.
• Define which users can view, edit and execute each portal schedule.
• Decide which recipients, output settings and report scopes users may choose.

1. Define the user’s choices

For the initial PDF workflow, expose a small form: approved report, permitted recipient/destination, intended recurrence and allowed parameter choices.

Validate those choices on the backend. Apply mandatory customer data scope independently of editable parameters. Never accept an arbitrary account ID, report URL, server path or recipient merely because it arrived from the frontend.

2. Authenticate the backend

Use POST /api/OAuth2/token with the configured client credentials. Follow Authentication and Token Management, cache the token and coordinate renewal using expires_in.

Portal user authentication remains separate. A shared ATRS client does not identify the individual portal actor; keep that actor in your application’s audit record.

3. Maintain ownership

Store a mapping such as:

Authorize every read, edit, execution, deletion and status request against that mapping. Knowing a schedule or execution ID does not grant access. Names, folders, keywords and RunBy are not authorization rules.

4. Discover approved Tableau content

Follow Discover Folders and Tableau Resources for account → project → workbook → view selection.

Filter the results to each user’s approved catalogue before returning them. Expose portal catalogue IDs and display names; resolve them to server-maintained ATRS account and resource values on the backend.

For template-based creation, maintain a mapping from the approved catalogue entry to a working ATRS template. Discovery alone does not provide every authoring setting.

5. Create and inspect the schedule

Use Create a Schedule from a Working Template as the complete request workflow. The backend substitutes validated name, folder, recurrence and destination choices while preserving the approved template’s resource, parameter types and rendering settings.

Create with recurring delivery disabled. Retain the returned UniqueId and complete intended definition, retrieve the saved schedule and verify it before marking portal setup complete.

The example’s schedule time is local ATRS schedule time. If users choose another timezone, define conversion and daylight-saving behavior in your application.

For package creation, submit the approved reports, recurrence and destinations using Create and Manage Report Packages. Use Create a Data-Driven Tableau Package when input records supply each report’s parameter values. Store the returned package ID and intended definition in the same ownership mapping.

6. Manage edits and pause/resume

For full edits, combine permitted changes with the retained intended definition. Preserve all required settings and destination IDs, submit SingleSchedule/Update, then retrieve saved state independently.

Serialize competing edits or use application-level version checks. Account for changes made directly in ATRS so a portal write does not silently overwrite them.

Use the complete enable/disable workflow for pause and resume. Show recurring enabled state separately from execution state; disabling recurrence does not cancel a running report.

7. Run and monitor a schedule

After authorizing the action, create a durable application operation record and use the Quick Start request sequence:

1. Resolve the portal schedule to its ATRS installation, family and ID.
2. Submit ExecuteScheduleAsync once.
3. Store the returned execution ID against that user-authorized operation.
4. Poll GetExecutionStatus on the backend within a deadline.
5. Decode ResultJson and return an appropriately filtered status to the user.

Use portal labels such as Submitted, Running, Succeeded, Failed and Needs investigation. Label output Delivered only when your defined delivery evidence supports it.

8. Recover uncertain outcomes

Prevent repeated button clicks from submitting concurrent copies. If a response is lost, keep the operation unresolved and follow monitoring and recovery.

Your application operation ID is not an ATRS idempotency key. Check what ran and arrived before resubmitting. Use application workload limits and a queue for larger volumes; free capacity is only a snapshot.

Keep administrative scheduler controls and process termination outside ordinary customer actions.

Validate the portal

Test with at least two users and, where relevant, two customer data scopes:

• One user cannot view or change another user’s schedules or execution status.
• Report, parameter and recipient choices remain within policy after backend validation.
• Full edits preserve unrelated settings and destinations.
• Token renewal resumes the same operation.
• Repeated clicks and lost responses do not trigger uncontrolled resubmissions.
• Failed results and partial output produce an actionable investigation state.
• The actual report content, recipient and files match the approved choices.

Keep the intended definitions and test results with the integration. Apply the same ownership, parameter and recipient checks to single-report schedules, packages and data-driven packages.