Skip to main content
“I cannot get in” almost never means the platform is broken. It usually means the address, the workspace, the status or the sign-in method is not what the member thinks it is. Work through these in order: knowing what you ruled out is what makes an escalation fast to answer. Built for whoever answers the “I cannot log in” emails. Replaces guessing and resetting passwords at random.

​
The five-minute pass

1

Confirm the address, character for character

An account is identified by email plus workspace, so a work address and a personal one are two different accounts. Compare what they typed against the address on their profile.
2

Confirm the workspace

If the same address belongs to more than one organisation on Orgo, the login screen has to pick one. Ask whether they belong to another community; they will not think to mention it.
3

Check their status, not their fee

A paid fee does not grant access. Open Members → the member → Edit → Permissions and read Status. Only Active permits a sign-in, while the fee tab looks perfectly healthy either way. See User statuses.
4

Check the sign-in method they used

Password, one-time code and social sign-in do not fail the same way, and do not even find the same accounts. See below.
5

Have them try a private window

A stale session shows the symptoms of a broken account, and this rules it out in thirty seconds.

​
The workspace picker hides some accounts

When a member enters their email on the shared login page, Orgo looks up which workspaces that address belongs to. That lookup only returns accounts whose status is Active, Unconfirmed email, New request, Inactive or Awaiting referral. A member whose account is Suspended, Excluded, on the waiting list or deleted is therefore not shown their organisation at all. They report “it says my organisation does not exist”, which reads like a platform fault and is the status doing its job. Check the status before you believe the message.
The lookup also surfaces workspaces where the address is only an event contact rather than a member. Those route to the event app’s own code login, not to the member login, and they carry no password. See the event app.

​
The three sign-in methods behave differently

An Inactive member who only ever uses Google sign-in will keep hitting a dead end. Ask them to sign in with the one-time code instead: that path offers the reactivation prompt, or at least reports the real status.
A refused social sign-in always finishes on app.orgo.space, never on your own address. A member on your custom domain or inside your branded app who picks Google and is turned away will report being thrown onto a different website; that is the refusal, not a separate fault. The auth_error value in the address bar there names the real reason, and it is one of the reasons in the table above.
Which method the login screen offers first is a setting: Default to Password Login (Settings → Users & Profiles → Configuration). Members can always switch to the other one.

​
What each blocked status tells the member

​
Password problems

Self-service reset. The member uses the forgot-password link, receives a code, and sets a new password. It only works for accounts on Active, Inactive, Awaiting referral or Unconfirmed email. A suspended or excluded account is refused.
Completing a password reset also moves the account’s status: an Unconfirmed or Inactive member who resets their password becomes Active, or New request if Manual Approval is on, or Awaiting referral if the referral programme requires referrals. This is the fastest way to unstick a member who never confirmed their email address.
Admin-initiated reset. On the member’s profile you can send them a password-reset email. It requires HR_LOCAL over their local group, works only for the same four statuses, and is throttled to one per minute per member. Each send is written to the audit log against the administrator who sent it. Members who never had a password. Anyone created by an invitation, an import, an admin, or by signing in with Google has a randomly generated password they have never seen. They must use the one-time code or a reset. One password across workspaces. If the same address is a member of several organisations on Orgo, changing the password changes it in all of them.

​
One-time code problems

The email code path has hard limits. Quote them when a member says the code “does not work”: A member who has requested several codes is usually typing an older one. Have them use the most recent email, or wait out the lockout rather than requesting again.

​
Multi-factor authentication

When the MFA module is on, everyone with tenant-level admin, HR or finance permissions has MFA forced on and cannot switch it off. Every other member has a switch on their own Settings & Privacy → Multi Factor Authentication page. The verification code is valid for 5 minutes, and a device that has passed the check stays trusted for 2 days. After that, or on a new browser or device, the member is asked again. “It asked me for a code again” after a couple of days is expected behaviour, not a fault.

​
Email changes

Changing the email address on an account is a two-step verification: a code to the current address, then a code to the new one. Only when both are verified does the address change, and the member is signed out and must sign in with the new address. A member stuck halfway through this still has their old address. If they cannot receive mail at the old address at all, an admin with ADMIN_LOCAL over their local group (or HR_TENANT) sees a plain address field on the member’s Email settings instead of the two-step flow, and can change it directly.

​
When it is worth reporting

Report it, rather than working around it, when:
  • the same member has the same problem again after it was fixed once;
  • a member is reactivated, suspended or deleted with no administrator action;
  • the login page shows an internal error rather than a specific message;
  • text renders as odd characters instead of apostrophes or quotation marks.
Include the address they used, the workspace, the method they tried and what they saw. Those four together are what makes a report reproducible; without them the first reply is always a request for them.