Relation between conversation_parts.part_type and conversation_parts.status of a conversation | Community
Skip to main content
Answered

Relation between conversation_parts.part_type and conversation_parts.status of a conversation

  • October 28, 2025
  • 2 replies
  • 83 views
K

I have discoverd instances in conversation_parts where the conversation_part.status is in a snooze state even if the part_type is a comment type. How is this possible, because according to this article (https://www.intercom.com/help/en/articles/6564538-snooze-a-conversation) 

“If you send a reply message in a 'snoozed' conversation that's assigned to you, it will not automatically 'unsnooze'/reopen the conversation.”

“If someone else sends a reply, adds a note, or updates an attribute in a 'snoozed' conversation assigned to you, it will be automatically 'unsnoozed'/reopened.”

 

So How come a conversation remain in an snoozed state even after there is a comment from either admin or customer?

A comment part type is defined as: Standard reply from customer or admin to a conversation (defined at: https://developers.intercom.com/docs/references/1.4/rest-api/conversations/conversation-part-model#conversation-part-types) 

 

These are the part-types appearing with snoozed state

1    comment
2    conversation_attribute_updated_by_admin
3    conversation_sla_paused
4    merged_primary_conversation
5    operator_workflow_event
6    note
7    participant_added
8    participant_removed
9    ticket_state_updated_by_admin
10    conversation_sla_unpaused
11    priority_changed
12    entity_linked
13    forwarded
14    conversation_sla_target_missed
15    title_changed
16    merged_secondary_conversation
17    conversation_tags_updated
18    conversation_sla_applied_by_rule

 

Best answer by Paul Byrne

Hey ​@Kartikeya Vishnoi Paul here from support engineering to help you out 🤝 

A comment row being persisted does not guarantee the conversation’s snoozed state was updated. The unsnooze is implemented as a separate backend event/worker flow: an explicit unsnoozed event part must be created or the unsnooze worker must run to update the message thread state.

 

In practice this means one of three things happened: 1) the reply was from the assignee so by design it didn’t unsnooze. 2) The reply was created by an operator/bot/workflow that does not trigger the “someone else” unsnooze rule. 3) The comment saved but the asynchronous unsnooze/state-change work did not complete because the unsnooze worker was delayed or errored.

I reviewed the Unsnooze command and the unsnooze workers runbook which shows the unsnooze is a separate backend flow. Here are the exact checks I recommend you run (SQL + worker DLQ checks) and the command to re-drive the unsnooze DLQ if you have platform access. Evidence collected: Unsnooze command, unsnooze runbook, conversation part model

2 replies

Paul Byrne
Intercom Team
Forum|alt.badge.img+6
  • Paul ByrneIntercom Team
  • Intercom Team
  • Answer
  • October 30, 2025

Hey ​@Kartikeya Vishnoi Paul here from support engineering to help you out 🤝 

A comment row being persisted does not guarantee the conversation’s snoozed state was updated. The unsnooze is implemented as a separate backend event/worker flow: an explicit unsnoozed event part must be created or the unsnooze worker must run to update the message thread state.

 

In practice this means one of three things happened: 1) the reply was from the assignee so by design it didn’t unsnooze. 2) The reply was created by an operator/bot/workflow that does not trigger the “someone else” unsnooze rule. 3) The comment saved but the asynchronous unsnooze/state-change work did not complete because the unsnooze worker was delayed or errored.

I reviewed the Unsnooze command and the unsnooze workers runbook which shows the unsnooze is a separate backend flow. Here are the exact checks I recommend you run (SQL + worker DLQ checks) and the command to re-drive the unsnooze DLQ if you have platform access. Evidence collected: Unsnooze command, unsnooze runbook, conversation part model

K
K

Understood, Thanks for the answer ​@Paul Byrne, 

Terms & ConditionsAccessibility statement