Your account

Your account is you, not your workspace. The address you sign in with is unique to the person, and a membership joins that one person to each workspace they belong to — so somebody in three workspaces has one password and one sign-in address, not three. Everything on this page follows you into every workspace you are a member of.

None of it is workspace administration, and no role is refused any of it.

Where it is

Open the profile menu in the top right — your name and avatar — and choose Account and security. That is the only route to it from inside the app, and it is also in the menu for a read-only external approver, for whom that menu is the whole navigation. No email we send carries the URL.

The screen has two tabs:

Profile — the name your team and your audit trail see.
Security — your password, and the address you sign in with.

Before you start

You have to be signed in. This screen proves who you are from your live session, so it is no help if you cannot get in at all. The last section on this page is for that case.
You need your current password. Both changes on the Security tab begin by checking it, the email change included.
Your account has to have a password. An account created through a social sign-in has none, so neither form is drawn and the screen says why instead of showing a field that can never be satisfied.

If the screen says this session cannot change your password or your address, sign out, sign in again and open it once more. If it still says that, we are having trouble reaching the service that holds your sign-in, and nothing you type will help until that clears.

1. Open Account and security

Profile menu, top right, Account and security. Open the Security tab.

You should be looking at two forms: one to change your password, one to change the address you sign in with. If you see a notice instead of the forms, read the section above — the account, or this session, cannot use them.

2. Change your password

Type your current password, then the new one twice, then submit.

inletAP states no password rules — no minimum length, no character classes, no strength meter. That is deliberate and it is not laxity: the policy is held and enforced by the service that holds your sign-in, and a second copy of it written into this product would be wrong the first time the real one changed. When a password is refused, the sentence you see is that service's own, printed against the new-password field.

The submit button is never disabled because of what you typed. It is disabled only while the request is in flight, so a password manager that fills the fields without your keyboard cannot leave you pressing a dead control.

What you should now be looking at. The form is gone, replaced by a sentence confirming the change. That is not cosmetic — a browser only offers to update a saved password once the form has left the page.

The sentence says one of two things, and the difference matters:

Your password is changed, you are still signed in here, and every other device has been signed out.
Your password is changed, but we could not sign your other devices out — so sign out of them yourself if you can.

We say which one happened rather than claiming the better one. Somebody changing a password because it was stolen needs to know whether the thief was actually put out.

3. Check that it is recorded

Open the Audit Log and look for Auth Password Changed, against your name, at the time you did it. When the other sessions were ended, Auth Sessions Revoked sits beside it.

A refused attempt is written too, as Auth Password Change Failed, and that is the real reason to look. A successful change looks identical whether the hand on the keyboard was yours or a thief's; the wrong-password attempts before it are the only signal there is. No audit row carries a password, a hash, or any part of one.

What happens to your sessions

A password change stamps your account with the time it happened. Any session opened before that stamp is destroyed the next time it is used, on every device and in every process — so "signed out everywhere" means the other sessions stop working, rather than a screen going blank in somebody's hand a second later.

The session you changed it from is spared, deliberately. Being signed out by your own action, at the moment you are most likely to think something has gone wrong, is the worse outcome.

Changing your email address does not do any of this. Your other sessions survive it, because the address moved and the credential did not.

The routes that take your current password allow ten attempts every fifteen minutes, counted per network address rather than per account — so an office behind one address shares that budget, and a colleague fumbling their own password can make you wait. Every refused attempt is in the audit trail either way.

Changing the address you sign in with

Also on the Security tab, and it is a two-step flow rather than a field you edit.

Type your current password and the new address, and submit. A code is sent to the new address.
Read the code from that mailbox and type it back in.
Submit. The address moves.

The code is the point of the flow. Your email address is how you sign in, so an address you cannot read is a locked account: one typo, confirmed without a check, and nobody can let you back in. Proving you can read the new mailbox before the change commits is what makes that mistake impossible. The current password is asked for separately, and for a separate reason — without it, an unattended laptop with a live session is a stolen account in two clicks.

While the change is pending:

You still sign in with your current address. The screen keeps showing it, and says so.
The code is good for ten minutes, counted down on screen against the deadline the server sent rather than a guess made in your browser.
A new code can be sent after a minute.
Cancel change abandons it, and asks for nothing — cancelling gains an attacker nothing.
A mistyped code costs you one retry, not the whole flow. An expired one means starting again.

If the address already belongs to another account, you find that out at the code step rather than before. That is deliberate: a check earlier would let anybody holding a session ask this product whether an address is registered here, and read the answer off the response. The refusal is worded identically whether the address is taken or simply not usable, for the same reason.

What you should now be looking at. The Security tab shows the new address as the one you sign in with, and the pending-change panel is gone.

Check it, in two places. The Audit Log carries Auth Email Changed, with the old and the new address in full. And your old mailbox receives a notice — subject "The email address for your inletAP account was changed" — saying when it happened and showing the new address partly masked.

Nothing can switch that notice off. It is not one of the seven email notifications and no preference silences it, because it is the one message that reaches somebody who has just lost their account. It carries no link and no button on purpose: training people to click a button in exactly that email is what credential phishing relies on. If you did not make the change, write to support@inlet-ap.com and include the message — it carries the date we need.

If you want a different address for one workspace only, changing this one will not do it. There is one address per person. Invite that address to the workspace as a member, and leave that workspace from this account.

Your display name

On the Profile tab, and it asks for no password. A name is not a credential: nobody signs in with it, and changing it cannot lock anybody out or let anybody in. A current-password field here would only teach people to type their password into forms that have no business asking for it.

It is still recorded, as Auth Name Changed. Your name is copied onto each audit entry as that entry is written, so the trail holds the name you had at each moment; without the rename in it, two rows months apart would read as two different people.

What an administrator can and cannot do

An administrator of your workspace cannot:

change your password,
change the address you sign in with,
change your notification switches,
sign you out.

There is no route in this product that touches anybody else's credentials, for any role. That is the deliberate shape of it rather than a gap: a person locked out of their own credentials cannot respond to a stolen password, and that is the one emergency they have to be able to handle without waiting for somebody else. It is also why a read-only external approver — not the customer's employee, and unable to raise a ticket with the customer's IT — has this screen at all.

What an administrator does control is your membership of their workspace: inviting you, your role in it, and removing you. See roles and permissions.

If you are locked out

This screen cannot help you, because reaching it needs the session you have not got. Nor can your administrator, for the reason above.

inletAP itself stores no password. There is no password column anywhere in its database, the credential lives with the service that holds your sign-in, and the only thing kept here is the date you last changed one. So there is nothing for anybody to reset on your behalf by hand.

Write to support@inlet-ap.com from an address we can recognize — your sign-in address, if you still read it — and say which workspace you are in.

The same applies if you sign in without a password and want one. Setting a first password is not something this screen can do yet, and it says so rather than offering a form that cannot work.