Make support access requested and temporary
Support access can be tied to one customer account, a written reason and an expiry instead of being a standing privilege. Wildo requires a usable grant for declared platform crossings and lets the customer require approval.
The customer can see the request and withdraw the grant. Expired access stops being usable when its time window ends.
Example — Investigate a customer’s support request
An operator requests access to the named account for a short investigation. If customer approval is enabled, the operator waits for approval before using a declared support operation.
For engineers
The resource exposes requestAccess, approve, deny and revoke. The request supplies justification and requested duration; operator identity, status and expiry are server-authored. Default duration is one hour and the server caps requests at four hours.
Admission checks the actual expiry, not whether a background process has relabelled the row:
This implementation excerpt from platform-access-grants.shared.schemas.ts shows the decision in context; explanatory source comments are omitted.
export function isPlatformAccessGrantUsable(
grant: Pick<PlatformAccessGrant, 'status' | 'expiresAt'> | undefined,
now: Date,
): boolean {
if (!grant) return false;
if (grant.status !== PlatformAccessGrantStatus.ACTIVE) return false;
return grant.expiresAt instanceof Date
? grant.expiresAt.getTime() > now.getTime()
: new Date(grant.expiresAt).getTime() > now.getTime();
}
Declare the operation that support may use
The crossing flag belongs to an API operation variant. The built-in ownership-repair operation keeps the role, scope permission and request together:
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) }),
This is a selected variant fragment from organization-members.shared.resources-config.schemas.ts, not a standalone resource. Its operation enums and roles come from @wildo-ai/saas-models, with z from zod. The existing membership resource registers this operation. A custom support action needs its own registered resource operation, API variant and implementation; copying the flag alone creates neither a route nor business behavior.
Choose whether the customer must approve
platformAccessApprovalRequired is a field on the organization record, with a default of false. It is not an organization-type authentication override or a caller-supplied grant status. Set it through the authorized organization configuration path before support requests arrive. The request handler reads the stored organization posture and checks whether a usable owner can approve.
Request, decide, then perform the action
The following sequence follows Wonder Todos’ platform-access-grant lifecycle example. ORG_ID comes from the customer support case; ordinary organization listing is not a platform-wide customer directory. OPERATOR_TOKEN belongs to an application super-administrator. CUSTOMER_ADMIN_TOKEN belongs to a tenant administrator with authority to decide the request. Use a customer with approval required and a usable owner for this pending-approval example.
curl "$BACKEND_URL/organizations/$ORG_ID/platform-access-grants/request-access" \
-H "Authorization: Bearer $OPERATOR_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"justification":"Investigate support case SUP-42","requestedDurationMinutes":30}'
curl -X PUT "$BACKEND_URL/organizations/$ORG_ID/platform-access-grants/$GRANT_ID/approve" \
-H "Authorization: Bearer $CUSTOMER_ADMIN_TOKEN" \
-H 'Content-Type: application/json' \
--data '{"decisionReason":"Verified support case SUP-42"}'
Take GRANT_ID from the created grant record’s _id. Check its returned status and expiry: accepting the request does not mean access is active. With the example’s posture it waits for the tenant decision, and the operator’s crossing is refused while pending. The request operation itself has a narrow bootstrap exemption so an operator can ask without already holding the grant.
Approval uses the customer’s authority, not the operator’s platform crossing. For a refused request use the grant’s deny operation; to withdraw an existing grant use revoke. These are lifecycle operations, not edits to status or expiresAt. A usable grant is looked up when the operator calls the target operation; it is not a replacement login token to send as a Bearer credential.
Continue with the ownership-repair invocation for an actual declared target operation. The grant remains limited to its operator, organization and time window; it does not admit undeclared actions.
Apply both admission requirements
The target operation must declare that it admits cross-tenant platform administration, and the operator must have a usable grant for the target account. A grant does not turn every operation into a support door. Grant lookup failures do not restore standing access.
| Account posture | New request |
|---|---|
| Approval not required | Automatically active, with the reason recorded |
| Approval required and usable owner present | Waits for a tenant administrator’s decision |
| No usable owner can approve | Recovery path auto-approves with a distinct recorded reason |
The last case prevents an ownerless account from becoming impossible to repair. Approval posture and owner usability are checked on the request path, not copied from the caller.
Separate account support from global administration
Approval and denial use the tenant’s own authority; the platform crossing declaration does not let an operator approve on that basis. Application-wide directory access has a separate grant and two-person approval policy because no single tenant can authorize reading a deployment-wide directory.