Improve Releasing an Email Address workflow

Request for comments

Need

A recent ticket raised a few questions of process around Releasing an Email Address.

The end user (non-paid) lost access to their account and was requesting the release of their secondary email address in order to setup a new account using it.

There were a number of stumbling blocks encountered whilst attempting to follow the workflow. Before trying to tackle changing the workflow itself I wanted to gather thoughts/comments on the challenges faced below:

From the workflow:

  • Confirm that the email address the user is trying to add exists on a different account.

It doesn't, it exists on the account the user cannot access.

  • Verify that the account shows no activity and is not a member of any projects or groups.

Additionally, confirm that the following are true:

  • The user is unverified
  • The user has never logged in
  • The user has no data (No groups or projects)

In this case, the account DOES have activity (but not in the last two years), they are a member of projects/groups and the user is shown as having logged in. Their account however remains 'unverified/unconfirmed' and they no longer have access to the primary (unconfirmed) email address on the account, so they can't request a password reset, nor can they use email swap as they are unverified.

Our Name Squatting Policy however makes the following distinction:

  • What constitutes data in the account?

    A group, a project, etc. means data. Unless the project or group is empty, or there's been no activity for 2 or more years.

So can/should the same not be applicable to email release?

  • Add the new email address as a CC to the ticket and ask the user to respond to the ticket from the email address they wish to add.

The user has already reached out via the secondary email address on the account so this doesn't apply. Same for step 4.

So the questions are:

  • Should the definition of no activity in this workflow be expanded to the same definition for name squatting?
  • Do we need to consider secondary email address any different to primary for the purposes of this workflow?

Approach

  • Expand no activity definition to match that of the name squatting workflow
  • Re-word the workflow to provide better provision for handling requests directly from an email on the impacted account (account from where the email will be removed)

Benefit

  • No ambiguity
  • Avoid management approval
  • Smoother process for the end user

Competition / Alternatives

  • Do nothing and endure copious head-scratching when the same situation arises