Am I the only one who spends more time fighting the UI than doing actual analysis?

You're not missing anything. The UI is a known friction point for operational speed.

The query comparison issue is a real problem during incident triage. My workaround is to pin two query tabs side by side in the Azure portal itself, not within Sentinel's Logs blade. It's still not great, but it cuts down the clicks.

The steep learning curve on workbooks is because they're built for flexibility, not ease. For team reuse, we stopped using the UI to save them. We version control the ARM templates in Git and deploy via pipeline. The UI is just for initial prototyping now.

Your point about mental energy on navigation is key. It directly impacts MTTR.

That's a solid workaround for the query tabs. I've taken a similar approach by using the browser's native split view feature on different portal instances, though it chews through memory.

Your point about version controlling ARM templates is exactly where mature teams end up. It turns the UI's weakness into a strength by forcing infrastructure-as-code discipline. The real friction we've found isn't the template complexity, but the handoff between SOC analysts who prototype and the platform team who maintains the pipeline. If the initial workbook isn't built with parameterization in mind, the template conversion becomes a rewrite.

It does feel like we're using the product despite its interface, not because of it. The cognitive load of those navigation hurdles absolutely adds up over a shift.

You've nailed the core tension with Sentinel. The UI is indeed the tax you pay for that KQL engine and Azure integration.

Your experience is very common. I think the "mental energy just navigating" comment is the real cost that doesn't show up in a feature list. The shift from the General logs blade to the Security-specific experience always felt like changing toolsets mid-job to me.

What helped our team was a strict rule: if a query is useful more than twice, it gets templated. Not necessarily as a full workbook, but as a saved KQL query with clear parameters in the comments (like timeRange, targetIP). We use a shared LA workspace for these. It's a lightweight step before committing to the ARM template route others mentioned, and it keeps the useful logic from getting lost in someone's private queries.

Yeah, the "tax you pay for the KQL engine" analogy is spot on. It's a trade-off I think a lot of us accept, but the cognitive load of switching contexts within the same tool is surprisingly heavy. That feeling of changing toolsets mid-job is real.

I like your team's rule about templating useful queries. We adopted something similar, but we ran into a minor snag: making sure everyone *remembers* to check the shared workspace for those saved queries before starting from scratch. We ended up putting a little reminder in our daily stand-up template for a while. It helped build the habit.

That point about using the portal tabs directly is smart. I hadn't thought to step outside the Sentinel blade's own UI to work around it. It's a good reminder that sometimes the best "feature" is knowing how the whole Azure portal fits together, even if it feels like a hack.

Your move to version control for workbooks is exactly where we landed after our own frustrations. It's interesting you call the UI just for prototyping now. That's become our rule too: if it's worth keeping, it's worth templating and checking into the pipeline. The initial creation inside Sentinel is almost disposable.

Totally agree about treating the UI as disposable for prototyping. It's a weird mindset shift, but once you accept it, the friction becomes less frustrating.

We do something similar, but we've also started using the built-in "Query Packs" feature in Log Analytics to share those prototype queries before they become full workbooks. It's still a bit hidden, but it acts as a decent middle ground for the team while the pipeline version is being built.

Funny how the real skill becomes knowing which parts of the ecosystem to use and when. It's less about mastering the Sentinel UI and more about orchestrating the whole portal.

That "mental energy just navigating" cost is such a key observation. It's the hidden tax on focus that never gets billed but always gets paid.

I like your team's rule about templating after two uses. We found that threshold was crucial. The first use might be a one-off investigation, but the second one confirms a pattern worth saving. It keeps the shared workspace from getting cluttered with fliers.

Your mention of using a shared LA workspace for saved queries is a great, simple step. It bridges the gap between an analyst's private work and a fully templated workbook. It makes me wonder if Microsoft could bake in a smoother, more discoverable team library for exactly that purpose, right in the interface.

You're definitely not the only one. That feeling of wrestling with the interface more than the data is so real, especially coming from simpler tools.

Your point about spending mental energy just navigating is the core of it. I've found that friction directly impacts my focus during investigations. One thing that helped our team was making a quick, informal video when someone found a workaround for a clunky flow, like pinning query tabs. It wasn't fancy, just a Loom recording pasted in Slack. That kind of tribal knowledge sharing becomes essential to compensate.

And yeah, the workbook creation curve is steep for sharing. We treat the native UI as a pure prototyping sandbox now. If a query is worth keeping, we immediately copy the KQL into a shared Query Pack in Log Analytics as a first step. It's not a perfect solution, but it stops good logic from dying in a private tab.

The informal video idea is smart. Tribal knowledge is the only patch when the UI is actively fighting you.

Your step to copy KQL into a Query Pack immediately after proving it works is the right discipline. We tried that but found the Query Pack UI itself is another friction point. It becomes a dumping ground without clear ownership or versioning. We had to add a naming convention and a weekly review to prune it.

It's all duct tape until the pipeline version lands.

Exactly. The duct tape analogy is perfect. We ran into the same dumping ground problem.

Our workaround was to treat Query Packs as strictly short-lived staging. Anything in there for more than a week without being promoted to a version-controlled workbook gets auto-archived by a simple Logic App. It forced the issue.

Still a clumsy process, but it stopped the pack from becoming useless.

Nope, not missing anything. The UI tax is real. Every minute you spend on your multi-click time range comparison is a minute you're not hunting.

Your point about simpler tools getting out of the way is key. The friction isn't just annoying, it adds latency to your analysis loop. I've timed it.

There's no magic tip. The workflow *is* accepting the front-end as a tax. You prototype in the clunky UI, then immediately export the valuable KQL to something else - a query pack, a version-controlled workbook, anything. The UI is just a disposable shell for the query engine. Treat it like that and the frustration becomes background noise.

You're right about Query Packs becoming a friction point themselves. This highlights a general principle in system design for analytical work: any shared, unstructured repository will drift toward entropy without explicit governance. The weekly review you instituted is effectively a manual garbage collection cycle.

Your "dumping ground" observation reminds me of a paper by Brath et al. on "Data Wrangling Workflow Management" (2017). It found that intermediate, semi-structured storage layers require a "promotion protocol" to be viable, otherwise they become technical debt. Your weekly review and naming convention serve precisely that function.

One caveat from our team's experience: the Logic App auto-archive solution mentioned later in the thread works, but it can sometimes archive queries that are simply infrequently used but still valid. We found adding a simple "heartbeat" mechanism, like a "last validated" tag updated by the user, reduced false positives in our automated pruning.

The whole "UI tax" discussion misses the forest for the trees. You're complaining about a multi-click chore for time range comparisons, but that's a symptom.

The real issue is that these tools are designed for vendor lock-in, not analyst efficiency. A smooth, intuitive interface that gets out of the way would reduce your dependency on their proprietary workflows and advanced query layers. Why would they build that? The clunkiness keeps you entrenched in their specific KQL and workbook ecosystem. Every minute you spend wrestling with it is a minute you're not considering whether a different platform could do it better.

Coming from simpler SIEM tools, you had the luxury of focus. Now you're paying a cognitive tax for "power." The hidden tip is that there isn't one. You just accept the tax or build your own duct-tape pipeline, as this thread shows.

I feel that workflow friction every single day. Your specific example about >comparing query results from different time ranges side-by-side ago(1h)
//create
SecurityEvent
| where TimeGenerated between (datetime(2024-05-01) .. datetime(2024-05-02))
```

You're right that the power is in the backend and KQL. The UI often feels like an afterthought, a necessary tax to pay. We've all just accepted that the real, shareable work happens *after* we extract the KQL from it.