# Messaging best practices Glue is built around a simple insight: most conversations start casually but evolve into something more structured. That's why **threads are the core unit of conversation** in Glue, not channels. ## Start with threads **Default to threads for most communication.** Unlike channels where conversations compete for attention in a single stream, each thread in Glue is a focused, organized space that adapts as your work evolves. #### When to use each message type | Message Type | Use For | Example | | -------------------- | ------------------------------------------------- | ----------------------------------------------------------------------- | | **Thread** (default) | Any work discussion, even casual ones | "Quick question about the API", "Let's plan Q4", "Bug in checkout flow" | | **Group Chat** | Announcements, time-sensitive alerts, social chat | "Office closed Monday", "Happy birthday! 🎉" | | **DM** | Private, sensitive one-on-one conversations | Personal matters, confidential feedback | **Rule of thumb:** If there might be a reply or follow-up, start a thread. Group chat is for information that stands alone. #### Why threads work better **Threads vs. Slack channels:** * **Focused** - Each discussion has its own space, not competing in a crowded channel * **Flexible** - Add or remove people as conversations evolve * **Organized** - Clear titles make conversations searchable and easy to find * **Intentional** - People are included because they're relevant, not "just in case" > **💡 Key difference:** In Slack, you @ mention people in channels. In Glue, you **add people as thread participants**. They'll see all messages without individual mentions, and it's clearer who's actively involved. *** ## Creating effective threads #### Write clear thread titles Thread titles are how you'll find conversations later: ✅ **Good:** "Q4 Marketing Budget Review", "Bug: Safari login failure", "Decision needed: Holiday schedule" ❌ **Avoid:** "Question", "Quick chat", "Thoughts?" #### Start small, grow organically Begin with whoever needs to be involved: ``` "Hey @Sarah, quick question about the API design" ``` Add more people as the conversation evolves: ``` "Good feedback—adding @Dev Team for their input" ``` Create new threads when topics shift: ``` "This is getting into deployment—I'll create a separate thread for that" ``` #### Provide context for async work * Include relevant background upfront * Attach necessary files or links * Set clear expectations: "Need input by Friday EOD" * Use @Glue AI to summarize long threads for people catching up *** ## Writing clear messages #### Make messages scannable * **Bold** action items and important information * Use bullet points for lists of 3+ items * Break long messages into short paragraphs (2-4 sentences) * Front-load the most important information **Before:** "So I was thinking about the presentation and noticed the data changed—can you update it?" **After:** "Can you update the presentation deck? The Q3 data has changed." #### Be specific about what you need * ❌ "Thoughts on this?" * ✅ "Does this pricing work for enterprise clients?" * ❌ "Can you look at this when you get a chance?" * ✅ "Can you review this by Thursday EOD?" *** ## Using mentions effectively #### Respect attention Every @ mention sends a notification. Use them intentionally: **DO mention when:** * You need someone's specific input or action * You're asking a direct question * You're adding someone new to a thread **DON'T mention when:** * They're already a thread participant (they'll see it anyway) * It's FYI information without action needed #### Add people to threads, don't just mention them **Better approach:** Add people as thread participants so they see all messages, not just the one where you mentioned them. #### Use group mentions sparingly Only @ mention entire groups for: * True emergencies or critical announcements * Time-sensitive information everyone must see immediately **For most situations:** Create a thread with the group instead—it's visible but less disruptive. #### Link to threads for context Instead of re-explaining, reference related threads: "See the approach we decided on in @Design Review Thread" *** ## Migrating from channel-based thinking If you're coming from Slack, shift your mental model: > **Old:** "I'll post this in #engineering"\ > **New:** "I'll create a thread with the engineers who need to weigh in" > **Old:** "Is there a channel for this?"\ > **New:** "I'll start a thread and include the right people" > **Old:** "Should I DM or post in the channel?"\ > **New:** "I'll start a thread—it's the most flexible option" Think in **conversations**, not **locations**. *** ## Quick reference #### Before sending a message, ask: * [ ] Should this be a thread? (If there might be discussion → yes) * [ ] Is my thread title specific and searchable? * [ ] Have I included the right people as participants? * [ ] Is my message clear and scannable? * [ ] Am I being specific about what I need? * [ ] Are my @ mentions necessary? #### Common scenarios **"Quick question about your code"** → Thread (even "quick" questions often need follow-up) **"Office closed tomorrow"** → Group Chat (pure announcement) **"What do you think about this approach?"** → Thread (discussion needed) **"Can someone help with this bug?"** → Thread (keeps troubleshooting organized) **"Want to grab coffee?"** → DM (personal and social) *** **Remember:** When in doubt, use a thread. It's easier to start organized than to migrate a messy conversation later. **Learn more:** * [Threads](/conversations/threads.md) - Deep dive into thread features * [Mentions and notifications](/conversations/mentions-and-notifications.md) - Master @ mentions --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.glue.ai/conversations/messaging-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.