Short answer

There's no self-serve "change email" button in the app — but you don't need to delete and recreate the user. Just email Civic.ly support with the old → new addresses and we'll change them in place on our side: same account, same history, same password, nothing to re-set up. For one address or a whole list, that's the quickest and safest route. (Deleting and recreating the user still works as a do-it-yourself fallback, but you lose the original account and have to re-invite — so it's the last resort, not the default.)

Detail

Recommended — ask us to change it (in place):

  1. Email Civic.ly support (or your usual contact) with each person's current Civic.ly email and the new email. A simple list is fine.
  2. We update it directly. Because the login is tied to the account itself (not the email text), the person keeps their existing password and all their history — they simply sign in with the new address next time. No invite, no password reset, no interruption.
  3. We confirm back when it's done. Good practice is to switch a non-critical user first and check they can log in before doing an admin's own login — we handle that ordering.

This is the right route when:

  • A staff member's email changes in a restructure or rebrand.
  • A user has been on a personal email and wants to move to a role-based address (or vice versa).
  • An account was set up with a typo in the email that wasn't spotted for a while (we can correct it the same way).

Fallback — do it yourself by create-and-delete (only if you can't wait for support, and you're an admin):

  1. Create the new user with the new email, same role/permissions as the old one.
  2. Send the invite / verification to the new email and complete setup.
  3. Log in as the new user and confirm they can see what they need.
  4. Delete the old user — Manage Account → Users (app icon, top right → Manage Account → Users), then the delete (bin) icon on their row. Delete is the only removal mechanism; there's no deactivate/suspend state, and deletion is permanent, so only do it once the new account is proven working.

The downside of the fallback is that the new account starts fresh (re-invite, new password) and the old account's record is gone — which is exactly why the in-place change above is preferred.

Watch-outs

  • Lead with "we'll change it for you", not "delete and recreate". The in-place change keeps the account, history and password; the create-and-delete route loses them. Only fall back to create-and-delete if the customer needs it done themselves immediately.
  • There is still no deactivate option — to remove someone (a leaver with no successor email change), delete is the only mechanism, and it's permanent. Don't say "deactivate".
  • Customers can't change the email on a user record themselves — there's no field for it, and they shouldn't attempt workarounds. The in-place change is something Civic.ly does on the back end safely (it keeps the Cognito login mapping intact); the customer just sends the list.
  • Remember to update any external systems (Slack, email distribution lists, password manager records) that referenced the old email.
  • If the migration is being done for Assertion 10 reasons, double-check that the Clerk and Chair specifically are the ones on role-based addresses afterwards — see Does every council admin need a non-personal email address for Assertion 10?.