A refused action should protect the application without leaving its administrators stranded. Wildo pairs sensitive access rules with specific recovery operations, so support can correct an exceptional situation without opening every customer account to routine intervention.
The distinction matters when authority itself needs repair: preventing the last owner from leaving is useful, but an account that has already lost its usable owner needs a different path back.
Make recovery part of the design
Keep the ordinary rule
A support intervention does not weaken everyone’s access checks.
Name the exceptional action
Recovery targets a particular operation and customer, rather than enabling general access.
Check the result
Restoring authority means leaving a usable administrator, not merely changing a role label.
Example: Restore an account's administration
An account has no usable owner. An authorized platform operator obtains temporary access for that customer and uses the ownership-repair action on an existing, active member. The action adds ownership while preserving the member’s other roles. Ordinary cross-customer operations remain unavailable.
For engineers
The organization owner floor checks active memberships and usable users whose organization-wide roles confer ownership. It serializes reducing changes with the organization row so two simultaneous removals cannot both pass an outdated count. The application administrator floor protects a separate population; neither is a substitute for the other.
Recovery has a different entry point. organizationMembers.grantOwnership is a named API operation, declared in organization-members.shared.resources-config.schemas.ts. This selected variant excerpt keeps the authority, scope declaration and input together; source comments are omitted:
variants: [
{
variantType: ResourceOperationVariantType.API_CALL,
isDefault: true,
roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
riskLevel: ResourceOperationRiskLevel.CRITICAL,
resourceOperationLike: CoreResourceOperation.UPDATE,
admitsCrossTenantPlatformAdministration: true,
requestDto: z.object({
justification: z.string().min(1).max(1000),
}),
},
],
The declaration admits this operation variant across a tenant boundary. It does not confer blanket tenant access on that role. The authorization service also requires a usable, time-limited platform access grant for the operator and target organization. Where tenant approval is required, the grant remains pending until approval; the measured ownerless-tenant case has a separate recovery rule so approval does not depend on the missing administrator.
Make the repair’s postcondition real
The implementation in organization-member-custom-implementation.backend.service.ts runs through the resource service’s transactional path. It checks both membership and user usability, and declares roles authoritative: a submitted role array cannot turn this action into an arbitrary privilege assignment.
Once those checks pass, its selected return paths are:
if (rolesConferOrganizationOwner(currentRoles, organizationOwnerConferralResolver())) {
return { roles: currentRoles };
}
return { roles: [...currentRoles, CORE_ORG_ROLES.ORG_OWNER] };
An existing owner remains an owner when the operation is retried. Otherwise the action adds ownership without removing existing roles. After recovery, verify the member can administer the account and appoint a second owner where appropriate. The detailed ownership repair guide describes its invocation; temporary platform access describes admission.
Keep the evidence precise
The crossing and critical operation produce audit evidence, including the role change. The ownership-repair request currently requires justification but its handler does not persist that request value. Record the operator’s reason in the operational case; do not describe the emitted role-change event as containing it. The separate platform-access request has its own justification and lifecycle.
Recovery reach is deliberately selective. Restore, reactivate and request-deletion variants can declare a reversible crossing; immediate purge does not acquire that crossing simply because the caller is a platform administrator. An erasure acknowledgement is another distinct contract, not an administrative bypass flag.
When extending the framework, name the state your refusal protects, the actor and operation allowed to repair it, and the postcondition that demonstrates recovery. Keep those decisions in the operation and service contract, where both API callers and the standard interface meet them.