Synoptic Panel in Power BI (2026): v1 Retired — Here's the Modern Way

A synoptic panel maps your data onto regions of an image you supply. Each region — a room on a floor plan, a zone in a warehouse, a section of a stadium, a body part on an anatomy diagram — is matched to a category value in your model and filled with a color driven by a measure: a red/amber/green state, or a gradient from low to high.

The classic use cases:

- **Office floor plans** — desk occupancy, footfall, cleaning status by room. - **Factory and warehouse layouts** — OEE, downtime, pick rates by line, cell, or bay. - **Stadiums and venues** — ticket sales and concession revenue by section. - **Human-body diagrams** — injury frequency in sports and occupational-health reporting. - **Process flows and store layouts** — cycle time per stage, sales per aisle.

What makes the category special is that the visual is *yours*: the image reflects your building, your line, your venue. No stock chart type can replace a diagram your stakeholders already recognize.

Synoptic Panel by OKVIZ — the visual that created this category and one of the most-downloaded custom visuals in AppSource history — was officially retired on April 10, 2026. OKVIZ deprecated v1 in favor of Synoptic Panel v2, a ground-up rebuild.

If your reports use v1, nothing exploded on retirement day: existing report copies of the visual keep rendering for now. But you are on a migration clock. Retired visuals stop receiving updates, which means every new Power BI API version, rendering change, or security review is a chance for the visual to break with no fix coming. Tenant admins doing periodic visual audits will also flag it.

The practical takeaway: treat v1 like any deprecated dependency. Inventory the reports that use it, pick a destination (v2, or an owned visual — see below), and migrate on your schedule rather than waiting for a breakage to set the schedule for you.

Synoptic Panel v2 is a capable product, and the honest comparison starts with its structure. There are two editions:

- **Synoptic Panel v2 (full edition)** — the complete feature set, but it is **not Microsoft-certified** and can rely on external services. Tenants that enforce certified-only visuals will block it, and organizations with strict data-residency rules need to review what leaves the visual. - **Synoptic Panel Lite** — **certified**, processes everything locally, supports export to PDF/PowerPoint, but carries a reduced feature set.

Licensing is the second structural change: the free tier of v2 is capped at **15 data points and 1 map**. A floor plan with 20 rooms already exceeds the free tier. Beyond it you are into subscription licensing — the per-user-per-month model that scales with your report's audience and never ends.

None of this is a criticism of OKVIZ; certification trade-offs and freemium tiers are how the custom-visuals market works in 2026. But if you are choosing a synoptic route today, these constraints belong in the decision up front, not after the report is built.

The traditional synoptic workflow, unchanged for a decade, goes like this:

1. Open your image in **Synoptic Designer** (OKVIZ's free companion web tool). 2. **Trace every region by hand** — click vertex by vertex around each room, zone, or seat block. The tool's magic-wand helps on high-contrast images, but real floor plans usually mean manual tracing. 3. **Name each area** so its id matches the category values in your data model. 4. Export the result as an SVG with data-bindable sub-elements. 5. Load the SVG into the Synoptic Panel visual and bind category + measure.

Step 2 is where afternoons go to die. A 40-room floor plan means 40 polygons traced by hand, and every renovation or layout change means opening the designer again. It works — thousands of reports were built this way — but tracing polygons is exactly the kind of mechanical vision task that machines now do better.

The modern workflow replaces manual tracing with AI vision. In VizForge's Synoptic Studio:

1. **Upload the image** — floor plan, layout, diagram; PNG, JPEG, or WebP. 2. **AI segments it** — Claude Vision reads the image, outlines every region, and names each one from the labels it sees ("Lobby", "Office A", "Line 3"). A labeled 8-room floor plan segments in about a minute, with confidence scores per area. 3. **Refine in the editor** — rename areas, edit binding ids, drag vertices, draw extra areas the AI missed, delete ones you don't need, and preview with sample data to see exactly how the visual will color. 4. **Download a .pbiviz you own** — a generated custom visual with your map baked in. Import it via the Visualizations pane, bind a category and a measure, done.

The data matching works the way synoptic veterans expect: every area has a **binding id** (like `office_a`), and the visual matches those ids against your category column's values — case-sensitively. You edit ids in the editor so they line up with your model before you ever touch Power BI.

The ownership model is the structural difference: 15 credits per map, one time. No per-viewer licensing, no data-point caps, no vendor lifecycle risk — the .pbiviz keeps working whether or not you ever spend another credit.

If you have Synoptic Panel v1 reports today, your options in order of effort:

1. **Move to Synoptic Panel v2.** Your existing SVG maps carry over. Check the certification question against your tenant policy (full edition is uncertified; Lite is certified but reduced), and price the subscription against your viewer count if you exceed the free tier's 15 data points. 2. **Re-generate the map as an owned visual.** Upload the original image (or a screenshot of the current map) to an AI segmentation tool and export a .pbiviz. Rebind the same category and measure fields. This is usually under an hour per report and removes the vendor dependency permanently. 3. **Keep the SVG workflow, change the runtime.** SVG compatibility runs both directions: VizForge exports OKVIZ-compatible SVGs with data-bindable path ids, so a map segmented by AI can still feed a v2 visual — and existing hand-traced SVG investments are not stranded if you switch tools later.

Whichever route you choose, do the binding-id audit first: list the category values your model uses per report, and make sure the destination map's area ids match exactly. That mapping — not the drawing — is where synoptic migrations actually go wrong.