rss.livelink.threads-in-node

How are teams combining AI agents with Microsoft Fabric Activator for intelligent automation?

codeautomation — Mon, 28 Sep 2026 20:35:35 GMT

I am exploring how AI agents can work together with Microsoft Fabric Activator to create more intelligent event-driven workflows.

Traditional automation usually depends on predefined rules and thresholds, but AI agents could add more context and decision-making capabilities.

Some possible scenarios:

Detecting business events from real-time data streams
Using AI to analyze the context behind an event
Triggering workflows based on intelligent decisions
Sending recommendations instead of only alerts
Connecting Fabric data workflows with external APIs and business systems

I would like to understand how developers are approaching this:

Are you using Fabric Activator with Power Automate, APIs, or custom AI agents?
What are the best patterns for handling complex event conditions?
How do you manage accuracy and avoid unnecessary automation triggers?

Would love to hear practical examples or architecture approaches from the community.

Date slicer

pradipir — Thu, 24 Sep 2026 19:34:23 GMT

Hi, I need some help with Power BI.

I want to use a Between Date Slicer and display the dates in this format:

DD-MMM-YYYY
Example: 01-Jan-2020

I don’t want to use the default dropdown/date format. I specifically want the Between slicer with two date inputs (From Date and To Date), but I need the displayed dates to appear as 01-Jan-2020 instead of the default format.

Could you please guide me on how to achieve this? If the standard Power BI slicer does not support this format, is there any custom visual or alternative solution that can provide the same Between Date functionality with the DD-MMM-YYYY format?

Thanks!

Fabric Eventstream MySQL CDC scans all databases and does not emit row-level events

girishtharwani2 — Sat, 12 Sep 2026 09:17:46 GMT

Hello Fabric Team,

We are testing the Microsoft Fabric Eventstream MySQL CDC connector with an AWS RDS MySQL database.

The MySQL instance is accessible through a private IP, and Fabric connects through a VNet data gateway/private network connection. Connectivity is successful, and the connector remains Active without reporting processing errors.

Our MySQL environment contains the same table structure across multiple databases, following a pattern similar to:

application_<tenant>.sample_table

We configured the source to capture only one fully qualified table:

application_tenant1.sample_table

The MySQL configuration is:

log_bin = ON
binlog_format = ROW
binlog_row_image = FULL
The connection user has SELECT, SHOW DATABASES, REPLICATION CLIENT, REPLICATION SLAVE/REPLICA, and the required snapshot permissions.
Each Fabric source uses a unique Server ID.
CDC from the same RDS instance has previously worked successfully through another CDC platform.

However, we are seeing the following behavior:

Although only one fully qualified table is selected, Fabric/Debezium scans schema metadata for every accessible database and table on the MySQL server.
More than 45,000 schema events were generated across the tenant and history databases.
The schema events contain DDL such as DROP TABLE IF EXISTS and CREATE TABLE.
Snapshot mode is configured as Initial.
The selected table contains approximately 16,000 records, but Fabric emitted zero snapshot r events.
We committed a new insert into the selected table after schema discovery finished, but no c event was emitted.
Eventhouse receives the schema events successfully, confirming that the source-to-Eventhouse path is operational.
The Eventhouse destination stores the Debezium payload in a dynamic column using a mapper from payload to RawEvent.

Could you please confirm the following?

Is it expected for the Fabric-managed MySQL CDC connector to scan and publish schema events for every database when only one fully qualified table is selected?
Does Fabric expose or support settings equivalent to:
- database.include.list
- table.include.list
- schema.history.internal.store.only.captured.databases.ddl
- schema.history.internal.store.only.captured.tables.ddl
Why would the connector finish schema discovery but not emit existing rows from the selected table when Snapshot mode is Initial?
Why are committed inserts not emitted after the schema phase appears to finish?
Is there a known limitation involving AWS RDS MySQL accessed through a private IP and VNet data gateway?
What is the recommended supported destination pattern for this CDC stream?

Our main objective is reliable ongoing CDC capture. We are flexible about the landing destination and can use:

Eventhouse
ADLS Gen2 in JSON or Parquet
Fabric Lakehouse/OneLake
Snowflake as the final destination

Please let us know which logs, connector identifiers, timestamps, or additional configuration details would help investigate this behavior.

Thank you.

Unable to create a Monitoring Eventhouse in a Microsoft Fabric workspace.

jonypanchal7 — Mon, 07 Sep 2026 12:32:40 GMT

I am trying to enable Workspace Monitoring for a Microsoft Fabric workspace. The user has Fabric Administrator access and is also a Workspace Administrator.

However, under:

Workspace Settings → Monitoring

the + Eventhouse option is disabled/not available.

We have verified the tenant-level settings and confirmed that “Workspace admins can turn on monitoring for their workspaces” is enabled.

Changing Ingestions from JSON

MoFabricIoT — Thu, 03 Sep 2026 11:54:06 GMT

I have an EventStream receiving IoT Data out of JSONs. In my KQL table the columns timestamp, deviceId and for example x and y exist. The data from one sensor gets ingested in the columns timestamp, deviceId and y. No x since there is no data in the JSON for that. I dont work with a Mapping because it only makes it more complicated and the names in the JSON and in the KQL table are identical.

No I changed the named for data from y to x when creating the JSON. Since there is no mapping and the column already exists in the KQL table the data should be saved now in column x.

My problem is, it doesn't the data is not in x nor in y. It seems to be gone.

Is that a bug in fabric? Can I solve this?

Unable to see PowerBI Activator Alerts

chnunez — Tue, 01 Sep 2026 16:51:54 GMT

I think I created an alert as a test and now I'm getting daily alerts in Teams from Activator. I tried to turn the rule off, but the link takes me to a Power BI app space I don't use, and I just see an error message.

I tried to stop the Teams messages by deactivating the bot and now I get daily emails from Activator. I don't see any rules on the report that I made the test alert on either.

How do I turn this off? One day I might actually want to use Activator alerts but I can't even manage them right now....and I work at Microsoft

Anomaly Detector is disabled

MoFabricIoT — Thu, 20 Aug 2026 11:42:52 GMT

Hello, I have a big Table in which we have our TimeSeries data from various devices. Since not every device sends the same data we have a big schema of numeric columns that are not filled for every deviceId.

Is that the reason why there is no Anomaly Detector in my EventHouse? In the schema I can see that columns for the data are int or real. Some columns are string, but that shoudn't be the reason, right?

Has anyone faced the same issue?

Text not shown in activator Alert msg

ram142more — Wed, 19 Aug 2026 05:24:49 GMT

Hi Team,

I am trying to show failed pipeline in activator with failed pipeline name but it wont show any variable after entering @ for Pipeline.

Can anyone guide me how to show text in activator alert msg, please?

Fabric Business Events: what delivery guarantees and replay pattern should we design for?

ShivekMaharaj — Mon, 17 Aug 2026 20:41:33 GMT

Hi all,

I am testing the newer Business Events capability in Fabric Real-Time Intelligence and trying to understand what reliability assumptions should be made for a production design.

The pattern I am looking at is roughly:

Eventstream → Business Event → Activator → downstream action / User Data Function

with Eventhouse enabled so the published business events are also retained for historical analysis.

The current documentation explains the publisher/consumer model and shows how Eventstream can publish a governed business event that Activator then consumes. What I have not been able to find clearly documented is the delivery contract between the published business event and its consumers.

A few things I am trying to clarify:

If an Activator consumer or downstream action is temporarily unavailable, does Fabric retry delivery of the business event?
Should consumers assume at-least-once delivery and therefore be designed to handle duplicate events, or is a different delivery model used?
Is event ordering guaranteed in any scope, for example for events from the same Eventstream publisher?
Since published business events can also be retained automatically in Eventhouse, is that retained history intended to support replay/reprocessing after a consumer outage, or is it primarily an analytical record and replay would need to be implemented separately?
Are there documented retry or delivery-retention windows that should be considered when designing an operational workflow?

I am mainly trying to understand what a resilient production pattern should look like when the business event triggers something with side effects, where processing the same event twice or silently missing an event would matter.

Would you generally make the downstream consumer idempotent and treat Eventhouse as an audit/recovery store, or is there a more Fabric-native pattern for this?

Interested to hear how others are approaching this with Business Events and Activator.

Eventhouse Capacity Planner minimum CU not reflected in UI/API

WorkFull22 — Thu, 13 Aug 2026 09:38:53 GMT

Hi all,

We've set a minimum of 32 CU on our Eventhouse via Capacity Planner (autoscale alone isn't sufficient - we need guaranteed baseline capacity to protect a large bulk-ingestion workload from destination-side OutOfMemory during a migration). We've been told the 32 CU setting has been applied on the backend, but the Fabric UI and REST API (.show cluster / .show diagnostics) still report capacity/behavior consistent with a much lower tier.

Can anyone confirm:

Whether the a custom minimum CU value is actually enforced server-side even though the UI/API don't show it, and
When UI/API reporting is expected to catch up to reflect the configured minimum?

Any insight or similar experience would be appreciated.

Best practice for handling schema evolution in Fabric Eventstream before data reaches Eventhouse?

ShivekMaharaj — Wed, 12 Aug 2026 21:33:25 GMT

I have an Eventstream receiving operational events where the schema may evolve over time.

For example, the producer initially sends:

DeviceId, Timestamp, Temperature, Status

but later adds fields such as:

Location, FirmwareVersion, ErrorCode

I want the pipeline to continue ingesting events without breaking downstream KQL tables, update policies, materialized views, or Real-Time Dashboards.

I am trying to understand where schema evolution should ideally be handled in a production Fabric RTI architecture.

Would you:

enforce the contract upstream using Schema Registry
normalize changing fields inside Eventstream before Eventhouse ingestion
land the raw payload first and handle schema evolution inside Eventhouse/KQL
maintain separate versioned event schemas/tables

How are people handling this in production when producers can add fields without notice?

I am particularly interested in avoiding a design where every small upstream schema change forces updates across Eventstream, KQL tables, update policies, and downstream dashboards.

Capacity overview events and Timepoints details

rgsalido — Tue, 11 Aug 2026 11:04:27 GMT

Good morning,

is there any update on when the information about the operations provided by the 'Capacity overview events' connector from an eventstream will be included?

thanks in advance

Best practice for deciding between Eventstream transformations and Eventhouse update policies

ShivekMaharaj — Thu, 06 Aug 2026 18:41:22 GMT

Hi Fabric Community,

I am exploring a Real-Time Intelligence architecture and would appreciate some guidance on where transformation logic should ideally be placed.

The proposed flow is:

Azure Event Hubs → Fabric Eventstream → Eventhouse → Real-Time Dashboard / Power BI

Fabric Eventstream supports filtering, field management, aggregation and other processing before events are written to the destination. An Eventhouse can also ingest the raw events first and transform them into curated tables through KQL update policies.

I am trying to understand the recommended boundary between these two layers.

For example, assume the incoming event contains:

Device or customer identifier
Event timestamp
Event type
Location
Numeric readings
Additional JSON properties

The required processing includes:

Removing events that fail basic validation
Renaming and standardizing fields
Converting timestamps and data types
Flattening selected JSON properties
Enriching the event with reference data
Creating five-minute aggregates
Preserving the original event for auditing and future reprocessing

My current thinking is:

Use Eventstream for lightweight filtering, routing and simple schema normalization.
Land the original event in a Bronze table whenever replay or auditing is required.
Use Eventhouse update policies or KQL for enrichment, reusable business logic and curated Silver tables.
Use materialized views for frequently queried aggregations rather than calculating them repeatedly in dashboards.

However, I am unsure where Microsoft recommends drawing the line.

A few questions:

Are there transformation types that should generally remain in Eventstream rather than Eventhouse?
Is it considered good practice to send both the raw stream and a transformed derived stream into separate Eventhouse tables?
When using Eventstream’s Event processing before ingestion mode, what are the trade-offs compared with direct ingestion followed by an Eventhouse update policy?
How do teams handle changes to transformation logic when historical events need to be reprocessed?
For reference-data enrichment, would you normally perform the lookup in Eventstream or after ingestion with KQL?
Are five-minute or hourly aggregations better implemented in Eventstream, through an update policy, or with an Eventhouse materialized view?

Microsoft’s Eventstream destination guidance documents both direct ingestion and event processing before ingestion, while the KQL update-policy documentation provides another way to transform ingested data.

I would be interested to hear how others divide responsibility between Eventstream and Eventhouse in production, particularly where auditability, reprocessing and maintainability are important.

Thanks in advance!

Best Way to Monitor Marketing Campaign Performance in Real Time Using Microsoft Fabric or Power BI?

iluvsmmpanel — Wed, 05 Aug 2026 13:31:22 GMT

Hi everyone,

I'm building a real-time dashboard in Power BI to monitor social media marketing campaigns. The goal is to combine data from platforms like Instagram, Facebook, and Google Analytics into a single dashboard.

I would like to track metrics such as:

Impressions
Reach
Clicks
CTR (Click-Through Rate)
Engagement Rate
Conversions
ROI (Return on Investment)

I'm considering using Azure Data Factory, Azure SQL, and Power BI for data collection and visualization.

Has anyone implemented a similar solution? Which architecture or Microsoft services would you recommend for near real-time reporting? Any best practices for handling automatic refreshes, data modeling, and performance optimization would be greatly appreciated?

I also put together a guide on social media analytics and campaign monitoring on my website. If sharing resources is allowed here, I'd be happy to share it with anyone who is interested.

Thanks in advance for your suggestions!

Luv Kalra

Real time dashboard

powerbidev123 — Sun, 02 Aug 2026 13:33:26 GMT

Since the latest Microsoft Fabric update, I've noticed a change in how Real-Time Dashboard refresh behaves.

Previously, I could configure visuals with Continuous refresh, allowing them to update almost immediately whenever new data arrived (typically within a few seconds, with a maximum delay of around 10 seconds).

After the recent update, it appears that continuous refresh is enabled by default, but visuals now refresh at a fixed minimum interval of 10 seconds. In addition, visuals that don't support continuous refresh—or when no new data is received—seem to refresh every 30 seconds.

I'm trying to understand whether this is expected behavior or if there's a way to restore the previous experience.

Specifically:

Is it still possible to configure Real-Time Dashboard visuals to refresh more frequently than every 10 seconds?
Has the previous event-driven continuous refresh option been removed, or is it available through another setting?
Are there any recommended approaches to achieve near real-time updates when new data arrives instead of relying on fixed refresh intervals?
Was this change introduced intentionally as part of the latest Microsoft Fabric release?

Our dashboards are used to monitor live operational processes, so even a 10–30 second refresh delay has a noticeable impact compared to the earlier behavior. Any clarification or guidance from the community or Microsoft team would be greatly appreciated.

New to microsoft fabric- time intelligence.

Anj_il_a- — Sun, 26 Jul 2026 17:53:13 GMT

Hello everyone! I'm new to microsoft fabric and Real -Time Intellligence. I am excited to learn how the real time data processing

works and look forward to learning from this community.

I am beginner to microsoft fabric . So as a beginner with basic programming knowledge, what are the best beginner resources to start learning Real-Time Intelligence?

I hope you will favour me....

Fabric Eventhouse: Capacity policy for .ingest inline is hard-capped at 1 concurrent operation

hal-apeno91 — Thu, 23 Jul 2026 11:24:09 GMT

Problem

When using the KQL Activity in Fabric Data Pipelines to execute .ingest inline commands against an Eventhouse KQL database, the effective ingestion capacity is always 1 concurrent operation — regardless of the Fabric capacity SKU (tested on F2 and F8) and regardless of the cluster capacity policy setting.

Running .alter-merge cluster policy capacity with ClusterMaximumConcurrentOperations: 16 succeeds without error, but .show capacity still reports an effective ingestion capacity of 1.

Any pipeline pattern that executes .ingest inline within a parallel ForEach immediately hits 429 TooManyRequests / ControlCommandThrottledException errors. Highlighting that the capacity is 1.

This makes the KQL Activity (KustoQueryLanguage type) unusable for parallel ingestion scenarios — which is an important use case in data pipelines (logging, event emission, watermark updates during parallel table processing).

Question / Request

Do you recognize this issue? if so I have the below request:

Increase the effective ingestion capacity for Fabric Eventhouse to match what the capacity policy allows (respect ClusterMaximumConcurrentOperations)

Activator + Fabric deployment: Not possible to parametrize triggered pipelines.

Tsubasanut — Thu, 23 Jul 2026 11:21:39 GMT

Disclaimer: I used ChatGPT to help me compile the message, but the problem itself was found and tested by me.

I’m seeing inconsistent behavior when deploying Activator items across Fabric deployment pipeline stages.

Scenario

We have a standard three-stage setup:

DEV workspace
TEST workspace
PROD workspace

Each workspace contains:

a Lakehouse used as the event source
an Activator item
a Fabric Pipeline used as the action target

The intended flow is:

A folder/file is created in the Lakehouse.
Activator receives the OneLake/Lakehouse event.
Activator triggers the Pipeline in the same workspace/stage.

So the expected behavior is:

DEV Lakehouse event → DEV Activator → DEV Pipeline
TEST Lakehouse event → TEST Activator → TEST Pipeline
PROD Lakehouse event → PROD Activator → PROD Pipeline

UI confusion

Firstly, the Activator UI can show the action target workspace as if it is correct. However, runtime behavior shows that the underlying workspace/item references are not consistently remapped.

I also found a difference depending on how the rule is authored:

If I create the activation rule from the Pipeline side, Fabric creates an event/action configuration that appears to remap correctly during deployment. So the Activator in DEV workspace points to pipeline in DEV workspace, and rhe Activator in TEST workspace points to same pipeline in TEST workspace
If I create an equivalent rule directly from the Activator UI, the workspace text in Action-Fabric item is not changing after deployment. So the Activator in DEV workspace points to pipeline in DEV workspace, and rhe Activator in TEST workspace also points to pipeline in DEV workspace. However, when event happens, the pipelines are executed in different workspaces.

So two visually similar Activator rules appear differently in the UI, while behaving the same way.

Activator content

At first, I created one event. But then I found out, that event source cannot be remapped during deployment. So DEV Lakehouse will always be a source for the event in all 3 workspaces.
Therefore, to test how Activator behaves across stages, I created one event for each physical Lakehouse: DEV, TEST, and PROD. The expectation was not that the event source itself would be remapped, but that the action target would remain correctly associated with the corresponding Pipeline for that event/stage.

Observed behavior

I created a test Activator containing three events/rules: one for the DEV Lakehouse, one for the TEST Lakehouse, and one for the PROD Lakehouse. Each event/action was intended to trigger the corresponding Pipeline in the same workspace.

After deploying the Activator, Pipeline, and Lakehouse through the deployment pipeline, the runtime behavior was inconsistent:

Creating a folder in the DEV Lakehouse triggered three pipeline runs, one in each workspace.
Creating a folder in the TEST Lakehouse triggered three pipeline runs, two in TEST and one in PROD.
Creating a folder in the PROD Lakehouse triggered three pipeline runs, all in PROD.

This creates a serious CI/CD risk.

If an Activator definition contains event sources from multiple stages, those source subscriptions appear to remain fixed after deployment. Then, depending on how action targets are autobound, a single Lakehouse event can trigger multiple deployed Activators and run Pipelines in unexpected workspaces.

For example:

a DEV Lakehouse event can trigger TEST or PROD processing
a TEST event can trigger PROD processing
multiple deployed Activators can react to the same physical OneLake event

This is not safe for deployment pipelines.

Rule conditions and parameters cannot solve the issue at the moment

I tried to use Activator rule conditions/action parameters to guard against this. However, all available fields appear to come only from the source event payload:

source
subject
time
id
type
data.url
data.blobUrl
data.requestId
data.clientRequestId

I do not see any way to reference:

current Activator workspace
current Activator item ID
current deployment stage
target action workspace
target Pipeline workspace
Fabric Variable Library values

Because all deployed Activators that subscribe to the same physical OneLake event see the same event payload, rule conditions cannot distinguish “this Activator belongs to this workspace” unless some environment-specific value is manually patched after deployment. Same for the triggered artifacts - they have no idea which Activator (DEV, TEST or PROD) was used for triggering.

Suggested fix from Microsoft

Making Activator event/action references deployment-safe. Either by adding deployment rules to Activator class, exposing more runtime context to the Activator, or making triggered artifacts aware about Activator itself.

Also, the Activator UI should not show an apparently correct target workspace if the runtime binding is different.

Current workaround

The only safe workaround I can see is to avoid deploying similar Activators altogether, or patch Activator references after deployment.

I would glad if someone could offer another solution to this problem of mine.

Fabric Mirrored Database Change Feed Eventstream source connector stuck in a restart loop

philhansen — Wed, 22 Jul 2026 14:56:46 GMT

I tried using the database change feed with EventStream to trigger a notebook on changes, but ran into a problem. Has anyone else successfully used the change feed with an EventStream? Any advice on solving the error below?

We built open mirroring (Mirrored Database) → Delta Change Data Feed → Eventstream

Mirrored Database Change Feed source → Filter operator (keep specific table) → Activator.

The Change Feed source connector repeatedly logs, in the Eventstream Runtime logs:
Warning Validate connector: '<connector-id>'.
Warning Connector runtime config validation is unhealthy. The connector will be restarted.
Failed reason: Connector validation failed, please retry the request.

This recurs several times per hour. Because each restart appears to re-read from the snapshot rather than resume from a committed offset, the stream is continuously flooded with duplicate read events, all carrying the same (latest) EXPORT_TIME, arriving hours after the source batch was actually processed.

2026-07-13 03:59:39 — "Connector runtime config validation is unhealthy. The connector will be restarted."
2026-07-13 11:18:16 — "Failed reason: Connector validation failed, please retry the request."
2026-07-13 11:20:07 — "Connector runtime config validation is unhealthy. The connector will be restarted."
2026-07-13 12:19:35 — "Failed reason: Connector validation failed, please retry the request."
2026-07-13 12:21:15 — "Connector runtime config validation is unhealthy. The connector will be restarted."

Streaming Architecture

binitafulpagare — Fri, 17 Jul 2026 04:06:22 GMT

Hi everyone,

I'm exploring Microsoft Fabric Real-Time Intelligence and would love to understand how it's being used in enterprise environments.

Which business scenarios have benefited the most from real-time analytics?

How do you balance:

Low latency
High throughput
Cost
Scalability
Reliability

I'm interested in learning from real production implementations.

Thank you!