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

Configure Power BI Filters Paginated Parameters and Rendering

Describe report personalization and rendering behavior in a supported schedule model.

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

Power BI basic filters

The documented basic filter model extends a shared filter base and applies an In or NotIn operation to an array of values. The shared model identifies the Power BI object, table, field, filter level, and optional slicer selector information.

Power BI advanced filters

The advanced filter model supports first and second conditions joined by a logical operator. The public model lists comparison, text, and blank-value operators.

  • LessThan, LessThanOrEqual, GreaterThan, GreaterThanOrEqual
  • Contains, DoesNotContain, StartsWith, DoesNotStartWith
  • Is, IsNot
  • IsBlank, IsNotBlank
  • And or Or between the first and second condition

Slicer and target selection

A filter can target the applicable report field or supported slicer. The model includes slicer title and field selectors and an IgnoreInsertBlanks option. Resolve the report and visual metadata first, then validate the filter against the report version used in production.

Paginated-report parameters

Property Purpose
ParameterName Name expected by the paginated report.
ParameterValue Value supplied to the report.
IsNull Send a null value where supported.
Type String, Numeric, Date, Boolean, or Other according to the documented model.

Rendering settings

  • Minimum and maximum loading time.
  • Page width, page height, and orientation.
  • Pages to render.
  • Margins and view style.
  • Rendering method, including documented Webkit, Chromium, and Image values.
  • Transparent background.
  • Expected minimum report size and rerender behavior.
  • PDF cropping and compression.

Compatibility: Not every property applies to every report type or output format. Use the request model for the selected endpoint and test the exact PBRS build and report source.

Validation procedure

  1. Discover the report in the target environment.
  2. Confirm table, field, slicer, parameter, page, and visual names.
  3. Create or update a non-production schedule.
  4. Render to a controlled destination.
  5. Verify data selection, page coverage, dimensions, file content, and final size.
  6. Record the model and PBRS build used for the successful test.

Parameter and rendering decisions

Document parameter name, data type, allowed values, nullability, single- or multi-value behavior and the PBRS identifier used to target it. For filters, record the target table, column, operator and value encoding.

Do not select Chromium, native API or image rendering from performance assumptions alone. Development must publish a build-specific decision table showing supported report types, outputs, visual behavior, authentication constraints and known limitations for each rendering mode.

Rendering-mode evaluation method

Dimension What to test
Compatibility Report source, output format, visual types, bookmarks, filters and paginated parameters
Correctness Page coverage, fonts, colors, graphics, embedded content and final file size
Performance Render duration, queue latency, CPU, memory, browser-process count and source throttling
Scale Recipients, files per execution, thread count, concurrent schedules and collaborator distribution
Recovery Timeout, partial output, cancellation, rerun and duplicate-delivery behavior

Support evidence shows that Chromium and native Power BI API rendering can have materially different resource profiles for high-volume workloads. That evidence justifies a controlled benchmark; it does not establish a universally preferred method.

Repeat-field documentation requirement

The final recurrence reference must explain that Frequency controls the primary schedule cadence, while Repeat, RepeatInterval, RepeatUnit and RepeatUntil control additional executions within the scheduled period. The precise interaction, defaults and boundary conditions remain subject to Development validation.

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.