Change Email Phone Number Applet

Four self-service pages that change or add the e-mail address or mobile number a person signs in with, reached from the profile screen or a mobile app rather than installed from a catalogue. A change takes two codes, one sent to the address or number the login already holds and one to the new one, and only then does the sign-in identity change; an address or number another login already uses is refused when you request its code.

Overview

This applet is four self-service pages, not a console: change e-mail, change mobile number, add e-mail (for a login that only has a mobile number) and add mobile number (for a login that only has an e-mail). Each one walks the user through a verification code sent to the identity they already hold, then a second code sent to the new identity, and only then changes the login principal. It has no menu, no listing and no settings — the CoreComponent is a bare <router-outlet>.

It is registered as ROOT-ADMIN, but it is not an administrator’s tool: the backend accepts the request from the user whose login is being changed, or from someone holding a tenant-owner / admin or user-profile-owner / admin permission. It is not installed from a catalogue: users reach it from the profile screen or from a mobile app.

Where it fits

Screens and menus

Four screens:

Each address box only enables Submit once you leave the box, because the check runs when the value changes, not as you type. Once you have submitted an address it is locked for that attempt and there is no Resend button: if a code does not arrive, reload the page and start again, which sends a fresh code. On success the page shows a confirmation and returns to Step 1; it does not take you anywhere else.

Configuration

Before you can use it

• You must be signed in. Opened without a sign-in, the page sends you to the login screen. (A mobile app can open it with its own access credentials instead.)
• Whose login is changed. Normally your own. Someone holding MST_TENANT_OWNER, MST_TENANT_ADMIN, MST_LOG_USER_PROFILE_OWNER or MST_LOG_USER_PROFILE_ADMIN can change another user’s e-mail or mobile number. Grant those permissions with that in mind: the e-mail and mobile number are how a person signs in and recovers the account.
• Branding follows the website the page was opened for; otherwise, the address it is served from.

Applet settings

None. The applet has no settings route, no personalization route, and reads no applet setting.

Settings in other applets that control this applet

None found.

Feature visibility / permissions

The applet has no client-side permissions; nothing is gated client-side.

Fields

What the boxes do not tell you:

• The current address is matched exactly, capitals included. If Submit is refused with Invalid email, try it in lower case: an address set through these pages is stored in lower case with spaces removed. A current address that belongs to a different login than the one being changed is refused with Invalid subject guid.
• The new address is checked against every login, not only yours. One that another login uses, or that is waiting on an unconfirmed sign-up, is refused when you press Submit on it, before any code is sent (see Troubleshooting for what the screen actually says).
• Each code is six digits and stays valid for up to six hours. An older one is refused with a plain Please try again; start again for a fresh code.

Lifecycle and effects

A change takes two verifications: a code sent to the current e-mail or number proves the request is yours, and a code sent to the new one proves it reaches you. Only after the second does the login’s sign-in identity change. A new address or number that another login already uses is refused when you request its code. Add Email and Add Mobile Number need only the second verification.

What happens on the second code, none of which the screen shows:

• The old address stops signing in at once. The new address is added to the login and the old one of the same type is marked deleted in the same step, so the old address is also free from that moment for any other login to register. Changing back later is an ordinary change, with two codes again.
• The change is copied into every tenant the login belongs to. BigLedger queues a background job that, in each linked tenant, updates that tenant’s copy of the login, the e-mail or phone on every person-type (individual) entity record linked to the login (the record a customer or supplier is kept on), and any membership card linked to the login. It also updates the contact key of every entity linked to the login, company-type ones included, although a company record itself keeps its own address; whether that is intended is an open question with the product team. So if a customer record shows the new address and nobody edited it, this is why.
• Nothing else follows. E-mail addresses typed on documents, delivery details and contact persons that are not linked to the login keep the old value.

No stock or journal effect.

Related applets

• Platform SysAdmin — where an administrator sees a login’s principals (User → Edit).
• Tenant Admin Applet — tenant-side user administration.

Troubleshooting

Several refusals reach the screen as the same general message, so the message alone does not always say which one you hit:

Related documentation

• Platform applets — the section hub.