A coaching invitation is a bounded offer of access, not a permanent sign-in credential. Model pending, accepted, expired and revoked states separately from whether the person is authenticated. When an accepted invitation is reopened, guide the person to their current relationship or sign-in rather than treating every replay as the same generic failure.
Prerequisites are the intended organization, recipient identity, role, expiration policy and acceptance operation. Client invitations and staff invitations may have different rules. Define those rules before borrowing a token flow from a nearby part of the application.
Bind acceptance to the intended relationship
An invitation should identify the access being offered and the account conditions required to accept it. A signed-in person using a different account needs a deliberate account-switch or verification flow. Do not automatically transfer the invitation because someone knows its recipient’s display name.
| Observed state | Useful destination | Access meaning |
|---|---|---|
| Pending and valid | Review and accept intended relationship | No relationship accepted yet |
| Accepted; signed out | Sign in to the existing account | Old link is not the credential |
| Expired before acceptance | Request or issue a new invitation | No new access from old link |
| Revoked or relationship ended | Explain current access state | Acceptance history does not restore access |
The table is proposed for a client flow. It is not a statement that these exact states or roles are currently implemented. Keep account creation and invitation acceptance distinct so a successful registration does not accidentally grant a broader role.
Treat replay and reissue as deliberate transitions
CoachNow’s first-party support FAQ explains that its invitation is one-time-use and should not be used as the login route after signup. That is a useful example of a real support confusion. It does not establish another platform’s expiration duration or role model.
CoachNow: invitation expiry versus normal sign-in
A repeated acceptance request should resolve the original invitation’s current state without creating another relationship. Reissue should explicitly decide whether an older pending link is invalidated. Retain invitation identity and accepted account identity separately, and avoid exposing tokens in public diagnostics.
Do not copy staff policy into a client promise
The reviewed UltraFit360 source creates sub-coach invitations with a token, role and expiration, and can replace a token for the same organization and email. This is a related staff lifecycle example. It is not evidence that client invitations use the same role, duration, acceptance or replay rules.
A proposed client invitation milestone should inspect the actual acceptance route and server checks, not only the creation form. Review role assignment, current organization membership and revoked access after acceptance. Frontend button visibility cannot establish who can accept or read the resulting records.
Write recovery copy for the actual state
“This invitation was already used; sign in to your account” is more actionable than “invalid link” when that is the verified state. “This invitation expired before acceptance” needs a reissue route. Keep error text neutral until the server has established what can be disclosed about the invitation.
If the person already has an account, preserve their current session while making the intended recipient clear. If a new account is required, retain the pending invitation through registration without treating account creation alone as acceptance. Give support a redacted state reference rather than asking people to paste private action links into public channels.
Acceptance should test new and existing accounts, mismatched signed-in identity, expired links, reissue, repeated acceptance and access revoked later. No invitation was issued or accepted for this article. The output is a proposed lifecycle worksheet that can be verified against one real client flow before adopting staff-invitation assumptions.
Keep invitation communication state separate from invitation validity. An email can fail while its pending invitation remains valid, and a delivered email can contain a link that was later revoked. Resending should use the intended reissue or replay policy rather than creating a new role assignment. A fixture can create a pending invitation, simulate failed delivery and then retry the communication. Verify that no extra relationship appears and that the current valid link is the one the person receives.
Coach client access permissions
Bring one client-to-coach workflow, current data contract and acceptance constraint to discuss a bounded fitness product build or integration pilot.
Explore health fitness app development
Why should invitation links and sign-in be separate flows?
An invitation authorizes a bounded relationship transition. After acceptance, sign-in and current access should use the account and relationship state, not replay the old link.
Can a sub-coach invitation implementation prove client invitation behavior?
No. It is an adjacent lifecycle example; client roles, acceptance and replay rules need separate verification.