Microsoft Fabric Workload: Vendor Attestation

Workload Information

Each requirement below quotes the Microsoft language verbatim, then states our attestation answer with a supporting note. Structure mirrors the Publishing Vendor Attestation Template: Section III and the gate-by-gate enumeration in the Publishing Requirements for Workloads.

1. Business Requirements

1.1 Value to Customers

Microsoft requirement: "Workload must clearly articulate its value proposition, benefits, and use cases to help customers understand how it solves their business problems."

Attestation: Yes.

BI Pixie provides usage telemetry and engagement intelligence for Microsoft Power BI and Microsoft Fabric reports. Inside Fabric, the workload lets a customer:

• Instrument BI reports in their Fabric workspaces with invisible native Power BI elements that capture page views, visual clicks, filter selections, bookmark navigation, and (opt-in) NPS surveys and feedback.
• View engagement events, drill into individual user behavior, and identify low-adoption reports and pages, all from inside the Fabric portal alongside lakehouses, semantic models, and reports.
• Deploy the BI Pixie analytics dashboard (semantic model and report) to the customer's own Fabric workspace.

The workload is additive to the BI Pixie cloud (SaaS) offering. Both variants share the same instrumentation engine, the same customer and subscription records, and the same shared backend business modules.

1.2 Trial Experience

Microsoft requirement: "We provide an easy and fast trial experience. The trial is available to the customer without waiting time (less than 5 seconds), and provides a free and easy way to explore the offered workload for a limited time in accordance with Microsoft guidelines for Trials."

Attestation: Yes.

BI Pixie offers a 14-day trial: 3 reports, 2,000 Billed Sessions, 14-day retention, 2 refreshes per day, 3 members, no credit card required, full Pro feature access. The trial activates the moment a BI Pixie item is created in any Fabric workspace; a customer's first telemetry event is captured within 5 seconds of item creation. The same trial onboarding flow has been running in production on BI Pixie SaaS since its General Availability on April 1, 2026, providing more than a month of validated production traffic.

1.3 Monetization

Microsoft requirement: "The workload is available on the marketplace for the customer to procure with or without a trial in accordance with the monetization guidelines."

Attestation: Yes.

BI Pixie's transactable SaaS offer is generally available on Azure Marketplace as BI Pixie. The offer is dual-channel: Azure Marketplace for Azure-native customers, and Stripe for direct and SMB customers. The Marketplace integration emits daily usage events on multiple custom meter dimensions (per-bracket report counts and Billed Sessions) to the Microsoft Marketplace metering API, mirroring the per-unit pricing customers see on the Stripe channel. Both channels write to the same customer and subscription state through a single bridge so the user-facing experience is identical regardless of procurement channel.

The workload uses the Bring Your Own License (BYOL) monetization pattern endorsed by Microsoft for Fabric workloads (see WDK Monetization, How to Monetize Your Workload, and the workload certification FAQ). Customers subscribe directly from within the workload experience and choose their preferred channel: the BI Pixie Azure Marketplace SaaS offer, or Stripe at bipixie.com. Once subscribed, account administrators can distribute the licensed capacity across multiple business units. Each business unit receives an isolated license with its own data container and quota allocation; members assigned to a license see only that business unit's data.

2. Technical Requirements

2.1 Microsoft Entra Authentication and Authorization

Microsoft requirement: "Workload must use Microsoft Entra authentication and authorization." "Publisher must obtain user Microsoft Entra ID token from the Fabric host before calling Fabric JS functions." "Publisher must only obtain any Microsoft Entra token using the JavaScript APIs provided by the Fabric Workload Client SDK."

Attestation:

• [Yes] No other authentication and authorization mechanisms are used for the workload variant.

The workload uses Microsoft Entra ID exclusively. Token flow:

1. Frontend. The workload frontend acquires user tokens only through the Fabric Workload Client SDK (@ms-fabric/workload-client) using acquireFrontendAccessToken and the host-provided openBrowserTab navigation API. There is no MSAL in the workload frontend, no third-party identity providers, and no third-party cookies.
2. Backend. The workload backend authentication module validates the Fabric user token by verifying the JWT signature against the Microsoft Entra ID JWKS endpoint, validating audience, issuer, expiry, and not-before claims, and performing an On-Behalf-Of (OBO) exchange to obtain a Fabric API token scoped to Item.ReadWrite.All and OneLake.ReadWrite.All on https://api.fabric.microsoft.com/. The module fails closed if the workload application client ID is unset.
3. Service-to-service (control plane to data plane). Uses Azure Managed Identity with EasyAuth. The control plane managed identity presents an AAD bearer token; the data plane validates via EasyAuth and additionally enforces a custom DataPlane.Write AAD app role declared on the data plane application registration and assigned to the control plane's managed identity. Mutating endpoints return HTTP 403 if the role is missing. No function keys, no shared secrets, and no allow-listed IPs for internal calls.

Tenant ID for our publisher Entra app: 2273c41b-b8d0-45af-bee6-e08496ae6718 (DataChant tenant).

App registration: Multitenant web application registered in DataChant's Entra tenant; verified custom domain bipixie.com per the General Publishing Requirements: Microsoft Entra Requirements. DataChant is a Microsoft Entra Verified Publisher.

2.2 OneLake and Fabric Data Stores

Microsoft requirement: "Workloads integrate with One Lake to store data in the standard formats supported by the Fabric platform so that other services can take advantage of it."

How BI Pixie integrates with OneLake. When a customer creates a BI Pixie item in a Fabric workspace, the workload provisions a companion Lakehouse in that workspace and creates a OneLake shortcut from the Lakehouse's Files folder to the customer's vendor-managed telemetry container. The shortcut is a zero-copy pointer over the shared ADLS Gen2 substrate that underlies both OneLake and the BI Pixie data plane, so customers can read their telemetry from any Fabric notebook (PySpark or SQL endpoint), build Direct Lake or import semantic models on top of it, and join it with other Fabric items in the same workspace. The BI Pixie Dashboard itself, deployed by the workload as a packaged semantic model and report, consumes telemetry through this shortcut. Companion Lakehouses are reused across reinstalls (matched by display name); existing shortcuts are not duplicated.

Attestation:

• [Yes] Not all data and metadata is stored in OneLake or Fabric Data Stores.

This opt-out is explicitly provided by the Vendor Attestation Template: One Lake and is consistent with the control-plane / data-plane separation in How to Store Item Definition.

In summary, the workload integrates with OneLake via a per-customer companion Lakehouse and a OneLake shortcut to the customer's telemetry, uses Fabric Data Stores for the customer-facing dashboard items (semantic model and report), and uses Fabric's control-plane item-definition API for the small portable metadata file. The vendor-managed substrate for raw telemetry events at rest is documented in the table above.

2.3 Microsoft Entra Conditional Access

Microsoft requirement: "Workload must support Microsoft Entra Conditional Access policies for enterprise security requirements."

Attestation:

• [Yes] The service works in its entirety even if customers enable this functionality.

The workload acquires user tokens exclusively through the Fabric Workload Client SDK and exchanges them via the standard On-Behalf-Of flow against Microsoft Entra ID. Because the workload never bypasses Entra (no MSAL, no third-party cookies, no custom OAuth flows), all Conditional Access policies that the customer's Entra tenant applies (multi-factor authentication, compliant-device, named-location, sign-in risk, session controls) naturally apply to every workload session. The OBO exchange itself respects Conditional Access: if the customer's policy blocks the exchange (for example by requiring a specific authentication context), the workload surfaces a clean error and the user is prompted to satisfy the policy through Microsoft's standard experience.

2.4 Customer-Facing Monitoring and Diagnostics

Microsoft requirement: "Health and telemetry data needs to be stored for a minimum of 30 days including activity ID for customer support purposes, including Trials."

Attestation:

• [Yes] Minimum 30-day requirement is adhered to.

All BI Pixie operational telemetry (request traces, audit logs, error events, performance metrics) is sent to Azure Application Insights and forwarded to a centralized Log Analytics workspace with 90-day retention. Every API call that changes customer state is audit-logged with: the actor (user email), the verified caller managed-identity application ID, the action, the customer license key, the response status code, and a structured details object. Activity ID is Application Insights' built-in operation ID, retained for the same 90-day window.

A customer-facing service health page is live at bipixie.com/status/ (4 public components, rolling 30, 60, and 90-day uptime, refreshed every 5 minutes). See §5.3. Activity-ID-driven self-service diagnostics is a follow-up enhancement; for now, customers email support@bipixie.com with the activity ID from the page.

2.5 B2B (Cross-Tenant Collaboration)

Microsoft requirement: "The implementation of the workload is in line with Microsoft Fabric's sharing strategy focused on allowing customers to collaborate with their business partners, customers, vendors, subsidiaries, etc."

Attestation:

• [Yes] Cross-tenant B2B collaboration supported.

Because the workload uses Entra OBO tokens issued by the Fabric host, B2B guest users in a workspace authenticate exactly the same way as native users: the OBO token reflects the guest user's home tenant, and Fabric workspace RBAC governs whether they see the BI Pixie item. We perform no tenant-pinning beyond what Entra naturally enforces. Per-license RBAC inside the BI Pixie data plane is granted to the AAD object IDs of users authorized by the customer admin, so guest users gain access through the same flow as primary users.

2.6 Business Continuity and Disaster Recovery (BCDR)

Microsoft requirement: "We ask partners providing workloads to customers within Fabric to define Business Continuity and Disaster Recovery (BCDR) plans designed to tackle unplanned disasters and recovery steps."

Attestation: Yes.

The deployed architecture is multi-region capable. Production data planes run in eastus2, westeurope, and centralindia. Storage replication uses Read-Access Geo-Redundant Storage (Standard_RAGRS), so customer telemetry survives a full Azure region outage; the paired regions are centralus for eastus2 and northeurope for westeurope. The control plane runs in eastus2. Per-region private endpoints, Event Hubs, and Function Apps provide isolated blast radius. Compute is not currently replicated (active-passive failover is out of scope at current scale); recovery from a compute-region failure is a deploy-from-Bicep operation against the paired region.

DataChant's written BCDR plan, covering recovery time objectives, recovery point objectives, runbooks, failover procedure, communication plan, and annual test cadence, is available to enterprise customers and Microsoft reviewers under NDA upon request to support@bipixie.com.

2.7 Performance

Microsoft requirement: "The Workload implementation takes measures to test and track performance of their Items."

Attestation:

• [Yes] Performance tracking is not surfaced as a separate workload UI. Vendor support personnel monitor and tune workload backend performance via internal instrumentation; the items the workload creates and deploys surface their own performance through standard Microsoft tooling, described below.

For BI Pixie backend operations, DataChant tracks end-to-end traces, dependency timings, and custom metrics in Azure Application Insights, forwarded to a centralized Log Analytics workspace with 90-day retention. Operations staff monitor, alert on, and tune backend performance from this telemetry.

The performance of the items the workload creates is visible to customers through standard Microsoft tooling:

• Instrumented Power BI reports are native Power BI items in the customer's workspace. Their refresh, query, and rendering performance appears in standard Power BI tooling: workspace metrics, Fabric Capacity Metrics, dataset refresh history, and Performance Analyzer in Power BI Desktop.
• BI Pixie Dashboards (the semantic model and report the workload deploys) are native Fabric items. Their performance appears in Fabric Capacity Metrics and the Monitoring Hub alongside the customer's other Fabric items.

2.8 Presence (Region Availability)

Microsoft requirement: "To ensure that customer expectations independent of their home or capacity region are met, vendors need to align with fabric regions and clouds. Availability in certain restrictions also impacts your Data Residency commitments."

Attestation:

• [Yes] Service availability and colocation in the following pre-provisioned Fabric regions:
  • East US 2 (US data plane and control plane)
  • West Europe (EU data plane; default for both EU and UK Power BI tenants, with UK-geography routing available on request, see §4.3)
  • Central India (India and South Asia data plane)
• [Yes] On-demand geography provisioning for the United Kingdom (Microsoft Azure-recognized geography distinct from the European Union), Other APAC, Middle East and North Africa, Latin America, and Africa: DataChant commits to provisioning a dedicated regional data plane within 30 business days of a documented customer request. See §4.3 for full commitment language. The provisioning playbook is automated.
• [Yes] Auto-detect region from the customer's Power BI tenant home cluster so customers do not need to pick regions manually.

The control plane is in eastus2. Each data plane region runs an isolated stack (Function Apps, Event Hub, ADLS Gen2, VNet, private endpoints). Customer telemetry stores in the customer's auto-assigned region with Read-Access Geo-Redundant replication to the Azure paired region.

2.9 Public APIs

Microsoft requirement: "Fabric Public APIs are the backbone of automation... Fabric Public API empowers users to build innovative solutions."

Attestation:

• [Yes] The workload uses Fabric Public APIs.

The workload uses Fabric REST APIs for workspace and item enumeration, item creation (Lakehouse, Semantic Model, Report) for the BI Pixie Dashboard deployment, OneLake shortcut creation, and item definition save and get. All calls go through the OBO-exchanged Fabric token scoped to Item.ReadWrite.All and OneLake.ReadWrite.All on https://api.fabric.microsoft.com/. The umbrella Item.ReadWrite.All scope is deliberately preferred over per-type scopes to minimize the user's first-touch consent dialog, per Fabric API quickstart guidance.

2.10 Admin REST API Usage

Microsoft requirement: "Admin REST APIs are an integral part of Fabric admin and governance process."

Attestation:

• [Yes] No Microsoft Fabric Admin APIs are being used.

The workload operates entirely through delegated user permissions (OBO). It does not call any /admin/* endpoints.

3. Design and User Experience Requirements

3.1 Common UX (Fabric UX System Compliance)

Microsoft requirement: "The workload and all item types the partner provides as part of it comply with the Fabric UX guidelines."

Attestation: Implementation aligns with the Fabric UX System; a full compliance audit is in progress for the GA submission.

The frontend uses React, Fluent UI 2, and the @ms-fabric/workload-client SDK. Editor patterns use the prescribed ItemEditor, ItemEditorDefaultView, and ItemEditorEmptyView components from the Extensibility Toolkit. The ribbon contains the prescribed Home tab first, with the standard save and settings action factories. Sidebar navigation replaces the legacy ribbon-only pattern. The workload follows the standard 5-file editor pattern (Editor, EmptyView, DefaultView, Ribbon, Definition).

3.2 Item Creation Experience

Attestation: Standard Extensibility Toolkit item creation card. Single create card titled "BI Pixie". A full UX audit is in progress for the GA submission.

3.3 Monitoring Hub

Microsoft requirement: "All long-running operations need to integrate with Fabric Monitoring Hub."

Attestation: Yes. The item declares supportedInMonitoringHub: true and itemJobTypes: ["getData", "storeData"], opting the item into the Monitoring Hub via standard Fabric platform handling. Long-running instrumentation operations from BI Pixie items appear in the Fabric Monitoring Hub alongside other Fabric job items via the platform's projection of declared item job types.

No custom Monitoring Hub UI or job-detail extensions are added by this workload; the integration relies on the standard Fabric platform projection of declared item job types. Custom progress detail is surfaced in the workload editor's own jobs view as a complement, not a replacement.

3.4 Trial Experience

Attestation: Trial supported. See §1.2.

3.5 Monetization Experience

Microsoft requirement: "The monetization experience is in line with the design guidelines provided."

Attestation:

• [Yes] Bring Your Own License (BYOL).

Customers subscribe to BI Pixie at bipixie.com via Stripe or via the Azure Marketplace SaaS offer (both channels active and supported by the same webhooks and subscription state). The Fabric workload validates the customer's existing license key and surfaces plan state. New customers who discover BI Pixie through the Workload Hub are directed to bipixie.com or the Marketplace listing to start a subscription; the workload detects the new subscription on next load via the shared customer entity. This BYOL pattern is explicitly supported per WDK Monetization, How to Monetize Your Workload, and the workload certification FAQ.

Terms of Service (the BYOL contract) is published at bipixie.com/terms-of-service/.

The Plans page checkout flow uses the host-provided openBrowserTab navigation API (not window.open) to comply with Fabric iframe sandbox constraints.

3.6 Accessibility (WCAG 2.1 AA)

Microsoft requirement: "The user experience is in compliance with the Fabric UX design guidelines for Accessibility."

Attestation: Fluent UI 2 components are WCAG-compliant by default; a workload-specific WCAG 2.1 AA audit is in progress for the GA submission. The audit covers keyboard-only navigation, NVDA and JAWS screen-reader walkthrough of every editor view, light and dark theme contrast ratios, and focus-trap correctness on every dialog.

3.7 World Readiness and Internationalization

Microsoft requirement: "English has to be the default language. Content can be localized if you decide to do it. In this case add the supported languages to your attestation page."

Attestation:

• [Yes] English is the only supported language at General Availability.

All UI strings are routed through a translation helper, so localization is a tractable future addition (no hardcoded strings in JSX). DataChant has no committed localization roadmap and will add languages reactively if customer demand emerges.

3.8 Item Settings (Ribbon)

Attestation: Yes. Settings are accessible from the ribbon Home tab and open the workload settings view (account, billing, dashboard, and tracking configuration).

3.9 Samples

Attestation:

• [Yes] Samples not provided in the default workload deployment. The "Deploy Dashboard" action installs a clean semantic model and report populated by the customer's own telemetry, with no sample data.

Customers who want to evaluate BI Pixie with preloaded sample data can install the BI Pixie Power BI Template App from Microsoft AppSource (BI Pixie Enterprise, BI Pixie Starter) as a supported companion. The Template App ships with a preconfigured semantic model, report, and sample data.

3.10 Custom Actions

Attestation: Yes. The workload's Home ribbon includes the following custom actions: "Add Pixies" / "Update Pixies" / "Remove Pixies" (context-sensitive label for instrumenting reports), "Update All Pixies", "Open Dashboard", "Refresh Dashboard", "Invite Users", and "Contact Support".

3.11 Workspace Settings

Attestation: Not supported (matches the default per the Vendor Attestation Template).

3.12 Global Search

Attestation: Not supported (matches the default per the Vendor Attestation Template).

4. Security and Compliance Requirements

4.1 Security General

Microsoft requirement: "Workloads must go through a security review and assessment. Vendor attests that the security review and assessment was completed and will be periodically performed as enhancements and changes are made."

Attestation: Yes.

A multi-reviewer security audit was completed on 2026-03-20 and verified complete on 2026-03-27. Highlights:

• Managed identity end-to-end. Control plane to data plane authenticates exclusively via Azure Managed Identity with EasyAuth. No function keys and no shared secrets for internal calls.
• Custom DataPlane.Write AAD app role enforcement. A custom app role is declared on each data plane application registration and assigned to the control plane's managed identity. State-changing endpoints validate the role on every request and return HTTP 403 if it is missing.
• Audit logging on every state-changing API call (SOC 2 CC7.2). Each request that modifies customer state emits a structured JSON audit entry to Application Insights with: action, actor (advisory, from a request header), caller application ID (cryptographically verified managed identity claim), license key, status code, and a scoped details object. PII protection: object IDs and user hashes are truncated; function key values are never logged.
• VNet integration with private endpoints for the most sensitive components. All BI Pixie Function Apps route outbound traffic to internal Azure dependencies through a regional VNet. Private endpoints terminate the connection inside the VNet for the per-customer telemetry storage (Blob), the customer-records Table storage, Key Vault, and the event-consumer Function App. The customer-tracking ingestion endpoint and the workload backend Function Apps remain reachable over HTTPS for their respective callers (Power BI tracking pixels, Fabric Workload iframe, customer portal), with EasyAuth and managed-identity validation gating internal traffic.
• Default-deny firewalls on storage and Event Hub. Each storage account (telemetry, instrumentation, data plane API, control plane) is configured with default-deny network rules permitting only the VNet integration subnet and a small set of allow-listed operator IPs. The Event Hub namespace uses default-deny with trusted-service bypass for Azure-managed callers and a VNet rule for the integration subnet.
• Key Vault for secrets. Stripe keys, marketplace credentials, Power BI client secret, and Event Hub connection strings are all stored in regional and central Key Vaults with managed identity access.
• HTTPS only, TLS 1.2 minimum. Enforced on all Function Apps.
• Webhook signature verification on Stripe events, and JWT validation on Marketplace webhooks (issuer pinned to Microsoft Partner Center, audience pinned to the Marketplace client ID).
• Azure Front Door with Web Application Firewall. External tracking-pixel endpoints are behind Azure Front Door Standard with WAF rate limiting and Front Door identifier access restrictions.
• Failed-auth alerting. Azure Monitor alerts fire on 401 and 403 responses for the data plane apps.

Accepted gaps are documented internally with mitigations: Application Insights logs are not WORM-immutable (mitigation: RBAC on the Log Analytics workspace; immutable export to blob is on the backlog); the request-header actor field is not cryptographically bound to the caller (mitigation: the verified managed-identity caller application ID is logged alongside the advisory actor field).

DataChant's internal security architecture documentation is available to enterprise prospects under NDA upon request to support@bipixie.com. Third-party verification of these controls is addressed in §4.4 Compliance Attestation.

4.1.1 / 4.1.2 / 4.1.3 / 4.2.1 / 4.2.2 / 4.2.3: Token and Cookie Policy

Microsoft requirement: "Publisher must obtain user Microsoft Entra ID token from the Fabric host before calling Fabric JS functions." "Publisher must only obtain any Microsoft Entra token using the JavaScript APIs provided by the Fabric Workload Client SDK." "Publisher must not use third party cookies as part of their solution." "Publisher attests that only essential HTTP-only cookies are used by the Workload and only after positively authenticating the user."

Attestation:

• [Yes] Only essential HTTP-only same-origin cookies are used by the Workload and only after positively authenticating the user.
• [Yes] Not using or relying on third-party cookies as part of the solution.
• [Yes] Obtaining any Microsoft Entra token using the JavaScript APIs provided by the Fabric Workload Client SDK.

There is no MSAL in the workload frontend; tokens come exclusively from the Fabric SDK's acquireFrontendAccessToken. There are no analytics or marketing cookies in the workload variant. The customer portal (the SaaS variant) and the marketing site set their own cookies but those run in regular browser contexts, not inside the Fabric iframe; they are out of scope for the workload attestation per the iframe-isolation model.

4.1.4: Entra App Name Alignment

Microsoft requirement: "Microsoft Entra application name and publisher must align with the workload name to ensure clear identity and avoid user confusion."

Attestation: Yes. The workload Entra application is registered as "BI Pixie" under publisher "DataChant Consulting LLC" in DataChant's Entra tenant. Both fields match the workload display name and the Marketplace publisher. DataChant is a Microsoft Entra Verified Publisher.

4.2 Privacy

Microsoft requirement: "Every workload goes through a privacy assessment and a privacy review."

Attestation: Yes.

BI Pixie's privacy posture is operationally implemented as follows:

• Privacy by default for tracking-pixel telemetry. Email addresses are not collected by default for end-user tracking-pixel events; an MD5 hash is used for unique-user identification. The include_user configuration option, when false, prevents user identity capture entirely. The mask_ip option MD5-hashes IP addresses. The default configuration favors privacy: feedback collection and survey collection are off by default.
• Workload-session identity. Distinct from tracking-pixel telemetry, the Fabric workload session always carries the signed-in user's identity at the authentication layer (the Fabric token claims include user principal name / email). This identity is used to authorize workload backend calls and is not customer-controlled; it is the standard Fabric Entra ID model and is what makes Conditional Access (§2.3) and B2B (§2.5) work correctly. The privacy-by-default stance described above applies to the tracking-pixel telemetry the customer captures from their report viewers, not to the workload-session identity of the customer's own administrators using the workload UI.
• Customer-controlled tracking. Tracking-setup configuration is editable per customer and per project. "Clean mode" restores reports to their pre-instrumentation state (fully reversible).
• Self-service data removal (GDPR). The portal lets customers list tracked users (by hash, or by email if collected), select individuals for deletion, and delete all blobs under their subfolder. An audit log entry is written per deletion.
• Admin clean-data. Container deletion is gated on revoked-customer state and requires audit-logged admin action.
• Archive lifecycle. A dedicated archive container holds temporary safety copies of deleted event data; auto-deleted after 90 days by Azure Blob lifecycle policy. Disclosed in the published Privacy Policy and Terms of Service.

The published privacy policy is at bipixie.com/privacy/. The privacy posture is operationally implemented per the controls above; third-party privacy certification is addressed in §4.4 Compliance Attestation.

4.3 Data Residency

Microsoft requirement: "Fabric is making an Enterprise Promise around data not leaving the geography of the tenant for stored data and data in transit. As a workload you're showing up in Fabric directly and users need to be aware what your commitments to Data Residency are."

Attestation: Yes.

Commitment. End-user telemetry data is stored at rest in the Azure region selected for the customer, with Read-Access Geo-Redundant Storage replication to Microsoft's paired region within the same geography. Active production regions:

On-demand geography provisioning. DataChant operates pre-provisioned production data planes in the United States, the European Union, and India. For any other geography, including the United Kingdom (Microsoft Azure treats the UK as a separate geography from the European Union, with uksouth and ukwest as the UK-region pair), Other APAC, Middle East and North Africa, Latin America, and Africa, DataChant commits to provisioning a dedicated regional data plane within 30 business days of receiving a documented customer request via the customer portal. The new data plane is provisioned at no additional cost to the customer; existing customer telemetry is migrated from the default geography to the new region upon completion. This commitment applies equally to enterprise customers with strict data-residency requirements (financial services, public sector, healthcare, regulated industries) and to SMB customers requesting a specific geography. The provisioning playbook is automated, so the SLA reflects deploy-and-verify time, not engineering effort.

Region selection is automatic based on the customer's Power BI tenant home cluster, with a manual override for unsupported geographies. Each region runs an independent stack (Function Apps, Event Hub, ADLS Gen2, VNet, private endpoints); no cross-region telemetry replication and no cross-geography paired backup.

Data in transit: TLS 1.2 minimum on every external surface; intra-Azure traffic for the data pipeline rides VNet integration with private endpoints.

4.4 Compliance Attestation

Microsoft requirement: "The publisher attests to the following security, data, and compliance regulations and standards."

Attestation: Yes.

Per the Workload Publishing Requirements compliance-attestation table, this requirement is validated by self-attestation and is Optional at both Preview and General Availability. DataChant's posture is to align operationally with applicable regulatory regimes and security control frameworks while reserving third-party certification engagements for the timing that matches customer requirements. Specific positions:

5. Support Requirements

5.1 Live Site (Microsoft direct vendor outreach)

Microsoft requirement: "Microsoft support teams need to be aware of how to contact you in case customers are reaching out to us directly."

Attestation: Yes.

A written Live Site Operations Plan (incident severity matrix, on-call roster, MTTA / MTTR targets, communication template, post-mortem cadence) is in progress for the GA submission.

5.2 Supportability

Microsoft requirement: "Vendors are responsible for defining and documenting their support parameters (Service level agreement, contact methods, ...). This information needs to be linked from the Workload page and should always be accessible to customers."

Attestation:

• [Yes] Support information is published to the marketplace offering and available to users and customers directly via the workload.

The help link in the workload manifest points to bipixie.com/support/. Support contact appears in the product details page and within the workload empty-state and revoked-account views.

Service Level targets (GA):

• Uptime target: 99.9% monthly target, calculated against the workload backend, excluding scheduled maintenance windows announced at least 48 hours in advance.
• Severity 1 (production down for the customer): Initial response within 4 business hours (Monday to Friday, 09:00 to 17:00 US Central).
• Severity 2 (degraded functionality, workaround available): Initial response within 1 business day.
• Severity 3 (general support, how-to, feature questions): Initial response within 2 business days.
• MTTR commitment: Not provided at GA.
• Service credits: Not offered at GA.

These targets are published as a dedicated Service Level section at bipixie.com/support/. The support page is reachable from the workload's product details (via the manifest's help link), satisfying the §5.2 requirement that SLA and support parameters be linked from the workload page.

5.3 Service Health and Availability

Microsoft requirement: "Vendors need to host a service health dashboard that shows their service health and availability to customers."

Attestation: Yes. Service health dashboard is live at bipixie.com/status/.

The page surfaces 4 customer-facing components (Customer Portal, Fabric Workload, Report Instrumentation, Tracking Pixels) with rolling 30, 60, and 90-day uptime, an active-incident timeline, scheduled-maintenance windows, and an RSS feed at /status/feed.xml. A dedicated Function App probes the health endpoint on each component every 5 minutes and writes the status to a public-read blob with sensible cache controls. Public-language rules govern incident copy so internal architecture is never disclosed via outage updates. Internal monitoring (Application Insights, Log Analytics, Azure Monitor alerts, KQL workbooks) feeds the public projection and remains the source of truth for operators.

6. Fabric Features

6.1 Application Lifecycle Management (ALM) / CI/CD

Attestation: Yes. BI Pixie supports Application Life Cycle Management (ALM) for the native Fabric items it generates.

• [Yes] CI/CD is supported for the native Fabric items that the workload generates.

The BI Pixie Dashboard (a semantic model and a report) deployed by the workload into the customer's Fabric workspace is composed of native Fabric items. These participate in standard Fabric ALM tooling, including Fabric deployment pipelines and Fabric Git integration alongside the customer's other workspace items.

For the BI Pixie item type itself, item-definition portability across workspaces is supported via Fabric's saveItemDefinition and getItemDefinition control-plane APIs (see §6.2 and §2.2). Full integration of the BI Pixie item type into Fabric CI/CD (a CICD section in the workload manifest and custom deployment-pipeline contributions) is planned for a post-GA release.

6.2 Item Definition Portability

Attestation:

• [Yes] Items can be restored with their definition in other workspaces.

The item definition is a small portable JSON containing scope and tenant pointers only (license-key reference, project name, region pointer); never the full tracking config. ≤5 text files per definition. The tracking-setup config itself stays in vendor-managed blob storage (see §2.2). When an item is exported to another workspace, the definition restores; on first load the workload re-fetches the tracking config from blob storage based on the scope pointer.

6.3 Private Links

Attestation: Not Supported (Microsoft Fabric Private Links into the workload backend are not yet supported). Will be considered post-GA if customer demand emerges.

6.4 Data Hub

Attestation: Yes. The item declares supportedInDatahubL1: true and category Data, opting the item into the OneLake Data Hub. BI Pixie items appear in the Data Hub list of Data category items in workspaces where they are present.

This is standard Fabric platform handling for items with the Data category. No custom Data Hub UI or surface extensions are added by this workload. Lineage emission for the telemetry data the workload processes is not currently implemented (see §6.5).

6.5 Data Lineage

Attestation: [Yes] Supported for the native Fabric items that the workload generates.

The BI Pixie Dashboard (semantic model and report) deployed by the workload into the customer's Fabric workspace participates in Fabric data lineage natively, alongside the customer's other Fabric items. Custom lineage emission from the BI Pixie tracking-setup configuration and the telemetry data plane is planned for a post-GA release.

6.6 Sensitivity Labels

Attestation: [Yes] Supported for the native Fabric items that the workload generates.

Microsoft Purview Information Protection sensitivity labels propagate on the BI Pixie Dashboard items via Fabric's native handling, alongside the customer's other Fabric items. Custom propagation through the BI Pixie tracking-setup configuration or BI Pixie telemetry exports is planned for a post-GA release.

Item Publishing Requirements

Microsoft requirement: See Publishing Requirements for Items: per-item UX (ribbons, canvas, tabs, dialogs), data handling, accessibility, lifecycle.

The single item type DataChant.BIPixie.Pixies (display name "BI Pixie") is the only item subject to per-item gates. The Fabric UX compliance audit and Fabric Extensibility Toolkit Validator pass are in progress for the GA submission.

Per-item gate summary:

• Ribbon structure: Home tab first, save action, settings action; implemented per the standard editor pattern.
• Canvas and editor views: uses the prescribed ItemEditor, ItemEditorDefaultView, and ItemEditorEmptyView components.
• Tabs and dialogs: audit in progress.
• Item creation card: single create card.
• Empty, error, and loading states: audit in progress.
• Accessibility per item: WCAG 2.1 AA audit in progress (see §3.6).
• Item-level localization keys: audit in progress.
• Compatible item types casing: verified case-sensitive against the Workload Client SDK's item-type unions.

Extra Notes

The BI Pixie workload is additive to the BI Pixie cloud (SaaS) offering. It shares the same instrumentation engine, the same customer and subscription records, the same shared backend business modules, and the same authentication-into-data-plane pattern via Azure Managed Identity with EasyAuth. The workload-specific surface is: Fabric token validation and OBO exchange, the workload React + Fluent UI 2 frontend, and the workload Blueprint on the control plane.

Storage architecture stance is unchanged from the SaaS offering:

• Telemetry stays in vendor-managed Azure Data Lake Storage Gen2 (per-customer containers, customer-selected region).
• Tracking-setup configuration stays in vendor-managed blob storage.
• Item definition uses Fabric's saveItemDefinition control-plane API for the small portable JSON.

This is the explicitly-supported "Not all data and metadata is stored in OneLake or Fabric Data Stores" opt-out per the Vendor Attestation Template, Technical Requirements, "OneLake" section.

References

• Privacy Policy (bipixie.com/privacy/)
• Terms of Service (bipixie.com/terms-of-service/)
• Support (bipixie.com/support/)
• Service Health (bipixie.com/status/)
• Workload Documentation Quickstart

Contact

For questions about this attestation or to request DataChant's internal security architecture documentation under NDA: