MagentAI Analytics: From a Working Fabric Demo to Production-Ready Architectures

The MagentAI Analytics Demo is a fully implemented end-to-end analytics solution built in Microsoft Fabric.

Using synthetic data stored in SharePoint, the demo shows how operational service and AI-agent data can be ingested, transformed through Bronze, Silver and Gold layers, modeled semantically and presented in Power BI.

The screenshots below show the actual solution that was developed, including:

• SharePoint as the demo source

• Dataflow Gen2 for ingestion

• Fabric Lakehouses

• Notebook-based transformations

• A business-ready Gold model

• A Power BI semantic model

• Interactive reporting

The article then presents two additional architecture variants that show how the same solution could be implemented in a real production environment:

1. As an integrated Microsoft Fabric architecture

2. As a modular Azure data platform

The demo uses synthetic data and does not represent a productive Telekom or T-Systems system.

The Implemented MagentAI Fabric Demo

The working demo represents an analytics scenario around an AI-supported customer-service environment.

It combines operational service data with AI-related information to demonstrate how organizations could monitor service performance, incidents and AI-agent activity within one analytical solution.

The demo data includes:

• Customers

• Network incidents

• Service tickets

• AI requests

• Knowledge-base entries

These datasets can support analytical questions such as:

• How many service tickets are currently open?

• Which regions or services generate the most incidents?

• How many requests are processed by the AI agent?

• How does AI usage develop over time?

• Where do service bottlenecks occur?

• Which operational areas require management attention?

The objective was to create a complete and scalable analytical flow rather than an isolated Power BI report.

1. Source: SharePoint Demo Folder

The source files are stored as CSV files in a SharePoint demo folder.

The folder contains datasets such as:

• customers.csv

• network_incidents.csv

• service_tickets.csv

• ai_requests.csv

• knowledge_base.csv

SharePoint was selected because it provides a practical and accessible source for the demonstration.

It allows the complete architecture to be implemented and presented without requiring access to a productive AI-agent platform or operational source system.

Although the source is simplified, the downstream architecture follows the same principles that would be used in a larger production solution.

2. Ingestion with Dataflow Gen2

A Dataflow Gen2 loads the CSV files from SharePoint into Microsoft Fabric.

The Dataflow handles the initial connection, extraction and loading of the source data into the Bronze Lakehouse.

This separates source-system access from the later transformation logic and creates a clearly defined ingestion layer.

The implemented flow begins with:

SharePoint → Dataflow Gen2 → Fabric Lakehouse

3. Bronze Layer: Raw Data

The Bronze Lakehouse stores the source data close to its original structure.

Example tables include:

• bronze_customers

• bronze_network_incidents

• bronze_service_tickets

• bronze_ai_requests

• bronze_knowledge_base

The Bronze layer provides:

• A traceable landing zone

• Preservation of the original source structure

• Support for reprocessing

• Separation between ingestion and transformation

• A foundation for data lineage

At this stage, the data is available in Fabric but is not yet fully prepared for business reporting.

4. Silver Layer: Cleaning and Standardization

A Fabric notebook transforms the raw Bronze data into cleaned and standardized Silver tables.

The implemented transformations include:

• Trimming text values

• Standardizing categories

• Converting data types

• Normalizing date and timestamp fields

• Deriving additional columns

• Adding technical load timestamps

• Preparing reusable data structures

• Applying basic quality checks

Example Silver tables include:

• silver_customers

• silver_network_incidents

• silver_service_tickets

• silver_ai_requests

• silver_knowledge_base

The Silver layer provides a conformed and reusable data foundation.

Instead of preparing data independently inside each Power BI report, the transformation logic is centralized in the data platform.

5. Gold Layer: Business-Ready Data Model

A second Fabric notebook transforms the Silver data into a business-ready Gold model.

The Gold layer follows dimensional-modeling principles and contains dimensions and fact tables designed for analytics.

Example dimensions include:

• Customer

• Region

• Service

• Date

Example facts include:

• Service tickets

• Network incidents

• AI requests

The Gold layer provides:

• Business-oriented structures

• Consistent analytical relationships

• Reusable dimensions

• Prepared fact tables

• A scalable foundation for reporting

This ensures that Power BI consumes curated and governed data rather than raw operational source tables.

6. Semantic Model and Power BI Reporting

A Power BI semantic model is built on top of the Gold layer.

The semantic model contains:

• Relationships

• Measures

• Key performance indicators

• Business calculations

• Consistent reporting logic

The report can provide views such as:

Executive Overview

A high-level management view of service performance, operational activity and relevant trends.

Service and Incident Operations

A detailed analysis of service tickets, network incidents, priorities, regions and operational status.

AI Monitoring

An analytical view of AI requests, usage patterns and the role of AI-supported interactions within the service environment.

The implemented end-to-end flow is therefore:

SharePoint → Dataflow Gen2 → Bronze → Silver → Gold → Semantic Model → Power BI

Why This Is More Than a Power BI Demo

The primary goal was not simply to create a dashboard.

The demo shows how the complete analytical lifecycle can be implemented in Microsoft Fabric:

• Connecting to source systems

• Loading data

• Organizing raw data

• Applying transformations

• Implementing data-quality logic

• Creating a dimensional model

• Building a semantic layer

• Delivering business-ready reporting

This demonstrates how Fabric can act as a unified analytics platform rather than only as a reporting extension.

It also creates a foundation that can be extended with:

• Additional operational systems

• Larger data volumes

• APIs

• Event streams

• Machine-learning models

• Additional Power BI reports

• Data science and AI workloads

How the Real-World Architecture Could Work

The implemented SharePoint version is designed as a reproducible proof of concept.

In a real environment, SharePoint would likely be replaced by an operational AI-agent platform, APIs, telemetry feeds or an Azure landing zone.

The following two variants demonstrate how the same analytical scenario could be implemented as the “real deal.”

Variant 2: Production-Oriented Microsoft Fabric Architecture

The second variant shows how the solution could be implemented in a production environment using Microsoft Fabric as the central analytics platform.

Instead of synthetic CSV files, the data would originate from an operational AI-agent platform.

Possible source data could include:

• Conversation logs

• AI request logs

• Handover events

• Customer-satisfaction feedback

• Retrieval and knowledge-usage logs

• Operational telemetry

The AI-agent platform could provide this information through:

• APIs

• JSON exports

• Event streams

• Azure landing zones

• Scheduled batch exports

• Operational database interfaces

Ingestion

A Fabric Pipeline would orchestrate the loading of operational data into the Fabric Lakehouse.

Unlike the simplified SharePoint demo, the pipeline could manage:

• Multiple source systems

• Incremental loading

• Scheduling

• Error handling

• Monitoring

• Pipeline dependencies

Bronze Layer

The Bronze Lakehouse would store raw operational data such as:

• bronze_conversation_logs

• bronze_ai_requests

• bronze_handover_events

• bronze_csat_feedback

• bronze_retrieval_logs

The raw layer would preserve source fidelity and provide the basis for lineage, auditing and reprocessing.

Silver Layer

Fabric notebooks would clean, standardize and enrich the source data.

Typical transformations could include:

• Timestamp normalization

• Deduplication

• Type conversion

• Conversation enrichment

• Intent standardization

• Success and handover flags

• Data-quality validation

• Derived operational attributes

Gold Layer

The Gold Lakehouse would contain business-ready dimensions and facts.

Example dimensions:

• Date

• Channel

• Intent

• Customer segment

Example facts:

• AI requests

• Handovers

• Customer satisfaction

• Knowledge retrieval

Consumption

A Power BI semantic model would expose governed business logic for reports such as:

• Executive Overview

• AI Operations

• Agent Quality Monitoring

This architecture represents the production-oriented Fabric approach:

AI Agent Platform → Fabric Pipeline → Lakehouse Bronze/Silver/Gold → Semantic Model → Power BI

Fabric provides the ingestion, engineering, storage, semantic and reporting layers within one integrated platform.

Variant 3: Production-Oriented Azure Architecture

The third variant shows how the same use case could be implemented with individual Azure services.

The architecture consists of:

• Azure Data Lake Storage Gen2

• Azure Data Factory

• Azure Databricks

• Azure SQL Database

• Power BI

This approach separates the individual platform responsibilities more explicitly.

Landing Zone

Operational AI-agent data would first be stored in Azure Data Lake Storage Gen2.

Possible formats include:

• JSON

• Parquet

• Log files

• Structured exports

The Data Lake acts as the raw landing zone for incoming operational information.

Orchestration

Azure Data Factory would coordinate:

• Data extraction

• Copy activities

• Scheduling

• Dependencies

• Error handling

• Data movement

Transformation

Azure Databricks would implement the Bronze, Silver and Gold transformation logic.

The Bronze layer would preserve raw data.

The Silver layer would apply:

• Cleaning

• Standardization

• Deduplication

• Validation

• Business rules

• Derived attributes

The Gold layer would create reporting-ready dimensions and facts.

Serving Layer

The final analytical tables would be written to Azure SQL Database.

Example serving-layer tables could include:

• dim_date

• dim_channel

• dim_intent

• dim_customer_segment

• fact_ai_requests

• fact_handover

• fact_csat

• fact_retrieval

Azure SQL would provide a stable and consumable serving layer for Power BI.

Reporting

Power BI would connect to the prepared Azure SQL tables.

The semantic model would provide measures and KPIs such as:

• Total AI requests

• Handover rate

• Average customer satisfaction

• Average response confidence

• Retrieval success rate

The complete Azure flow would be:

AI Agent Platform → Azure Data Lake → Azure Data Factory → Azure Databricks → Azure SQL → Power BI

Three Variants, One Analytical Concept

The three variants represent different stages and implementation approaches.

Implemented SharePoint Demo

The first variant is the working solution shown in the screenshots.

It demonstrates:

• End-to-end implementation in Fabric

• Data ingestion from SharePoint

• Bronze, Silver and Gold processing

• Notebook transformations

• Dimensional modeling

• Semantic modeling

• Power BI reporting

Real-World Fabric Architecture

The second variant shows how the implemented demo could be connected to a real AI-agent platform while keeping Microsoft Fabric as the central platform.

Real-World Azure Architecture

The third variant shows how the same analytical requirements could be implemented with individual Azure services and a dedicated SQL serving layer.

The core business logic remains comparable across all three approaches. The primary differences concern platform integration, operational responsibility, scalability and architectural flexibility.

Fabric or Azure?

Microsoft Fabric is particularly suitable when an organization wants:

• One integrated analytics platform

• Tight Power BI integration

• Reduced service-integration effort

• Central governance

• Faster implementation

• Simplified platform operations

A modular Azure architecture may be preferable when an organization requires:

• Full control over individual services

• Existing Azure Databricks integration

• Independent component scaling

• Highly customized processing

• Integration into an established Azure platform

• A dedicated SQL serving layer

The right approach depends on the existing technology landscape, governance requirements, operating model and long-term data strategy.

Key Takeaways

The MagentAI demo demonstrates several important architectural principles:

End-to-End Thinking

Analytics begins at the source and does not end with the visualization.

Layered Data Processing

Bronze, Silver and Gold layers separate raw ingestion, data preparation and business modeling.

Reusable Business Logic

Transformations and analytical structures are centralized instead of being recreated in individual reports.

Governed Semantic Modeling

Power BI consumes prepared data through a consistent semantic layer.

Scalable Architecture

The SharePoint proof of concept can evolve into either an integrated Fabric solution or a modular Azure platform.

Business Value from AI Data

Operational AI-agent data can be used to measure service quality, automation performance, customer satisfaction and process efficiency.

Conclusion

The implemented SharePoint-based Fabric demo proves that the complete analytical flow can be built within Microsoft Fabric—from ingestion and transformation to semantic modeling and Power BI reporting.

The two additional variants show how the same concept could be transferred into a real production environment:

• as an integrated Microsoft Fabric architecture

• or as a modular Azure data platform

Across all three approaches, the objective remains the same:

Transform operational AI-agent data into reliable, governed and actionable business insights.