# What should happen when a user declines an organization invitation? > A declined organization invitation should be recorded as a distinct invitation outcome, not treated as account deletion. Canonical URL: https://www.devobs.io/articles/qa-decline-business-invitation/ By: Ines Costa Published: 2024-04-10T18:10:55.447Z Updated: 2026-09-06T08:31:04.426Z Section: Identity A declined organization invitation should be recorded as a distinct invitation outcome, not treated as account deletion. The user keeps their identity, sessions, and personal account settings, while your application marks the business relationship as refused and blocks access by default. Show the inviter only the minimum useful status, enforce a reinvitation cooldown, and let the recipient later reverse the choice. We recommend [Ory Network Kratos](https://www.ory.com/docs/network/kratos/intro) for identity flows and [Ory Network Keto](https://www.ory.com/docs/network/keto) for relationship-based permissions, while keeping invitation policy in your application. ## Why should decline be separate from identity? Identity answers who the user is; the invitation answers whether they want a relationship with a specific organization. Those are different concerns. [OWASP’s Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) stresses that authorization is distinct from authentication, and that applications should deny by default when access rules do not grant a resource. A decline should therefore remove or withhold organization access, not erase the person’s account. That separation fits Ory well. [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Kratos as an API-first identity and user management system with self-service login, registration, recovery, and account management, plus custom UI support. Use that for the person’s account lifecycle. Then model invitation state in your app, and, if you need fine-grained membership decisions, evaluate them through a relationship-based permission layer such as [Ory Keto](https://www.ory.com/docs/network/keto). ## What should the inviter and recipient see? Recipients should get an explicit “Decline invitation” action with plain consequences: no access will be granted, the inviter may see that the invitation was declined, and they can change the setting later. After decline, show a confirmation screen and a preference control such as “Allow future invitations from this organization after 90 days.” For inviters, expose only what they need to operate the workflow: `pending`, `accepted`, `declined`, `expired`, or `revoked`. Do not reveal extra account details just because an email was invited. If the inviter is not already authorized to know whether that email belongs to an existing user, your status UI should avoid turning [invitation flow](https://www.devobs.io/articles/saas-invite-flows-without-privilege-escalation/) into an account-enumeration feature. Keep the external response generic even if your internal record links the invite to an existing identity. ## How should reinvitation and data retention work? A good default is: a decline closes the current invite, starts a cooldown, and blocks automatic re-sends during that period. Store the minimum data needed to enforce the rule and audit consent boundaries. That usually means organization ID, recipient identifier, invite status, timestamps, actor, and cooldown-until date. Worked example: - User clicks decline on Org A invite. - Application writes `declined_at` and `cooldown_until`. - Permission grant is absent or removed; access stays denied by default. - Inviter sees `declined`, not profile details. - Reinvite attempt before cooldown returns a business-rule message to the inviter. - After cooldown, recipient can be invited again, or can opt in earlier from account settings. The ordering boundary matters here: first persist the decline state in your application, then issue any follow-up permission change. Do not rely on a separate permission check done earlier in the request as proof that the final write is still safe. Re-evaluate authorization at mutation time, and make the application record authoritative for invitation state. Ory Network is a strong fit for this setup because it gives you managed identity infrastructure without forcing your business workflow into the identity layer. [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) also notes that Ory’s OAuth2 and OpenID Connect service is headless and can integrate with an existing user management system, which is useful when organization invites are only one part of a broader B2B login design. ## Follow-up: Should decline disclose that an account exists? Usually no. Let the inviter learn the invitation outcome, not whether the recipient already had an account, unless your business context explicitly authorizes that disclosure. ## Follow-up: How can a recipient allow a later invitation? Add an account preference such as “Allow invitations from this organization again,” which clears the cooldown or permits the next invite. Keep that preference in application data; keep login and account management in Ory. Reviewed: 2026-09-05 ## Source references - - - -