Organization and user administration

Ethen has sign-in, sign-up, settings, and project-oriented routes, but a complete organization and membership product is not established. Durable invitations, enterprise roles, access-review automation, SSO, SAML, SCIM, and directory provisioning remain unresolved.

This page describes the administrative concepts that can be used safely today and the checks required before a deployment treats users, projects, or settings as an enterprise identity boundary.

Organizations

An organization would ordinarily own users, projects, policies, billing, and shared configuration. A complete organization hierarchy and a verified mapping from organization identity to Supabase records are not available.

Do not treat a project route, workspace label, or settings page as evidence of organization tenancy. A deployment should document the actual ownership key used by each sensitive table and route.

Until the model is approved, keep organization-level procedures conservative and avoid claiming organization deletion, transfer, parent-child structures, or centralized administration.

Questions the organization model must answer

A complete organization model needs stable answers for creation, ownership, membership, project association, policy inheritance, billing ownership, deletion, and transfer. The current route inventory and settings surface do not establish those behaviors.

Before using “organization” in an operational procedure, identify the actual record that owns the resource. It may be a user, project, workspace-like context, provider account, or deployment. Use that exact boundary in authorization checks and reports.

If several customers share one deployment, unresolved organization ownership becomes an isolation risk. Keep customer data in approved separate environments or stores until the backend model and enforcement are verified.

Ownership conflicts

If two users or teams claim the same project, do not resolve the dispute by changing an identifier in the interface. Use the organization’s approved ownership evidence and inspect the backing record before altering access. Ownership transfer is not implemented as a verified workflow.

A future organization model will need to define who can transfer or delete an organization and what happens to projects, provider credentials, logs, and billing records. Until then, avoid operational promises in those areas.

Administrative ownership

Assign an accountable administrator for identity configuration, project ownership decisions, provider-account access, and emergency offboarding. Those duties can be held by different people, but each one needs an approved handoff path.

The platform does not currently prove a super-administrator or organization-owner role. Avoid giving one person broad deployment and provider credentials merely because the interface lacks a narrower option.

Users

Clerk can provide authenticated user identities when configured. The sign-in and sign-up route family supports entry into that identity system, but root configuration alone does not guarantee that every route uses the identity.

Administrators should verify user creation, deactivation, session termination, and backend ownership separately. If a user is removed from the identity provider, check whether project, provider, local, or external accounts still grant access.

No complete user-lifecycle automation or identity-to-database bridge is established.

Joiner, mover, leaver process

For a new user, confirm the identity-provider account, intended projects, allowed products, provider or billing access, and any approval authority. For a user changing roles, remove old access before adding broader permissions where practical. For a departing user, disable sign-in, revoke personal API keys, remove project access, and review external provider or local runtime access.

The process should include service and shared accounts. A departed administrator may have configured environment variables or provider accounts that remain active after the user session ends.

Because no unified user-lifecycle automation is verified, administrators should maintain an external checklist and evidence until the product implements a durable workflow.

Shared and service accounts

Shared human accounts weaken accountability and complicate offboarding. Prefer individual identities for people and separately named service credentials for automated work. Record the service owner and affected routes.

No complete service-account administration surface is verified. Manage those identities through the deployment and provider systems that issue them, and include them in access reviews.

User records should avoid storing provider credentials or other secrets merely to simplify onboarding. Identity establishes who the person is; separate controlled systems should hold the credentials needed by services and automation.

Roles

Roles group permissions, but the platform does not currently publish a complete enterprise role matrix. Product-specific labels such as admin, operator, reviewer, requester, or approver may serve different purposes.

Define permissions by action and resource rather than by a broad title. Viewing usage, changing a provider key, editing a policy, approving a proposal, or reading an audit record should be evaluated independently.

Do not claim SSO group mapping, SCIM provisioning, automated role assignment, or a universal admin role.

Action-based role design

Start with actions rather than titles. Group actions only after the permission boundaries are understood.

• View: read project data, usage, logs, findings, or settings.
• Operate: invoke a provider or runtime, start supported work, or retry a job.
• Configure: change a provider, environment value, model route, or project setting.
• Govern: edit policy, review exceptions, or approve proposals.
• Administer: add or remove users and ownership.
• Investigate: access sensitive logs, evidence, or incident records.

The platform does not prove that these groups exist as enforced roles. They are a review framework for mapping actual route behavior. Avoid granting a broad “admin” capability when the user needs only one action class.

Default access

New users should receive no broader access than the onboarding decision requires. Avoid copying an existing administrator’s role as a shortcut. Where the product cannot express a narrow permission, use project separation, provider-account restriction, or deployment controls until the role model is implemented.

Document unresolved permissions so administrators know which actions require manual verification.

Invitations

A durable invitation workflow is not verified. The current route and identity evidence does not establish invitation creation, expiry, resend, acceptance, revocation, role assignment, or audit history.

If a deployment onboards users manually, record the requester, approved access, identity created, projects assigned, and completion date outside the product as needed. That procedure should not be represented as an Ethen invitation feature.

Avoid sending credentials through an invitation message. Users should authenticate through the configured identity provider.

Manual onboarding boundary

Until invitation behavior is implemented, an administrator can coordinate account creation through the configured identity provider and then assign the approved project or route access using the supported deployment controls.

Record the intended access before the person signs in. Verify the identity after account creation, and confirm the exact resources afterward. Do not send provider credentials or shared passwords as an invitation substitute.

If the identity provider offers its own invitation feature, describe it as provider behavior rather than an Ethen organization invitation.

An onboarding message should identify the approved product or project and point to the configured sign-in route. It should not promise that accepting the identity-provider invitation automatically creates Ethen membership, project access, or role assignment. Verify each outcome after the user signs in.

Access reviews

Access review compares current access with current job or project need. Because automated recertification is not implemented, the review should inspect identity-provider users, project ownership, settings access, API keys, provider accounts, approval roles, and local devices.

Record the resource, access type, reviewer, decision, and remediation. Remove access from both Ethen and external providers where applicable.

A complete enterprise access-review workflow, reminder schedule, manager attestation, and durable evidence store remain unverified.

Review frequency and triggers

The platform does not prescribe a fixed review cadence. Customers should choose one based on data sensitivity and operational change, and should also review access after staff departure, project transfer, provider-account change, incident, or major deployment change.

A review should compare access in the identity provider, Ethen routes, Supabase records, API keys, provider accounts, and local systems. Differences are expected when no central identity bridge exists.

Close the review by removing unnecessary access and testing the result. A spreadsheet or ticket can hold the evidence until Ethen supports a durable access-review record.

Remove stale provider and local access during the same review. A user can lose Ethen sign-in while retaining a provider console account, a copied API key, or files on a local device. Record those external systems in the scope rather than assuming the central application can revoke them.

Remediation follow-through

A review is incomplete until removals and changes are verified. Re-test the affected route, check that revoked API or provider credentials fail, and confirm that the user cannot access project data through another device or service identity.

Record any access that could not be removed immediately and assign an owner. Do not close the review based only on a settings-page update.

Troubleshooting

When a user cannot access a route, check whether authentication is configured, whether the session is valid, whether the server sees the same identity, and whether the backing store grants access to the intended resource.

When access is broader than expected, inspect the server action and data query rather than only the page navigation. Verify service-role use and RLS where Supabase is involved.

Do not solve an ownership problem by weakening route checks. If project or organization ownership cannot be determined reliably, keep the affected route out of production use.

Common administration failures

Do not weaken data authorization to make the interface appear functional.

If an access issue affects only one product, compare that product’s server route and store with a working route. Different subsystems can use different ownership or persistence paths even when the same user is signed in.