> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Decide who owns admin access
> Name who owns sign-in and who owns roles before you restrict how your team signs in, and learn which questions only your own IT department can answer.
Name two owners before you restrict how your team signs in: the person who administers your Google Workspace or Microsoft Entra directory, and the person who owns the TWICE Commerce account. They are rarely the same person, and access breaks in the gap between them.
Settle it now rather than in the week before you go live. Getting a group created in your directory, or agreeing who approves an access request, goes through an IT department on its own timetable.
## What restricting sign-in actually does
TWICE Commerce does not federate with your identity provider. There is no SAML or OIDC connection to your directory and no directory sync.
What the admin gives you is an allowlist of four sign-in methods: **Email & Password**, **Google**, **Microsoft** and **Facebook**. Restrict the account to Microsoft, and everyone reaches it with a Microsoft account that Microsoft has authenticated. Nothing about your directory's groups, policies or joiners reaches TWICE Commerce with it.
## Who decides what
Your directory decides who gets through the door. TWICE Commerce decides what they can touch once inside. Both have to happen, and only one of them is ours.
| Decided in your directory | Decided in TWICE Commerce |
| ----------------------------------------------------------------- | ------------------------------------------------------------------ |
| Whether a person has an account to sign in with at all | Whether that person is a member of your TWICE Commerce account |
| Joiners and leavers | Which role each user holds, and which areas they see |
| Group membership, multi-factor authentication, conditional access | Suspending a user, or removing them |
| Password policy and reset | Nothing. TWICE Commerce stores no password for a directory account |
Revoking someone in your directory stops them signing in with that provider. It does not end their TWICE Commerce membership, and it does not change what their role allowed. A leaver has to be removed in both places.
## Decide these four things
Answer all four before anyone changes a setting. Each one has an owner on your side, and none of them is a TWICE Commerce setting.
| Decide | Who usually owns it | What goes wrong unsettled |
| ---------------------------------------- | ------------------------------------------------- | ---------------------------------------------------------------------- |
| Who approves a request for admin access | The TWICE Commerce account owner | Requests reach whoever is nearest and roles get handed out by accident |
| How a new starter gets an account | Your IT department, then the account owner | A joiner waits days for an invite nobody knew they owed |
| What happens on their last day | Your IT department and the account owner together | A leaver keeps a working sign-in, or keeps a membership |
| Which sign-in methods the account allows | The account owner, with IT | Someone restricts the account and locks out half the team |
Write the two names down where the launch owner can find them. A rota or a shared mailbox is not an owner.
## Restrict the sign-in methods
Set the allowed methods under **Settings → Security**, in the **Sign-in methods** card. Tick every method your team is allowed to use and clear the rest.
A new account allows all four until you restrict it. At least one method has to stay selected: the form refuses to save an empty set, with "At least one sign-in method is required".
Tell the team before you save. Anyone signed in with a method you cleared is dropped to the account picker on their next request, and their row there reads "Sign in with Microsoft to access" rather than opening.
Restricting sign-in methods is a plan capability. The [plans](/docs/twice-commerce-overview) list enforced SSO sign-in under Enterprise. Check your agreement, or ask your TWICE Commerce contact what your account includes.
## What happens to people who already have a password
Nobody is locked out of their work, and no data moves. Each person links their directory account to the membership they already have, once.
| Their situation | What they do |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Signs in with a password today | Sign in with the new provider. TWICE Commerce recognises the email, emails a 6-digit code, and links the credential after **Verify email** |
| Has never signed in at all | Follow the invite, then sign in with the provider. Nothing to link |
| Is not a member of the account | Nothing works. An uninvited sign-in is rejected with "We don't recognize that email", not turned into an account |
Microsoft accounts can skip the emailed code when their email domain is on the account's verified login domains. That list has no field in the admin, so ask your TWICE Commerce contact to set it before a large team links up.
## Keep a way back in
Turn on **Security restrictions bypass** in the same view, and check that at least two people can use it. It lets a user who holds the `Account settings > Security > Manage` permission sign in with email and password even when that method is not allowed, which is how a misconfigured provider gets fixed.
Owner and Admin hold that permission. Manager and Member do not, and neither does a custom role that was not given it.
Test the bypass while the restriction is live, not after an outage starts. Have one of those two sign out, sign in with email and password, and confirm they reach the admin.
Without the bypass, a misconfigured provider leaves nobody able to change the setting, and recovering the account becomes a support request.
## Roles are never driven from your directory
Assign every role in TWICE Commerce by hand, under **Settings → Users & Roles**. There is no group-to-role mapping and no provisioning from your directory, so a group in Entra changes nothing here.
Plan the two processes around that:
* **A joiner** needs an account in your directory and an invite in TWICE Commerce. Neither implies the other, and the invite carries the role.
* **A leaver** needs removing in both places. Their directory account going away blocks that provider, but their membership survives it, and so does a password they set earlier if **Email & Password** is still allowed.
Remove a leaver under **Settings → Users & Roles**, or set them to **Suspended** to keep the record and end the access. The account owner cannot be suspended or removed, so transfer ownership first when the owner is the one leaving.
See [Get your team into TWICE](/docs/guides/launch/get-your-team-into-twice) for choosing the role itself.
## What TWICE support cannot do
Ask your own IT department for anything on the left. Nobody at TWICE Commerce can reach your directory, and asking costs you a round trip.
| Not ours | Ours |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Create, disable or unlock an account in your directory | Membership, roles and visible areas in your TWICE Commerce account |
| Reset a directory password or a multi-factor device | Which sign-in methods the account allows |
| Map your groups to TWICE Commerce roles, which the product does not do | Setting the account's verified login domains |
| Tell you who in your organisation approves access | Recovering the account when the bypass was never turned on |
## Done when
* One named person owns admin access on your side, and one named person administers the directory. The launch owner has both names.
* Your joiner and leaver steps name both systems, and someone has agreed to run them.
* The allowed sign-in methods match what your team can actually use, and the team was told before it changed.
* Two people hold the security permission, and one of them has signed in through the bypass with the restriction live.
## Related articles
The launch step this guide belongs to.
Choosing a role, sending the invite, and visible areas versus data access.
The two cards on the page, field by field.
The invite flow, the four system roles, and the permissions matrix.
The decisions that come before any configuration.