Restore ownership when a workspace is stranded
If an organisation no longer has a usable owner, a platform operator can promote an existing usable member. The recovery action adds ownership without replacing the member’s other roles.
The operation is deliberately narrow: it repairs authority in an existing membership rather than creating a new account or opening general cross-customer editing.
Example — Recover an ownerless customer workspace
An active customer member is ready to take responsibility after the former owner’s account is disabled. An authorised operator grants ownership to that membership and hands administration back to the customer.
For engineers
Establish the target before invoking recovery
The target must have both a usable organisation membership and a usable user account. An invitation or disabled account cannot become a functioning owner merely by receiving another role.
The operation is organizationMembers.grantOwnership. Its request requires a justification:
{
"justification": "Restore customer administration after the former owner left"
}
A non-member caller needs application-level super-administrator authority and the applicable target-organisation access grant. The operation explicitly admits this crossing; ordinary membership operations do not inherit it.
Invoke the repair on the membership
First complete the temporary-access request and approval sequence. For a genuinely ownerless organization, the request handler can establish the recorded recovery grant without waiting for the missing owner. An operator still needs the required platform role and a usable grant.
MEMBERSHIP_ID below identifies the existing organization-member row, not the global user. Obtain that identifier from the authorized support context; the grant does not make an ordinary cross-tenant membership LIST available. This route is the one exercised by Wonder Todos’ ownership-repair example:
curl -X PUT "$BACKEND_URL/organizations/$ORG_ID/organization-members/$MEMBERSHIP_ID/grant-ownership" \
-H "Authorization: Bearer $OPERATOR_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"justification":"Restore customer administration for support case SUP-42"}'
Use the operator’s own authenticated token after the grant becomes usable. The request does not accept a replacement role array. On success, the existing member gains ownership while retaining their other roles; the customer can resume administration. Retrying for an existing owner does not duplicate authority.
Understand the authoritative result
The prefix marks roles authoritative. It checks the current membership and user, retains all existing roles and adds ORG_OWNER if they do not already confer ownership. A retry is idempotent: a member who is already an owner remains an owner.
It cannot demote someone, move the membership or replace the entire role set with values supplied by the caller. The write and the linked-user usability check participate in the same transaction.
Confirm the repair and preserve the operator’s reason
Re-check that the target can administer the workspace and appoint another owner where appropriate. The current request contract requires justification, but the implementation does not persist that request value; keep the operator’s reason in the operational case record. The emitted operation evidence must not be described as containing the discarded justification.