> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Private tickets

> Restrict ticket visibility to specific roles for HR, security, and confidential requests so only the requester and assigned team members can view.

Private tickets restrict visibility to specific users, ensuring sensitive information stays confidential. Use private tickets for HR requests, security incidents, personal information, and other confidential matters.

## Mental model

A private ticket restricts the entire ticket's visibility to users with specific roles. Unlike a regular ticket (visible to anyone in the workspace), a private ticket is only accessible to the requester, assignee, followers, approvers, and workspace members/admins.

Private tickets are different from private notes. A private ticket hides the entire ticket from unauthorized users. A private note hides a single message within an otherwise visible ticket.

***

## How tickets become private

Two mechanisms create private tickets:

1. **DM-created tickets**: Any ticket created from a Slack DM with Ravenna is automatically private. This cannot be overridden.
2. **Private forms**: When a form has the private setting enabled, all tickets created with that form are private by default.

When a private form is triggered in a public Slack channel, the system automatically redirects the conversation to the user's DM with Ravenna. A confirmation message is posted in the public channel with an embedded deep link that opens the requester's DM with Ravenna, so they can reach the private conversation in one click. All subsequent interactions happen privately.

***

## Access rules

| Role              | Access to private tickets       |
| ----------------- | ------------------------------- |
| Requester         | Always                          |
| Assignee          | While assigned                  |
| Followers         | While following                 |
| Approvers         | While assigned as approver      |
| Workspace members | Always (within their workspace) |
| Workspace admins  | Always (within their workspace) |

Access is dynamic. Adding someone as a follower grants access immediately. Removing them revokes access unless they qualify through another role.

Important: @mentions do not grant access. Mentioning a user in a private ticket does not add them as a follower or grant visibility. You must explicitly add them to a role.

***

## Public thread protection

When a ticket is privatized, the public request thread receives a prominent notice that the conversation has been moved to a private ticket. If a user replies in this public thread, Ravenna sends an ephemeral warning to that user, directing them to continue in DMs. This warning is sent once per user per thread — tracked via metadata on the Slack thread so repeat replies do not trigger additional warnings.

The flow:

1. A ticket is converted to private (via DM creation, private form, or 🤫 emoji).
2. The public request thread gets a `:lock:` notice indicating the conversation moved to private. When the ticket originated from a private form in a public channel, the notice also embeds a deep link to the requester's DM with Ravenna so the requester can open the private conversation directly from the public thread.
3. If any user posts a reply in the public request thread, Ravenna sends them an ephemeral message warning them to use DMs instead.
4. The user's ID is stored in the thread metadata (`warnedUserIds`) so they are only warned once.
5. The reply is silently dropped — it is not processed as a ticket message.

This prevents accidental information leakage in public channels when users do not realize the ticket has been made private.

***

## Constraints and gotchas

* DM-created tickets are always private. There is no way to make a DM-created ticket public.
* Private forms create private tickets even when triggered from public Slack channels. The system handles the redirect to DM automatically.
* Workspace members and admins always have access to private tickets in their workspace. If you need to restrict visibility from workspace members, private tickets alone are not sufficient. Consider using a separate workspace with restricted membership.
* Access changes are immediate. Adding or removing a follower/approver/assignee updates visibility instantly.
* @mentions in private tickets do not grant access or send notifications to users who lack access.
* Replies in the public request thread of a private ticket are not processed. The user receives a one-time ephemeral warning to continue in DMs.