> ## 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).
* A public system message is posted on the source linking the primary ("This ticket has been merged into ..., further updates will be shared there"), authored by the workspace bot rather than the acting user. The primary also gains a linked ticket named `Merged: <source display ID>`, which unmerge deletes.
* The source's followers and tags are added to the primary. A source requester who differs from the primary's requester is added to the primary's followers.
* Active SLAs on the source stop. The merge event is handled as a terminal event, the same as archive and delete.
* Time-based automation skips merged sources: inactivity auto-close, reminder policies, and reopen-on-reply all check the merge pointer before acting, so a reply on the source leaves it closed.
* 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.
* A merged ticket is immutable. Editing its fields or moving it to another channel fails with `TICKET_MERGED_IMMUTABLE`. Unmerge first.
* 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)
- [Expenses and invoices](/guides/playbooks/finance/expenses-and-invoices.md)
- [Workflow builder](/documentation/automate/workflows/workflow-builder.md)