Establish Application Administrator

Introduction

The cleanest supported way is to make the canonical Production Application Administrator use the specific email you want, rather than creating another GLOBAL administrator.

ERS already supports this through the Production GitHub environment variable E2E_ADMIN_EMAIL. The deployment workflow defaults to e2e-admin@enterpriseremotesystems.com only when that variable is absent. The underlying authorization identity remains the canonical GLOBAL e2e-application-admin.

Recommended sequence

Set your desired Production administrator login:

gh variable set E2E_ADMIN_EMAIL \
  --env production \
  --body '<YOUR-ADMIN-EMAIL>'

For example, use the real email address you want to authenticate with rather than the generic e2e-admin@.... Then set/rotate its Production password:

gh secret set E2E_ADMIN_PASSWORD --env production

That prompts for the password without putting it into shell history.

Verify the email configuration: gh variable list --env production

You should see: E2E_ADMIN_EMAIL <YOUR-ADMIN-EMAIL>

You cannot retrieve the password secret afterward; GitHub only confirms that the secret exists. Then redeploy the production branch using the normal deployment workflow:

Then rerun the existing Production deployment workflow against the production branch:
gh workflow run deploy.yml \
  --ref production \
  -f environment=production

The provisioner will reconcile the existing canonical Application Administrator rather than create a duplicate.

What ERS will do

If the canonical Production administrator currently looks like:

Actor:
e2e-application-admin

Login:
e2e-admin@enterpriseremotesystems.com

Role:
APPLICATION_ADMIN

Scope:
*

and you configure: E2E_ADMIN_EMAIL=<YOUR-ADMIN-EMAIL>

the provisioner updates the existing Authentication Account approximately to:

Actor:
e2e-application-admin

Login:
<YOUR-ADMIN-EMAIL>

Role:
APPLICATION_ADMIN

Scope:
*

It also updates the password to the new E2E_ADMIN_PASSWORD and invalidates old sessions/password-reset tokens when credentials change. The implementation explicitly supports updating the login on the Authentication Account already bound to the canonical GLOBAL actor. This is preferable to creating another Application Administrator The provisioning command technically accepts arbitrary:

actorKey
displayName
login
password

But I would not create another GLOBAL APPLICATION_ADMIN actor just to obtain a personalized login. ERS's hardened model and deployment process are built around a canonical Application Administrator identity, and Bite 30K even introduced 000070_revoke_noncanonical_application_admin_grants. The deployment itself explicitly provisions e2e-application-admin.

So the better model is:

one canonical GLOBAL Application Administrator
                  ↓
specific real Production login
                  ↓
specific Production-only password

rather than:

e2e-application-admin
+
another-human-application-admin

One cosmetic issue With this method, the login becomes your chosen email, but the underlying Actor is still named internally: e2e-application-admin

and the deployment display name remains approximately: Production Automation Administrator

That isn't a security problem, but now that ERS is entering actual Production use, I think this is a legitimate housekeeping item: rename the concept from an “E2E administrator” to a canonical Production/bootstrap Application Administrator, while preserving the same one-GLOBAL-admin security model.

For your immediate need, however, no software patch is required. Set E2E_ADMIN_EMAIL, set E2E_ADMIN_PASSWORD, redeploy Production, and use those credentials.