> ## 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.

# Merge tickets

> Merge duplicate tickets into a single primary ticket in Ravenna while keeping every conversation thread alive, and unmerge if you change your mind.

Merge duplicate or related tickets into a single primary ticket so your team works the request in one place. Each merged ticket keeps its own messages and live Slack and email threads, and the whole operation is reversible with unmerge.

## Mental model

Merging folds one or more duplicate **source** tickets into a **primary** ticket by pointer, not by relocation. Each source keeps its own messages and events; it is closed and stamped with a reference to the primary. The primary's timeline renders each source as a collapsible "Merged from" sub-thread, loaded lazily when expanded.

Key distinction: merge vs move vs relations.

| Operation             | What happens                                                                                                                       | Use when                                             |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| **Merge**             | Source closes and points at a primary. Messages stay on the source; the primary shows them as sub-threads. Reversible via unmerge. | Multiple tickets describe the same request           |
| **Move**              | Ticket transfers to another workspace with a new ID. Irreversible.                                                                 | The ticket belongs to a different team               |
| **Parent/sub-ticket** | Tickets stay open and independent, linked hierarchically.                                                                          | Related work items that should be tracked separately |

***

## Merge mechanics

**On merge, for each source:**

* The source is closed and marked merged into the primary (merged-at timestamp and merging user recorded).
* The source's followers and tags are added to the primary.
* Any tickets previously merged into the source are re-pointed at the new primary (chains flatten; every merged ticket points directly at exactly one primary).
* The source keeps all of its messages and events. Its live Slack and email threads keep working, and new replies land on the source.
* Merge events are recorded on both the source and the primary.

**Cross-requester handling:**

* If a source's requester differs from the primary's, all of the source's messages are made internal so the primary's requester cannot see a conversation they were never part of. Each message's original visibility is stamped first so unmerge can restore it.
* The web merge dialog surfaces this as an amber warning before confirming.
* The API accepts `forceInternal` (boolean, optional) to override the default: `true` forces messages internal regardless of requester, `false` keeps them visible even when requesters differ.

**Validation rules:**

* Maximum 10 source tickets per merge.
* The primary cannot itself be a merged ticket. Merge into its primary instead.
* A source that is already merged cannot be merged again.
* The primary is automatically excluded from the source list, and duplicate source IDs are deduplicated.

**List behavior:**

* Merged source tickets are hidden from ticket lists and views by default.
* The **Merged** filter (boolean) opts in: `true` shows only merged sources, `false` explicitly shows only non-merged tickets.

***

## Unmerge mechanics

Unmerge reverses a merge for a single source:

* The source's merge pointer is cleared and it reopens in the **Open** status. Its original pre-merge status is not restored.
* Messages that were made internal during a cross-requester merge are restored to their stamped original visibility.
* Unmerge peels back one merge only. Sources that were flattened onto the primary during an earlier chain-flattening stay merged into the primary.
* Unmerge is available from the "Merged from" block on the primary and from the "Merged into" banner on the source.

***

## API

`POST /tickets/merge`

```json theme={"system"}
{
  "primaryId": "string (required)",
  "sourceIds": ["string (required, min 1, max 10)"],
  "forceInternal": "boolean (optional)"
}
```

`POST /tickets/unmerge`

```json theme={"system"}
{
  "sourceId": "string (required)"
}
```

Both return the affected ticket's `id`, `mergedIntoId`, `mergedAt`, and `mergedById`. After a successful unmerge, `mergedIntoId`, `mergedAt`, and `mergedById` are `null`.

Authentication follows the standard REST API conventions. See [API overview](/api/overview).

***

## Constraints and gotchas

* Email replies to a merged source do not notify the primary's assignee or followers. New activity on a source is only visible by expanding its "Merged from" block on the primary.
* Unmerge restores message visibility but not the source's original status; the source always reopens as **Open**.
* Merged sources disappear from default ticket lists. Use the **Merged** filter to find them.
* Followers and tags copied to the primary during merge are not removed on unmerge.
* Merging requires permission to modify tickets in the workspace.


## Related topics

- [Reverse a ticket merge](/api/ticket/reverse-a-ticket-merge.md)
- [Merge one or more source tickets into a primary ticket](/api/ticket/merge-one-or-more-source-tickets-into-a-primary-ticket.md)
- [Links](/documentation/tickets/links.md)
- [Workflow builder](/documentation/automate/workflows/workflow-builder.md)
- [Overview](/integrations/workday/overview.md)