Separate product administration from customer administration
Each application has its own product-wide roles and customer-organization roles. Managing one customer account does not make someone an administrator of the whole product.
That distinction lets a product support its customers while keeping customer membership, administrative responsibility and temporary support access separate.
Example — Let a customer manage its team
A customer owner invites colleagues and manages their account. A product administrator operates the wider application. The owner’s organization role does not become a product-wide role, and the product administrator still needs the appropriate declared access to cross into customer records.
For engineers
ResourcePrimaryScope.APPLICATION means the scope of one hosted application. It is distinct from ResourcePrimaryScope.ORGANIZATIONS, which describes its customer organizations. It does not mean the Wildo application-manager service or authority over other hosted applications.
These selected entries from roles.shared.defaults.ts show the separate default role tables. They are fragments of two declarations, not one complete configuration object.
[CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN]: {
role: CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN,
inheritFrom: CORE_APP_ROLES.APP_ADMIN_BILLING_MANAGER,
isSystemRole: true,
relatedPrimaryScope: ResourcePrimaryScope.APPLICATION
}
// Separately, in DEFAULT_ORGANIZATION_ROLES:
[CORE_ORG_ROLES.ORG_OWNER]: {
role: CORE_ORG_ROLES.ORG_OWNER,
inheritFrom: CORE_ORG_ROLES.ORG_ADMIN,
isSystemRole: true,
relatedPrimaryScope: ResourcePrimaryScope.ORGANIZATIONS
}
A role is resolved in the table for its scope, including that table’s inheritance chain. Writing the name of an application role into an organization membership does not create application authority. Organization-unit roles are narrower still; a unit assignment is not an organization-wide membership.
Declare the operation and the reach it needs
| Intended action | Authority to consider |
|---|---|
| Manage one customer’s members | Organization membership, operation roles and grant ceiling |
| Operate application-wide resources | Application-role table and the resource’s operation contract |
| Support a particular customer from outside its membership | Declared cross-tenant variant plus usable tenant access grant |
| Enumerate permitted application-wide directory data | Declared read surface plus usable application-wide grant |
| Read application audit data | Administrator permissions; a usable application-wide grant is also required when auditTrail.applicationReadAccess is independent-approval |
Application authority is necessary for product administration, but it is not blanket permission to read or edit every customer’s records. The authorization layer separately evaluates the operation’s admission and the applicable grant. Customer-specific and application-wide grants have different scopes; an empty customer identifier is not a substitute for the latter.
Match the approval to the grant’s scope
| Grant | Approval and lifecycle |
|---|---|
| Customer-specific access | Bound to one organization. With a usable owner and approval required, it starts pending; tenant authority approves or denies it. When approval is disabled or no usable owner exists, the request can become active immediately. |
| Application-wide read access | Bound to one application, not one customer. Requests always start pending; approval requires a different application super-administrator. There is no tenant-policy or ownerless auto-approval branch. |
An active grant must still be usable for the requested access, including its expiry and revocation state. Neither grant replaces the operation’s role and admission checks. The registration workflow explains how to provision the second identity, including the deliberate single-developer local convenience.
Keep recovery authority explicit
The framework’s administrative floors protect against writes that would remove the last usable administrator. A startup report also detects states introduced outside those write paths, such as a restore or direct database edit.
Within the application’s role hierarchy, an organization may have a higher application-level recovery path; the application super-administrator floor has no still-higher role in that hierarchy. Recovery from an externally introduced zero-administrator state is an operator procedure. Sharing Wildo’s infrastructure does not silently create a cross-application customer-support identity.