Activator Monitoring features

[evrise]

Hi, 

Activator UI display granual data about who updated it, when, and when event was triggered. 

May I access it in more programaticall way ? Via Fabric Monitor or Azure Log Analytics? 

I need to keep all those information  for audit somewhere else.

Thanks

[v-mdharahman]

Hi @evrise,

Thanks for reaching out to the Microsoft fabric community forum.

Its a great observation regarding the metadata shown in the Activator UI. At this time, the granular details like "who updated an event", "when it was updated", and "when it was triggered" are only surfaced in the Activator UI and are not yet exposed programmatically through Fabric Monitor, REST APIs, or Azure Log Analytics.

We understand the importance of having this level of audit detail accessible externally, especially for compliance or operational logging. While Fabric Monitor and Log Analytics provide insights for other Fabric activities (e.g., pipeline runs, dataflows, etc.), Data Activator currently does not emit telemetry or logs to these services.

That said, we’ve received similar feedback from other users, and audit logging support for Activator is something the product team is aware of. In the meantime, the best workaround would be manually capturing metadata from the UI or using custom logging in your action logic, if you're triggering external services via Power Automate or webhooks.

If I misunderstand your needs or you still have problems on it, please feel free to let us know.  

Best Regards,
Hammad.
Community Support Team

If this post helps then please mark it as a solution, so that other members find it more quickly.

Thank you.

[evrise]

Hi, Thanks. It would be nice to record this using custom logic. But its also impossible. Seems the product is still not production ready even its GA over year. 

Solved: Get parameters from Activator event - Microsoft Fabric Community

[v-mdharahman]

Hi @evrise,

You are right, there are some current limitations when it comes to auditing and event context extraction within Data Activator. While it's GA, certain enterprise-grade features like programmatic access to event metadata or logging hooks are still in development or under consideration based on user feedback like yours.

At the moment, you're correct that there's no way to extract event parameters or metadata directly from the Activator trigger itself, which does limit the ability to build robust custom logic downstream.

Also if you want to raise any points or issue towards developers I suggest Ideas forum. Here you can raise an idea or upvote for a pending idea. Go through the below link for Ideas Forum.

Ideas Forum 

Best Regards,

Hammad.

[v-mdharahman]

Hi @evrise,

As we haven’t heard back from you, so just following up to our previous message. I'd like to confirm if you've successfully resolved this issue or if you need further help.

If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well. If you find a reply particularly helpful to you, you can also mark it as a solution.

If you still have any questions or need more support, please feel free to let us know. We are more than happy to continue to help you.
Thank you for your patience and look forward to hearing from you.

[evrise]

No, We havent as there is no solution right now. 

[v-mdharahman]

Hi @evrise,

To achieve a robust and audit-compliant tracking mechanism, you can implement custom logging as part of the pipeline or notebook execution flow triggered by Activator. This approach provides full control over the audit data captured and retained.

Logging Strategy:

* Insert a logging step at the beginning of each pipeline or notebook.

* Then capture the following key metadata: 

Timestamp using utcnow() to record the execution time. Environment context, such as workspace name, pipeline name, and run parameters, using System.Environment variables or expressions like pipeline() (for pipeline metadata). Initiator details, including pipeline().RunId and any user metadata available via parameterization or triggering context.

Recommended Logging Destinations:

* Delta Table in a Lakehouse – Ideal for scalable querying and long-term retention.

* Azure Log Analytics (Custom Logs) – Enables centralized monitoring and alerting integration.

* Azure Storage (Blob/Table) – Cost-effective raw log storage.

* SQL Database Table – Useful for structured querying and downstream reporting.

By embedding this logging mechanism within the execution flow, organizations can ensure all Activator-triggered processes are traceable, auditable, and compliant with internal or regulatory monitoring requirements.

Best Regards,

Hammad.

[evrise]

No I can not. as the alert do not pass information to other triggered items. 
So no. there is no Solution right now. As somebody mentioned it is not Enterprise ready. 

[v-mdharahman]

Hi @evrise,
I just wanted to follow up on your thread. If the issue is resolved, it would be great if you could mark the solution so other community members facing similar issues can benefit too.
If not, don’t hesitate to reach out, we’re happy to keep working with you on this. 

Best Regards,

Hammad.