Enterprise Settings: Who Sees What, and How a Student Migrates Out

Settings at /enterprise/settings is the same component the consumer app renders, with two blocks swapped by portal. The rough edge first: the swap keys off your session role, so an admin or a moderator who opens this page gets the consumer Billing & Usage card and a Delete Account button. I read the code on 20 September 2026.

Key takeaways

• All three enterprise roles can open this route, and each one has a Settings link in the side menu.
• Only a session whose role is enterprise_user sees Migrate to Personal Account.
• First name, last name and bio save together under one Save Changes button.
• Limitation: admin and moderator sessions get consumer billing figures and the delete controls.
• Limitation: nothing here reads your existing migration request, so a reload clears the banner you just got.

Which cards does each role get?

The split is one computed flag, true only for a resolved enterprise_user role. Before the role resolves it falls back to the route's portal flag, which reads 'enterprise' for everyone, so the server-rendered first paint shows an admin the student layout.

Two bits of the profile card are decoration. The green "Connected" badge sits beside a Google icon with no condition around it, so a student who signed in with a one-time link gets it too. The camera button over the avatar has no click handler.

If the profile load fails, the red bar at the top of the app carries the server's message and status code, then the component adds "Saving Profile Info failed. Please visit later." on a page where you were only reading. The bar shows the latest line only, with a "+1 more" button once a second error is queued.

Setting a password after a one-time link

The Security card exists for enterprise sessions and nowhere else, because the status call behind it needs an enterprise token. With no password set, its subheading reads "You signed in with a one-time link. Set a password so you can get back into your account any time.", the current-password field is not drawn, and the button says Set a password.

Validation happens in the component, and each failure prints in the same red line below the verification widget and above the button: "Enter your current password.", "Choose a password with at least 8 characters.", "Passwords do not match.", or "Please complete the verification check." On success the fields clear and a green "Password updated." panel appears at the top of the card.

How a student asks to move to a personal account

One field, one button. Type an address into the box showing [email protected] and press Request Migration, which reads Submitting... while the call is out. The field uses Angular's email validator, so the label says Gmail but any well-formed address passes; a malformed one turns the border red and prints "Enter a valid email address." underneath without sending anything.

The migration field rejects an entry that is not an email address.

What comes back depends on whether you still hold a seat on a batch that has not expired.

• No live batch: the migration runs immediately, the request row is written as already decided, and a green bar says "Migration approved automatically. Log in with this Gmail account going forward."
• Live batch: a pending row is written, one email goes to your organisation's admin with a link to their review screen, a note lands in your chat thread, and a yellow bar says "Request submitted — awaiting admin approval."
• Refused: a red box with the server's wording, such as "That email is already associated with another account."

Then the page forgets. There is no stored pending state and no approved or rejected view here; the decision reaches you as a chat message instead. The admin's side of that queue has its own post, the enterprise migration requests one.

Author's take. Putting the outcome in chat was the cheap choice when I built it, and I can defend the chat notice. I cannot defend showing a student a success banner and then losing it on refresh.

What approval changes on your account

Approval rewrites one row. Your user record takes the consumer role the page asked for, your email becomes the address you typed, the sign-in provider is set to Google, any stored password hash is cleared, and every batch seat you hold is marked disabled.

Resumes move with you because they were never keyed to the batch; they hang off the same user id, which does not change. Your old organisation email no longer matches that row, so the next settings call made with your enterprise token comes back unauthorised. The app then takes its consumer branch for that error, which logs out the consumer session and sends you to the home page, not to the enterprise sign-in.

Use this if you are leaving the college account and want your saved resumes to follow you, or you signed in with a link and want a password.

Skip this if you want to track a request you already filed. The consumer post "Account Settings: Your Profile, Your Data, and Deleting Your Account" covers the delete and export side that leaks into an admin's view here.

Related pages

• Migration Requests in AceDraft for Teams: Moving a Student to a Personal Account
• My Resumes in AceDraft for Teams: The Student's Resume List
• AceDraft for Teams: Creating an Admin Account and Signing In