Skip to content

Deciding a sign-in request

What a sign-in request is, why Social Studio refused rather than joining two accounts, and what allowing or refusing one actually does to your account.

Updated

Two accounts holding the same email address is not two people being one person. When somebody signs in with a Google or Apple identity carrying an address your account already uses, Social Studio refuses to join anything on the strength of that match, records the attempt as a sign-in request, and leaves the decision to you. The same happens when somebody proves they hold a mobile number your account has attached.

Nothing is joined while a request sits there, and nothing will be joined unless you decide it. The person who asked is told only that their side is recorded and that the account holder decides the rest. They are told nothing about you.

You are told nothing about them either, and that is deliberate rather than an omission. The request records who it is about - your account - and never who asked. Naming them would turn this page into a way of finding out who is trying to reach a particular address or handset, which is exactly what somebody holding a recycled SIM would want.

BEFORE YOU START

  • A way to complete a security check. Both decisions need one, and refusing needs one just as much as allowing does. If your account has an authenticator, a code from it is enough. If it signs in through your own identity provider, Account security lists the check you can use.
  • Nothing else. This page is about your own account and needs no organisation role.

STEPS

  1. Open Sign-in requests from the sidebar, or go to /app/sign-in-requests. Account security links to it too.
  2. Read what the request is about. A sign-in request names the address it matched on. A number request shows the number, partly masked, so you can recognise one that is yours.
  3. Read what it is waiting on. A request where the other side has not yet proved anything has nothing for you to agree to yet.
  4. Choose. "Allow this sign-in method" lets that method reach your account. "Refuse" ends the request.
  5. On a number request the two choices read differently, because they do different things: "Release the number" detaches it from your account, and "Keep the number" ends the request.
  6. Complete the security check when you are asked for one, and the decision is recorded.

WHAT YOU SHOULD SEE

A short confirmation naming what happened - "Allowed. That sign-in method now reaches this account.", or "The number has been released. Nobody holds it now." - and the request rewritten with its outcome. A decided request stays on the page with what you decided; it does not disappear.

WHAT THIS WILL NOT DO

  • It will not merge two accounts. Allowing a sign-in request lets one more method reach the account you already have. No content moves, no team membership changes, and no second account is absorbed.
  • It will not hand your number to whoever asked. Allowing a number request RELEASES it: your account stops holding it, nobody holds it, and whoever can prove the handset must attach it again with a fresh code. That may be the person who asked, or it may not.
  • It will not tell you who asked, ever.
  • It will not notify you. Nothing emails, pushes or badges when a request arrives, so somebody who is waiting on you may have to tell you to look.
  • It will not shut anybody out of Social Studio. Somebody you refuse can still take an account of their own, with no email address on it, so a refusal is an answer about your account rather than a judgement on them.
  • It will not work on your phone. There is no Flutter screen for this, so a request can only be decided on the web.

WORTH KNOWING

Whether your account has ever confirmed its own email address is shown on a sign-in request, and it is shown for you to weigh rather than because the decision rests on it. Accounts created through single sign-on and through developer signup both carry an address nobody checked. That is why proving you can read a mailbox is never accepted here as proof of who an account belongs to - the security check on your own session is.

Releasing a number you rely on to sign in is worth a moment's thought. Add another way in first if it is your only one.

IF IT DOES NOT WORK

  • "This action needs a fresh security check." means the decision was not recorded and the page is asking you to complete one. Nothing changed.
  • "This account does not sign in with an authenticator code." means the check for your account lives elsewhere. Open Account security, complete a check there, and come back.
  • "The case is no longer accepting decisions" means somebody or something already resolved it - most often the person who asked took an account of their own instead.
  • "The existing account already holds a different external subject" means your account is already reachable by a different external identity, and one account can hold only one. Nothing was changed and support has to look at it.
  • "Social Studio could not read your sign-in requests just now" is not the same as having none. Reload before concluding anything.
  • A request whose state Social Studio does not recognise shows no buttons at all, on purpose. Contact support rather than acting on it.

COMMON QUESTIONS

Somebody says they cannot sign in and there is nothing on this page. What now?

Then no request was recorded for them, which usually means the address or number they are signing in with is not the one your account holds. A request only appears when Social Studio refused a sign-in because it landed on your account. If the page says it could not read your requests, that is different - reload before concluding there are none.

Will allowing this give somebody else access to my content?

No. It lets one more sign-in method reach the account you already have. It grants no team membership, moves no content and creates no second account. Whoever was signing in reaches YOUR account only if they are you; if they are not, refuse.

If I release my number, can I get it back?

Only by proving the handset again with a fresh code, the same as anybody else. Releasing gives the number to nobody, so whoever holds the SIM at that moment can attach it.

  • Securing your account

    Turning on two-factor authentication, keeping recovery codes, ending browser sessions and revoking credentials, and what the step-up check is for.

  • Reading the audit trail

    Who did what and when across the organisation, the separate trail of your own account security events, and the two things deliberately left out of both.