Expose OneLake Catalog and Monitor UI filters as explicit REST/API options

Today, some filtering experiences in OneLake Catalog and Monitor are primarily optimized for interactive UI usage.
However, for automation, operational tooling, and agentic AI scenarios,
it would be much more useful if these filter settings were also exposed as explicit and stable REST/API options.

At the moment, users often need to reapply the same filters manually in the UI.
This is inefficient, error-prone, and difficult to integrate into repeatable workflows.
It also limits the usefulness of AI agents, internal support tools, and operational scripts that need to reproduce the same scoped view consistently.

Requested improvement

Please make the filtering model used in the Fabric UI available programmatically, especially for:

• OneLake Catalog

  • workspace
  • domain
  • item type
  • endorsement / certification state
  • tags / metadata-based filters
  • security / governance-related filters where applicable

• Monitor

  • time range
  • status / result
  • workload / item type
  • user / operation
  • other commonly used filter dimensions already available in the UI

Why this matters

This would help with:

• repeatable operational investigations
• internal support workflows
• automation and scripting
• agentic AI / Copilot scenarios
• reducing manual and repetitive UI work

Expected outcome

Ideally, users should be able to:

1. define filters explicitly in REST/API requests,
2. save and reuse the same filter logic across tools and workflows,
3. reproduce the same filtered scope as the Fabric UI,
4. use these filters reliably in automation and AI-assisted experiences.

This would significantly improve consistency between the UI and programmatic access, and make Fabric much more usable for advanced operational and governance scenarios.