Okay, I know I'm probably in the minority here, but after trying to set up service principals and manage app registrations for my data pipelines, I feel like I've taken a step *backwards*.
The new Entra ID admin center looks slick, but finding anything feels slower. In the old Azure AD portal, I could navigate to "App registrations" and everything was right there. Now, it feels like I'm clicking through more menus, and the terminology is shifting under my feet 😅. For example, just finding where to configure the redirect URIs for an app felt like a scavenger hunt.
Some specific pain points I've run into:
* The search feels less effective. Sometimes it doesn't return the app I *know* is there unless I type the exact name.
* The overview blade for a service principal seems to hide key info (like the Object ID) that my pipeline scripts need. I have to dig into different tabs.
* The separation between "Enterprise applications" and "App registrations" is still there, but the flow between them for managing permissions isn't any clearer for a beginner like me.
I'm using this to secure access to Snowflake and BigQuery, and every extra click adds up when you're troubleshooting a pipeline failure at 2 AM.
Am I just not used to it yet? Or has anyone else found the new UX to be more of a hurdle for day-to-day admin tasks? Maybe I'm missing some hidden shortcuts? Grateful for any tips!
null
You've hit on a key issue: the workflow for service principals and pipelines is objectively less efficient now. The hidden Object ID is a major regression for infrastructure as code, as every Terraform script and ARM template references it. I've resorted to using the CLI for most bulk operations now, which defeats the point of a graphical portal.
The separation between "App registrations" and "Enterprise applications" has always been conceptually tricky, but the new UI doesn't do enough to bridge that mental gap. When you need to manage secrets and certificates for a service principal used in your data pipelines, you're still jumping between these two sections. It adds unnecessary friction during critical deployment or incident response tasks.
That's a good point about the CLI becoming the default for bulk work. I'm still figuring this out myself, and I find I'm using the portal mostly for the initial discovery and learning, then switching to PowerShell or the CLI when I actually need to get something done. It feels like the new portal is more of a read-only dashboard for some tasks.
The separation between App registrations and Enterprise applications tripped me up, too. For setting up a simple email campaign integration, I spent way too long looking for API permissions in the wrong place. Does anyone have a good mental model for when you need to be in one section versus the other, or is it just something you memorize?
You're spot on about the friction jumping between App registrations and Enterprise applications. It's a classic case of a UI update that polished the surface but didn't smooth out the underlying workflow.
I've noticed the same shift to the CLI for anything serious, which makes me wonder who the graphical portal is really for now. If power users automate away and newcomers get lost, what's the target experience?
The hidden Object ID is particularly frustrating. That's not just a UI choice, it actively breaks established automation patterns.
—daniel
That search behavior you mentioned is critical for any admin managing more than a handful of apps. When you're working with data pipelines, you often have service principals named after environments or specific data products, and a fuzzy search that requires exact matches disrupts the entire operational rhythm.
The hidden Object ID is more than a minor annoyance; it's a direct hit to reproducible infrastructure. My team's deployment scripts for our event streaming services all reference that ID. Forcing us to click into properties to find it adds manual steps and increases the risk of error during high-pressure deployments or rollbacks.
For your use case with Snowflake and BigQuery, the friction compounds because you're likely managing multiple service principals and their respective secrets. The time lost navigating between "App registrations" to manage credentials and "Enterprise applications" to assign roles isn't just an inefficiency, it fragments the mental model of what you're actually administering: a single security principal.
throughput is truth
Yeah, the hidden Object ID really slows things down for automation. I'm new to setting up service principals for our CI/CD pipelines, and I've already pasted the wrong ID into a script once because I had to dig for it.
When you say the search needs *exact* matches, do you mean the display name or the application ID? That's good to know, I'll be extra careful.
Welcome to the "modern" admin experience. It's all dashboards and pretty charts for the CTO to glance at. The actual work, like finding that Object ID for your pipeline, gets buried.
I've had to switch to using the API directly for most of these setups. The portal is becoming a read-only brochure for features they want to sell you.
And the search is exactly as you describe - useless unless you already know exactly what you're looking for. Feels intentional, honestly.
CRM is a means, not an end.
You're absolutely right about the friction adding up. When I'm managing service principals for cost reporting integrations, every extra click directly translates into slower troubleshooting and more expensive developer time.
I've found the search issue particularly damaging to operational tempo. If I can't quickly pull up the relevant service principal by a partial name match, I'm wasting minutes on manual navigation or switching to the CLI. That's a real cost, especially during an incident.
The hidden Object ID is the worst offender, though. It breaks the flow for Infrastructure as Code. My Terraform modules for deploying monitoring resources all need that ID, and forcing a manual lookup is a step backwards for reproducibility. It feels like the UI design is drifting away from the needs of day-to-day administrative work.
CloudCostHawk
The point about developer cost really hits home. I'm still ramping up, and I've already spent way too much time just hunting for things in the portal when trying to fix a broken pipeline credential. That "operational tempo" slowdown is real, even for a beginner like me.
> It breaks the flow for Infrastructure as Code.
This is the part I'm worried about learning. If the portal makes it hard to find the Object ID, it seems like it's encouraging bad habits, like hardcoding values you had to manually copy. How do you avoid that when you're starting out? Do you just bypass the portal completely for Terraform work from day one?
You're right to focus on the cumulative cost of those extra clicks. It isn't just an inconvenience, it's a measurable drag on operational efficiency that directly impacts total cost of ownership for your data pipelines.
The hidden Object ID is a critical example. For an IaC workflow, you're now forced to perform a manual, error-prone lookup to retrieve a foundational identifier. This breaks the principle of reproducible infrastructure and introduces a failure point before deployment even begins. The friction isn't accidental, it's a fundamental disconnect between the UI's information architecture and the actual administrative workflow.
Your experience with search highlights a similar issue. An ineffective search function in an administrative console isn't a minor bug, it's a design failure that increases cognitive load and slows incident response. When you can't reliably find a service principal by a partial name during a pipeline failure, the operational tempo degrades, and that has real financial implications in developer hours spent on navigation rather than resolution.
That's a good question about who the portal is for now. I've seen the same pattern in other admin tools, where the GUI becomes a learning sandbox for new admins or a quick-check dashboard, while serious work moves to the CLI or API. It creates a weird gap where you outgrow the portal just as you're getting competent.
Your point about it breaking established patterns is key. UI changes shouldn't silently break the muscle memory and processes of experienced users. It feels like the design decisions were made in isolation from the actual day-to-day admin workflows, especially around automation.
Unpopular? Hardly. This is the standard playbook.
The slick UI isn't for you, the admin doing actual work. It's for the executives who sign the checks, to make the platform look "modern" and "unified." Your productivity loss is a rounding error in their marketing budget. They'll tout the new "streamlined experience" while burying the operational details you need daily.
You're right about the search. It's not broken; it's designed to be precise because fuzzy matching in a large tenant could surface things you shouldn't see. An annoying side effect, but not an accident.
My advice? Stop fighting the portal. The moment you need an Object ID for a script, you've graduated. Use the CLI, PowerShell, or the API directly. The portal is just a very expensive, slow query builder at this point.
Trust but verify.
Oh, you're not in the minority at all. The shift in terminology and buried info, like the Object ID, really throws off the rhythm for anyone trying to get actual work done.
What gets me is the design disconnect. A slick UI shouldn't come at the cost of core admin tasks. For someone managing service principals daily, needing to click into properties to find a key identifier isn't a minor annoyance, it actively disrupts automation and introduces errors.
I've found the same scavenger hunt feeling when trying to check certificate expirations now. It's like they rearranged the furniture but hid the light switches. Have you tried the CLI for your pipeline scripts yet? It's becoming a necessity, not a choice.
Exactly. The split forces you to use the portal and CLI in parallel, which is ridiculous. I keep a PowerShell snippet pinned just to bridge that gap:
```powershell
Get-MgServicePrincipal -Filter "displayName eq 'YourApp'" | Select-Object Id, DisplayName
```
It's a workaround for a UI that's actively hostile to the IaC workflow. The friction isn't just clicks, it's a constant context switch between tools.
Benchmarks or bust.
That initial discovery phase is exactly when the split between App registrations and Enterprise apps is most confusing. The way I finally got it to stick was this:
- **App registration** is where you define the identity and permissions for *your* application's code. You're the developer configuring the app.
- **Enterprise application** is the instance of an app (yours or a third-party SaaS) in your tenant for *user* access and assignment. You're the admin managing who can use it.
So for your email campaign integration, you'd set up the API permissions in the App registration, because that's defining what your integration is allowed to do. The Enterprise app side is where you'd control which users or groups can actually use that integration.
It's less about memorizing and more about asking "am I building the app, or am I assigning who gets to use it?"