Given an invitation id, token or email, it returns the raw invitation row with its computed expiry and status, every sign-in account matching that email, each of those accounts' stored role and account assignment, matching crew member records, and whether the referenced crew actually exists. It is restricted to an admin of that account or a platform owner.
Also called: invite stuck pending · they signed up but cannot get in · invitation not working · duplicate account
- 1Look up by invitation id, token or email address
- 2Return the invitation row with computed expiry and status
- 3List every matching sign-in account and its stored metadata — this catches the duplicate-account case where someone signed up with a different provider
- 4Show linked crew member rows and whether the referenced crew exists
'He signed up but he still shows as pending' was a support call that ended in guesswork, because that failure leaves no error anywhere — the sign-up succeeded and something after it quietly did not, so a new hire sat locked out for a week. An admin can now look at what an invitation's state actually is, across the account records and the sign-in provider, instead of theorising about it. The commonest real cause is the one it puts on screen: the person has two logins on the same email, usually after signing up a second time with a Google button, and the invitation was accepted by the one nobody is looking at.
- A stuck invitation has no visible cause, so support guesses
- Duplicate sign-in accounts for one email silently break acceptance
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →