The login/link process is confusing and broken, and needs significant improvement

Michael Crawford 1 Reputation point

I am trying to setup an account to take multiple Azure certification exams. I created an account on with my "work" email address. However, when I went to associate this with my personal address, all I would see is a brief flash of what looked like a multi-account select dialog when I login to or have other needs to signing, but with no text, then it failed due to some error and returned me to the same page. I was not able to associate any additional work or personal accounts. This definitely looked like an unhandled login condition in the code.

Let's start with that, but there are a few more conditions, which I think show this login/association logic is not fully baked.

I have THREE M365 organizations, which I'll reference as the following:

  1. = = my employer, where I "work", which you consider a "work" account
  2. = = my personal & family set of email addresses and calendar, which I migrated from GSuite Legacy two months ago, and setup with AWS SSO, email groups, and calendaring for my family and personal/work use and training, which I consider to be my (ONLY) personal email address (which I've used for 25+ years), but which you apparently consider to be a "work" account.
    1. = = an open source project, which I've setup for email, security groups, distribution groups and SSO integration with AWS control tower and other accounts.

So, when I open, to manage my M365 organizations, I see a list of 3 login options, which may or may not be signed in. I have to pick the one I want to use, I can switch between them. This MOSTLY (but it's often flaky) works to pick and let me manage the correct organization.

I'm just now starting to use to use Azure. I've already seen this get confused and add a free account intended for tenant to the companydomain tenant, despite the fact I was not logged into the latter and had the page up for It's clear this logic has bugs from that experience.

What's hitting me now, is that I want to take some tests and am prevented from doing so, because your design has apparently not anticipated the fact some of us sophisticated users have our personal email address on what you consider to be a work domain, meaning it's on, and that means that ALL email addresses go to the login system, not the login system.

I have no other personal email address other than an old personaldomain@Stuff .com email address, which is my backup/recovery email address. It's not on the system, and I don't really want it there.

Everywhere else, for decades, I've used myname@bugtibaloch as my personal email address. It's tied to my AWS training, my Terraform training, my GitHub and GPG identities, etc. I want all my personal certifications to be tied to this email address. But, it seems the esi system did not anticipate this use case. YOU NEED TO FIX THIS.

You should not have some special division between what you consider a work vs personal email address which is not always going to be represented by your customers. We should be able to associate multiple email addresses, and treat any of them as the "primary" or "personal" (from our perspective) email address which is our personal identity and which certifications and training progress is tracked against.

In the meantime - HOW do I fix this? I can't attach ANY account, I'm not even given a choice due to this bug. I want to make one of what, from your perspective, is a work account email address as the email address associated with my training and certifications. Please tell me how I do this.


Not Monitored
Not Monitored
Tag not monitored by Microsoft.
37,117 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Dave Patrick 426.3K Reputation points MVP
    0 comments No comments