> ## Documentation Index > Fetch the complete documentation index at: https://docs.forge.ai/llms.txt > Use this file to discover all available pages before exploring further. # Ownership > Assign governance work to the people and teams responsible for each policy, AI system, or user group. Ownership distributes AI governance decisions across the organization. Instead of sending every request to a central security team, Forge can route matching work to the employees or teams who understand the relevant policy, AI system, or business group. Owners can review their assigned work through Responses without receiving broad administrative control over unrelated governance activity. ## What you can assign An ownership assignment connects one governed target to one or more owners. | Target | Example use | | ---------- | ------------------------------------------------------------------------------------------------ | | Policy | Route requests created by a particular access or content policy to its policy owner. | | AI system | Route activity involving a particular AI product to the team responsible for that system. | | User group | Route requests from a directory group to its manager, application owner, or governance delegate. | Owners can be individual directory users or directory groups. Ownership does not change the target user's role, grant permanent access, or automatically approve a request. ## How requests are routed When Forge creates a governance request, it attempts to find the most specific matching owner in this order: 1. An owner explicitly selected by the originating workflow. 2. The owner assigned to the matched policy. 3. The owner assigned to the affected AI system. 4. The owner assigned to the requester's directory group. 5. The organization-wide Responses queue when no owner matches. The selected assignment and routing reason are stored with the request. This keeps the decision understandable even if ownership settings change later. A request without a matching owner is not lost. Members with policy-management access can review it from the organization-wide Responses queue. ## Add an owner 1. Open **Settings**. 2. Select **Ownership**. 3. Select **Add owner**. 4. Choose whether the assignment applies to a policy, AI system, or user group. 5. Select one or more governed targets. 6. Select the users or groups who should own matching work. 7. Configure optional notifications. 8. Select **Save owner**. The same set of owners can be assigned to multiple targets in one operation. Users and groups must be available in the Forge directory before they can be selected. Assigning ownership does not independently grant Console access, so owners must also have the appropriate Forge access for the review workflow. ## Notify owners Each ownership assignment can use one or more notification methods: | Method | Behavior | | --------------------------- | ------------------------------------------------------------------------- | | Slack channel | Posts matching requests to a selected channel. | | Slack direct message | Messages selected owner users whose Forge identities are linked to Slack. | | Email owners | Emails selected users and the users in selected owner groups. | | Additional email recipients | Includes specific addresses that are not assignment owners. | | Console only | Creates the assigned work without sending an external notification. | Slack channel and direct-message delivery require a connected Slack workspace. Direct messages also require the selected directory user to have a resolved Slack identity. Notification preferences affect delivery only. They do not change who is authorized to review the request. See [Notifications](/secure/notifications) for organization-wide event preferences and delivery verification, including Slack, email, and the organization notification webhook. ## Review assigned work Owners review matching governance work from **Responses**. The **Mine** view contains requests routed to the current owner. Authorized policy managers can use **All** to review organization-wide requests, including requests that could not be assigned automatically. Depending on the workflow, a request can provide actions such as: * Approve the requested access. * Deny the request with a reason. * Approve a supported scope or duration. * Authorize a supported remediation. * Review the resulting grant or session control. Forge checks the current request state, assigned owner, and permitted decision scope before applying a response. ## JIT Viewing [JIT Viewing](/secure/jit-viewing) uses Ownership to distribute requests for temporary session-content access. When the session user belongs to a directory group with an active owner assignment, Forge routes the request to that group owner. If no owner matches, policy managers can still review it from the full Responses queue. This allows business teams to govern access to their employees' session content without giving them permanent access to every session in the organization. ## Changes and audit history Ownership settings can be updated as responsibilities change. Existing governance records retain their assignment and decision history. Forge records ownership and governance activity, including: * Ownership assignment changes. * The target and resolved owners. * Request routing and reassignment. * Notifications and delivery outcomes. * Approval or denial decisions. * The reviewer and approved scope. Use the [Audit Log](/secure/audit-log) to inspect administrative changes and the [Responses](/secure/responses) workspace to review request history. ## Related pages Require temporary approval before sensitive session content can be viewed. Review assigned requests, decisions, grants, and session controls. Configure governance, Shadow AI, and Registry notifications. Control organization permissions and administrative access.