User-owner association

Link a signed-in user to an Owner entity for owner-scoped permissions — three write-paths — self-request, self-request with auto-approve, and admin direct-bind.

User-owner association links a signed-in user to an owner entity. Without an association, the user cannot manage data entities and cannot be granted ownership-scoped permissions through an owner's Role bundles.

The platform supports three write-paths to create the binding:

• Self-request, then admin approves — a regular user submits a request from the home page; an administrator approves it on Management → Associations → New requests.

• Self-request with auto-approve — a user holding the DIRECT_OWNER_SYNC permission submits the same form; the platform auto-approves on the spot.

• Admin direct-bind — an administrator holding the OWNER_RELATION_MANAGE permission creates the binding directly from Management → Associations using the Create association button.

User-owner association is a one-to-one relation. A user can be associated with only one owner, and an owner can be associated with only one user at a time.

For regular users

After signing in, scroll to the bottom of the Catalog Overview home page. The Owner association widget appears inline as the last block on the page — it is not a modal dialog and has no overlay.

The widget shows a single input — Owner name — and a Send a request button.

Choosing an owner name

Type to search the existing owner directory. As you type, the platform searches the catalog; suggested matches against your username appear under Maybe it's you.

If no existing owner matches the name you typed, the platform creates a new owner with exactly that name when you submit. This is by design — operators want users to be able to bind to a brand-new owner — but it also means typos and casing variants ("John Smith" vs "john smith" vs "John Smith") accumulate in the owner directory.

Recommendation for operators: pick a stable owner-name convention for your deployment (case, whitespace, trailing characters) and communicate it to new users. The owner directory can be cleaned up by an administrator from Management → Owners; an administrator with the OWNER_RELATION_MANAGE permission can also remove individual bindings via Management → Associations → Active associations (see below).

After you submit

When you press Send a request, your request appears on Management → Associations → New requests for an administrator to review.

While your request is pending, the home-page widget is replaced with a Request is being checked message.

If your request is declined

If an administrator declines your request, the next time you reach the home page you see a banner above a fresh request form. You can dismiss the banner with the X button, but the dismissal does not persist — refreshing the page or signing in again brings the banner back until you submit another request.

There is no per-decline-reason surface; the message is the same regardless of why the request was declined. If you need the reason, ask the administrator directly.

Changing or removing your association

Once your association is approved, you have no self-service path to change or remove it. The home-page widget now shows your owner's entities and does not offer a Disassociate or Switch owner action.

To switch to a different owner, or to remove your binding entirely, ask an administrator with the OWNER_RELATION_MANAGE permission to remove the binding via Management → Associations → Active associations (see Removing an existing binding below). After removal, the request form reappears on your next sign-in.

For administrators

The administrative workflow lives at Management → Associations — a top-nav tab with three sub-tabs: New requests (incoming pending requests), Active associations (existing bindings), and History (resolved requests audit).

The Associations tab is hidden from operators who do not hold the OWNER_ASSOCIATION_MANAGE permission.

Approving incoming requests (New requests tab)

The New requests sub-tab lists every open pending request, one row per user. Each row shows:

Column	Source
User name	The signed-in user's OIDC / LDAP username
Owner name	The owner the user requested
Role	Owner roles attached to that owner (if any)
Provider	The auth provider the user signed in with

Per-row Accept and Reject buttons each open a confirmation dialog before writing. Accept records the request as APPROVED and writes the user-owner binding; Reject records it as DECLINED. Both actions are written to the audit channel surfaced on the History sub-tab and require the OWNER_ASSOCIATION_MANAGE permission.

Creating a binding directly (Create association)

In the Associations tab header, operators holding the OWNER_RELATION_MANAGE permission see a Create association button. (The button is hidden for operators without the permission.)

Clicking it opens a modal form with three required fields:

Field	Notes
Owner	Pick from the existing owner directory — this path does not create new owners.
User	Free-text — type the OIDC / LDAP username verbatim. The platform does not verify the username exists in your identity provider; an incorrect username is accepted at the API level and silently produces a binding nobody can sign in to.
Provider	Pick from the list of providers active on this deployment.

On submit, the platform writes the binding directly — there is no intermediate "pending" state and no second-administrator approval. The action is gated by the OWNER_RELATION_MANAGE permission (not OWNER_ASSOCIATION_MANAGE).

Provider is not always a reliable discriminator. The Provider value you pick here (and the Provider column shown across the New requests, Active associations, and History tabs) does not isolate a binding to one sign-in method in every deployment. Both LOGIN_FORM and LDAP logins are stored with an empty provider, so a binding made for one is matched for the other when the username is the same. If your deployment has run more than one auth mode over its lifetime, read the cross-mode user-name collision caveat before relying on Provider to keep two same-named users apart.

Removing an existing binding (Active associations tab)

The Active associations sub-tab lists every approved binding — one row per user-owner pair, with the columns from the New requests tab plus Resolved by (the administrator who approved or created the binding) and Resolved at.

Each row has a Remove button that opens a confirmation dialog reading "User X will stop being associated with owner Y." On confirm, the binding is deleted at the platform tier.

Remove is the only operator-side path to undo any binding — including bindings created through the auto-approve short-circuit (DIRECT_OWNER_SYNC) and through the admin Create association button.

The backend permission gate on this endpoint is OWNER_RELATION_MANAGE. On the current UI, the Remove button is enabled when the operator holds OWNER_ASSOCIATION_MANAGE — so an operator who holds only OWNER_RELATION_MANAGE may see the button but the backend will accept the call, and an operator who holds only OWNER_ASSOCIATION_MANAGE may click the button only to have the backend reject it. Until that inconsistency is resolved, grant both permissions to operators who need direct-bind authority.

After you remove an association

The confirmation dialog describes the local effect only. The wider consequences for the affected user:

• Their My objects view in Activity Feed goes empty.

• Their My view in Alerting goes empty.

• Any ownership-scoped permissions granted through the owner's Role bundles are no longer applied on their next request.

The user is not notified by the platform. If they reach out about empty dashboards or missing access shortly after, an unbind is the likely cause.

Auditing past association requests (History tab)

The History sub-tab lists resolved requests — both APPROVED and DECLINED — in reverse chronological order. The columns are User name, Owner name, Role, Provider, Resolved by, Status, Resolved at.

This sub-tab is read-only. The underlying activity stream is reachable to any signed-in user — operators auditing who-approved-what should be aware that the resolved-association log is part of the platform's read-collaborative posture on Management surfaces (see Permissions → Read access on Management catalogs).

All three write-paths are recorded here, not only the request-approval path. Approving or rejecting a pending request, creating a binding directly with Create association, and removing a binding from Active associations each write a row to the same audit stream, and the History tab shows them all:

Write-path	Recorded as
Approve a pending request	Approved
Reject a pending request	Declined
Create association (admin direct-bind)	Approved
Remove a binding	Declined

A binding created with Create association therefore appears in History as an Approved row, and a removal appears as a Declined row — both attributed to the administrator who performed them. The History tab is a complete record of every association decision on the deployment.

How DIRECT_OWNER_SYNC changes the user-side flow

If a user holds the DIRECT_OWNER_SYNC permission — typically granted to a Policy that fast-paths users mapped from a trusted OIDC group — the home-page request form behaves the same, but on submit the platform short-circuits the administrator-approval step entirely. The owner row is created if it did not exist, the binding is written, and the request is recorded as APPROVED in one transaction. The button label on the form changes from Send a request to Associate to reflect the immediate effect.

The administrator never sees the request on the New requests sub-tab; it lands directly on History as APPROVED with no human reviewer.

Operator caution. Granting DIRECT_OWNER_SYNC is consequential beyond "speeding up admin approval." The permission also composes with the new-owner-on-submit behaviour described under Choosing an owner name — a holder can mint a brand-new owner name and self-bind to it in one POST. Grant it only to principals you also trust to mint owner names (typically a service identity, not an end-user policy). See the Permissions page for the full caveat.