Skip to content
  • There are no suggestions because the search field is empty.

Build a Customer-Facing Scheduling Portal with the PBRS API

Use PBRS behind a secure application so authorized users can configure controlled Power BI report deliveries.

Review status: Draft for Development and Support review. Routes and models labelled validation required must be tested against the supported PBRS build before publication.

Reference architecture

  1. The browser authenticates to your application, not directly to PBRS.
  2. Your server authorizes the tenant and user.
  3. The server offers only allow-listed PBRS reports, recurrence choices, formats and destinations.
  4. The server maps friendly choices to PBRS identifiers discovered and cached server-side.
  5. The server creates or updates the schedule through a protected PBRS client.
  6. The application reads the saved schedule back and stores an audit record.
  7. A controlled test or first execution verifies artifact creation and delivery.

Security controls

  • Never expose PBRS credentials or tokens in browser code.
  • Enforce tenant isolation on every discovery, read and write.
  • Allow-list report, workspace, folder, schedule and destination choices.
  • Validate recipients, filenames, paths, parameters and filter values server-side.
  • Apply least privilege, rate limits, audit logging and secret rotation.
  • Use a client-owned idempotency strategy and reconcile after timeouts.

Portal workflow

Discover approved objects, collect a constrained scheduling request, validate it, create or update the PBRS schedule, read it back, execute a controlled test, and display an outcome that distinguishes accepted, executed and delivered.

This pattern is based on an evidenced production use case. Exact endpoints and models must come from the build-verified reference articles.

Recurrence controls in a portal

Do not reduce PBRS recurrence to a single “repeat” switch. Present the primary frequency separately from intraday repetition. Validate and persist start date, execution time, frequency-specific selections, optional end date, Repeat, interval, unit and repeat-until value. Read the schedule back and show the calculated next run before enabling it.

Portal outcome and recovery states

  • Saved: PBRS returned and persisted the intended schedule.
  • Scheduled: the calculated next run matches the user's choice.
  • Accepted: PBRS accepted a test execution.
  • Executed: the execution reached a successful terminal state.
  • Delivered: every expected artifact and destination was verified.
  • Needs attention: the request is ambiguous, timed out, partially failed or requires reconciliation.

Documentation standard: Record the PBRS build used for verification, test in a non-production environment, redact credentials and customer data, and confirm the saved PBRS state after every write.