Open specific support actions, not blanket access
Support access is attached to a particular action. Wildo checks whether that operation permits an application operator to cross an organization boundary and whether the operator has a usable grant for the target organization.
Restoring an account or repairing ownership can have a deliberate path without opening general editing or immediate permanent deletion across customer accounts.
Example — Restore an organization's ability to administer itself
An operator obtains access for a stranded organization, then uses the ownership-repair action to promote an active member whose linked user is also active. The action does not create a new member or allow arbitrary changes to the organization’s records.
When no usable owner remains, the grant service checks that condition and can automatically approve recovery access; the operator cannot simply assert it. The grant approval policy explains when customer approval is required.
The illustration shows another specific support action: restoring an organization awaiting deletion during its retention window. Ownership repair follows the same principle, with its own operation and inputs.
For engineers
The ownership-repair operation on organizationMembers is a concrete example. This selected fragment removes comments and the neighboring notification declaration; it belongs inside the resource’s operation configuration:
[OrganizationMembers_Operations.GRANT_OWNERSHIP]: {
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 role gate and admitsCrossTenantPlatformAdministration do different work: one checks authority, the other opts this variant into crossing. The implementation supplies the narrow ownership change; the declaration alone does not implement a business action. Its required justification belongs to the request, while grant approval follows the separate access-grant lifecycle.
Establish access before invoking the action
Request a temporary platform access grant for the target organization and follow its approval policy. The authorizer looks for a usable grant for this operator and organization within its time window. A lookup failure refuses access. The request-access operation has a narrow bootstrap exception because requiring an existing grant to request one would make the flow unreachable.
Membership is established from authenticated role entries, not an organization ID supplied in the URL. Unit-scoped authority is not treated as organization-wide membership. Admission is checked in the role/collection path and the fetched-record path so that opening one route does not silently open another.
Repair ownership without replacing existing permissions
The target must be an active membership linked to an active user. An invited or suspended member, or a disabled user, cannot restore usable administration; the action refuses that target instead of reporting a cosmetic repair.
The implementation makes roles server-authoritative and includes the linked-user read in the membership transaction. A caller cannot inject its own role set through a lower-level service call. The following selected implementation preserves existing roles and makes an already-owner retry succeed:
const currentRoles = normalizeRoleArray(currentObject!.roles);
if (rolesConferOrganizationOwner(currentRoles, organizationOwnerConferralResolver())) {
return { roles: currentRoles };
}
// Add ownership without removing the member's other roles.
return { roles: [...currentRoles, CORE_ORG_ROLES.ORG_OWNER] };
| Target or input | Result |
|---|---|
| Active member and active linked user | Adds ownership while preserving existing roles |
| Member already has an owner-conferring role | Keeps the current roles; retry is idempotent |
| Invited or suspended membership, or unusable linked user | Refuses the repair; resolve that lifecycle state first |
| Caller supplies a different role set | The implementation’s authoritative role result takes precedence |
Keep the operation’s purpose narrow
| Existing action | What makes the crossing deliberate |
|---|---|
| Activate or restore an organization | A named lifecycle transition with a recovery purpose |
| Request deletion with a window | A declared transition that retains a restore path |
| Grant ownership | Promotes an eligible active member; does not become a general membership editor |
| Immediate purge | No cross-tenant admission in the default declaration |
The crossing flag is an authoring decision, not a client header or runtime switch. Review it with the resource specification and the implementation’s actual writes. Reversibility is a design choice in these default operations, not a type-system rule preventing an application author from declaring an unsafe custom action.
At a fetched-record tenant denial, the response conceals existence with not-found semantics. Other earlier authorization failures can be refused before a record is fetched. Access evidence records the applicable observation; it does not establish that the action later completed successfully.