From Workflow Actions to Agentic AI: Evolving HubSpot × Slack

Designing Slack-native interactions that bring complex CRM workflows and AI capabilities into a cohesive cross-platform experience

Tl;dr

Customer problem

HubSpot customers work in Slack but frequently need to switch to HubSpot to access customer context, uncover important business insights, and take action. This fragmented experience interrupts their workflows and makes it harder to act on information where they're already working.

Business problem

Slack is a key surface for HubSpot customers and represents an opportunity to increase Breeze adoption, improve AI feature discoverability, and deepen engagement with HubSpot features. Slack-connected customers also represent meaningful monthly recurring revenue (MRR) and higher integration usage corresponds to higher retention.

Solution

In order to answer the question 'How might we help sales teams close deals more effectively?' I evolved the HubSpot × Slack experience starting with manually configured actions on notifications to AI-powered, contextual interactions with Breeze Assistant, adapting web patterns to create a cohesive AI experience across platforms.

Project evolution

1

Discover: Understanding how customers work in Slack

  • Introducing the HubSpot x Slack integration
  • Foundational customer research

2

Design: Enable actions in Slack

  • Designing action enabled notifications
  • Adoption and usage metrics

3

Evolve: Bringing Breeze into Slack

  • Insights from customer conversations
  • Prompt exploration
  • Component & Interaction design
  • Cross-platform AI design challenges

4

Reflect: Outcomes & learnings

  • Proposed validation
  • Key takeaways for designing cross-platform AI features

Discover: Understanding how customers work in Slack

Introducing the HubSpot x Slack integration

The HubSpot × Slack integration enables customers to receive CRM notifications, share information, and collaborate on customer relationships directly within Slack.

However, while customers could receive information in Slack, taking action often required switching back to HubSpot. We wanted to understand how we could make the integration more actionable and help sales reps close deals more effectively.

Foundational customer research

As part of an initiative to make HubSpot's collaboration integrations more actionable, the team was exploring ways for customers to take action directly from Slack notifications.

I conducted foundational research with 8 sales professionals using HubSpot's Slack and Microsoft Teams integrations to understand their deal management workflows and identify opportunities for actionability.

Through semi-structured interviews and affinity mapping, I explored:

  • How sales reps used collaboration tools throughout the deal-closing process.
  • What information they needed and which actions they wanted to take.
  • What prevented them from making better use of existing integration capabilities.

Finding 01 - Customers wanted meaningful information, not more notifications.

7 out of 8

reported receiving redundant notifications for actions they'd already performed in HubSpot. Some customers ignored notifications because of the volume and repetition.

Opportunity

Prioritize relevant, actionable information rather than adding to notification fatigue.

Finding 02 - Customers needed to act on information, but not every action belonged in Slack.

Sales reps wanted to perform lightweight actions directly from their notifications, including:
Completing tasks, Making basic deal updates, Accessing richer deal information, Initiating customer outreach

However, some preferred HubSpot's richer interface for more complex workflows.

Opportunity

Enable high-value, lightweight actions in Slack while preserving HubSpot for more complex workflows.

Finding 03 - Customers weren't discovering the integration's existing capabilities.

Many participants hadn't configured the integration themselves and were unaware of features already available to them, including contact sharing and task-related functionality.

Opportunity

Improve contextual discoverability and make useful capabilities accessible within existing workflows

"The only challenge I had is okay now that I have it installed what is it supposed to show? What am I supposed to learn out of this integration?"

Customer [name redacted]

VSB B2B Department Lead

Design: Enable actions in Slack

Designing action enabled notifications

Based on the research, I identified core follow up tasks that a sales rep would want to perform when receiving a HubSpot notification about a deal in Slack

  • Customer outreach through calls directly from the tool
  • Customer outreach through email, with smart suggestions (e.g., “last time you sent template 1 to the customer, would you like to send template 2?”)
  • Checking off a task / creating a follow up task
  • Updating basic properties of the deal
  • See a more meaningful snapshot of a deal (viewing the deal in HubSpot)

There were multiple ways notifications flowed from HubSpot into Slack as supported by the integration, but research showed that the notifications configured to send to Slack through HubSpot workflows were the most meaningful, as they had been intentionally set up according to triggers that mattered for the sales teams. So the corresponding design decision was to have a way for users who configure these workflows to append actions to their workflow notifications - moving from just passively viewing information in Slack to acting on them.

This example shows setting up a workflow for a deal that has been inactive for a week being sent to the Slack channel. To this, I designed the follow up actions that would be appended - in this example, the user chooses customer outreach as the follow up action when a stale deal notification is sent to the channel.

Sales rep experience in Slack

Once these notifications are configured through workflows, what do the sales reps then see in Slack? Below are the snapshots of how the different actions would be experienced within Slack. For this, I designed elements in Slack's Block Kit builder. This experience balanced taking lightweight actions in Slack and redirecting to HubSpot where appropriate, as substantiated by my research.

Updating the properties from the notification
Logging a call made to the deal
Creating a follow up task on the stale deal
Creating a note for the deal
Immediate outreach - making a call
Immediate outreach - drafting an email

Adoption and usage metrics

25%

of portals using the Send Slack Notification workflow action added actions to their notifications, roughly 6,000 of 24,000+. Actions were an optional addition on top of the existing notification.

20k

clicks a month across the action buttons and Slack shortcuts, mostly tasks, notes, and email or call outreach

Figures are approximate and come from HubSpot’s internal product analytics. Click counts include a small volume from separate Slack shortcuts and can’t be split from notification buttons.

Actionable notifications made Slack a place where reps could act on a deal. The next question was bigger: what if they could simply ask?

Evolve: Bringing Breeze into Slack

By 2025, HubSpot’s investment in AI opened a new opportunity. Breeze Assistant was being designed for the web experience, and bringing it to Slack would help reps get customer context and take action where they already work, while supporting broader goals around AI adoption and engagement.

I embedded with the Breeze team to own the Slack side of that work. They were deep in the web experience but didn’t have much context on Slack as a surface. I had 2+ years of designing the HubSpot × Slack integration which meant I knew how reps used it and what they needed, where the integration already helped, and where the overall user experience would be impacted.

What I brought to the team

  • A customer lens. My earlier research showed that reps wanted fewer, more meaningful notifications and lightweight actions, with HubSpot reserved for complex work. That research was scoped to notifications, but the same principles shaped how I approached Breeze in Slack.
  • Platform knowledge. I understood the constraints of Slack’s Block Kit, threading, and shared channels, and what the integration already offered today.
  • Cross-platform ownership. I was responsible for keeping Breeze coherent across web and Slack, and for flagging where a direct port wouldn’t work.
  • A prototype-first way of working. AI features were changing quickly and had to land on two platforms, so specs went stale fast. Instead, I used Block Kit Builder’s “Send to Slack” to send real messages to engineers, and they sent me tests from our test Slack workspace. We reviewed what the feature looked like in Slack, not what a document said.

Insights from customer conversations

The Breeze team’s PM spoke with customers about using Breeze in Slack as it was. Most of the pain points were about answer quality: Slack wasn’t delivering the rich answers people got on the web, which limited how useful they found it. For example, instead of showing record snapshots and histories in a format people could scan, Breeze in Slack returned a wall of text. Other pain points were around completing flows in Slack, for example with artifacts, invoking agents and so on.

The design challenge

How might we translate Breeze Assistant's capabilities into Slack's interaction model while maintaining a cohesive experience across platforms?

Prompt exploration

I started with the prompts sales teams (reps and managers alike) actually ask, like meeting prep, deals with no next step, and pipeline risk, and ran each in Breeze on web and in Slack. AI doesn’t answer the same way twice, so I ran each prompt multiple times and designed for the patterns that kept showing up, not for any single response.

Below is a snapshot of some of the prompts I explored, with notes comparing the experience on web and in Slack and patterns I found across prompts.

"Prep me for my 1:1 with Maranda Thompson based on her activity and deal progress"

Breeze on web
Breeze on Slack

1. On web, the deal details are presented as a card with a linked name, labeled fields and show the stage as a badge to draw the user's attention. In Slack it became a column of bold label/value rows, and the stage (“Qualified To Buy”) is plain gray text, so the one thing a user scans for first no longer stands out.
2. Each list of recent activity has an activity icon, a clickable record name, and a readable date on web. In Slack the names come through as raw [CRM_RECORD:…] tokens, the icons are gone, and the timestamps are raw.

"Where's the revenue risk in my pipeline this quarter?"

Breeze on web
Breeze on Slack

1. The list of deals is shown as a card on web. On Slack it is unformatted.
2. Reports that could be viewed on web were inaccessible on Slack.
3. While the next steps stand out on web due to the overall structure and flow of Breeze's answer, on Slack they get lost within the text.

"Show me my hottest leads this week"

Breeze on web
Breeze on Slack

1. On web, the record details are presented as a card with a linked name, labeled fields and show the stage as a badge to draw the user's attention. In Slack it became a column of bold label/value rows, and the stage is plain gray text, so the one thing a user scans for first no longer stands out.

"Build me a list of accounts with no activity in 90 days"

Breeze on web
Breeze on Slack

Lists of records are shown as a report on web, whereas any lists do not render in Slack.

"Log my call with Rebecca at Acme - she's looping in procurement"

Breeze on web
Breeze on Slack

1. Clarifying questions asked by Breeze (Ask User Question) showed an interactive experience on web, but in Slack the user had to rely on the conversation - while this doesn't prevent them from proceeding it degrades the experience, especially compared to emerging design patterns for LLMs.
2. Any activity that is created is formatted in a card on web, and reads as a block of text on Slack.

"Move the Acme deal to negotiation stage, close date is end of the month"

Breeze on web
Breeze on Slack

1. The same clarifying-question gap has a sharper cost here: the user shouldn’t have to type the exact deal name or say “the first one.” One tap should do it.
2. Any answers given by the user for an Ask-User-Question (AUQ) were logged as a Q&A in the conversation on web, whereas on Slack the user didn't have the trace of what they submitted unless they read through the conversation again.
3. Human-in-the-loop: an agent should pause and ask for confirmation before changing a record. On web it does. In Slack it was missing.

Component & interaction design

I proposed four components to address the patterns I found, each defined by when it applies and not by how it looks.

Record / activity card

Any record or completed activity is shown as a card of property - value pairs, with the most important detail highlighted in the subtext and the record or activity name linking to the actual record in HubSpot. It’s a base that variations build on, like using the same card to bring attention to recommendations shown by Breeze.

Deal details displayed in a record card, with the stage as subtext. The name acts as the CTA to open the record in HubSpot.
When an activity is recorded, the activity name and relevant details are displayed in a card. The name acts as the CTA to open the activity
Recommended - the card layout draws the user's attention to the main recommendations provided from Breeze's output

Interaction history

Any list of past interactions or related activity is shown as a card of dated items, each with an icon, a bold title, a one-line description and a timestamp, so it can be scanned at a glance and linked back to the record in HubSpot.

Relevant CRM history shows the last 5 activities that happened for that record to prep for a meeting
Recent logged activity shows up when a record needs to be summarized for the user

Data tables and lists

Any list of records is shown as a data table, with the most important properties as columns and each record name linking to the actual record in HubSpot. On web, the same kind of list appeared as plain text, a report artifact or a card, depending on the response, so I proposed one consistent table for Slack.

The data table supports sorting, pagination and opening interactive elements.
Expanding the table shows the full list of records, up to 200 rows based on Slack’s limits. Beyond that, Breeze generates a second table, which matters for the large lists reps often ask for, like open deals or stale accounts.

Ask User Question flow

When Breeze needs more information to continue, it asks in a card. The user can pick an option or just type an answer, and the card then becomes a record of the question and the answer. No answer is required, matching Breeze on web, so a user can skip any question and Breeze continues with what it has.

The user picks one of the options and clicks Submit. The “Input needed” card is replaced by a “Your input” card that records the question and the answer, and Breeze continues.
The user can also type in the regular message box, and that text is treated as the answer to the question. The card is replaced by the same “Your input” card, so the conversation keeps a record either way.

In my testing on web, Breeze asked follow-up questions one at a time, and I couldn’t get it to ask several together. I did see other AI assistants, like Claude, present multiple questions as a carousel, with one question on screen at a time. Slack doesn’t support that pattern for inputs, so I designed the card to hold several questions at once, with a single Submit. The compromise is the message box. With several questions on screen, it’s unclear which one a typed answer belongs to, so Breeze has to read the text in context and assign each comma-separated part to the question it fits. Anything left unanswered is skipped.

The user answers each question by selecting options and clicking Submit. The card then becomes a record of every question and answer.
The user can type one message instead. Breeze assigns each comma-separated part to the question it fits, and the card becomes the same record.

Cross-platform AI design challenges

Design challenge 1: Handling AI artifacts

Breeze Assistant generates rich, interactive content that users can iteratively refine, but these experiences don’t always translate into Slack’s Block Kit components. The challenge was determining which AI-generated artifacts could be meaningfully displayed and edited in Slack, and when to direct users to HubSpot for a richer experience, while preserving context, usability and cross-platform consistency.

Native artifacts (Code, markdown, CSV, TXT)

Code snippet generated by Breeze in Slack

Simple artifacts, like code snippets, tables and markdown, display natively in Slack. Slack’s limits (usually on characters) mean anything longer is truncated, with a link to open the full artifact in HubSpot.

Richer artifacts (PPT, documents, reports)

Richer artifacts, like documents, presentations and reports, get a link to edit them in HubSpot, followed by a second message with a static PDF snapshot, so reps can review them without leaving Slack.

The trade-off was noise. If a user keeps refining an artifact from Slack, every revision follows with the edit link and the latest snapshot. That adds messages, but I decided it was more useful than forcing people back to web just to see the latest version.

The first pass from Breeze shows a snapshot with a file attachment and a link to the artifact on HubSpot.
Each revision from Slack posts the updated edit link with a new version and a new PDF snapshot.

Design challenge 2: Privacy of information shared cross platform

When a sales rep uses Breeze Assistant in HubSpot, the customer information returned is visible only to them. Bringing Breeze into Slack introduced a new privacy challenge: what happens when a user queries customer information in a shared channel where other members may not have permission to access that data in HubSpot? This raised important questions about how AI-generated responses should be displayed, who should be able to see them, and how to prevent sensitive customer information from being inadvertently exposed.

An example: Scheduled prompts

Breeze on web lets users schedule prompts that run at a set time. Bringing that to Slack started as a small idea: let users create a scheduled prompt in natural language from Breeze in Slack. Even at that scope, it opened up harder questions:

  • Active use versus automation. Legal’s view was that someone actively using Breeze in a channel understands that others can see the response, because of disclaimers at the start. A scheduled prompt is messier. What if the person who created it leaves? What if it runs for months and the people in the channel change?

It also raised questions about who can create prompts, where they’re managed (in the Slack app, in HubSpot's Slack settings page, or HubSpot notification pages) and general visibility across these surfaces so that users don't hit a dead end.

A user creating a scheduled prompt in Breeze through natural language, Breeze asks follow up questions and then displays the saved prompt which can be managed within Breeze on Web
A user creating a scheduled prompt in Breeze through an explicit UI action, selects the frequency and time which can be managed within Breeze on Web

What I proposed

Footer with a link to open and manage the scheduled prompt in Breeze on Web

I argued that trust and privacy should lead: be transparent about where automated information comes from, and give customers an easy way to opt out. To start, I suggested limiting scope to creating prompts through natural language from Breeze in Slack, with every delivered message carrying a footer that says where it came from (“Scheduled prompt sent via Breeze”) and links to the saved prompt on web where it can be managed, and also linking to Breeze on web from the Slack settings and notification pages in HubSpot, so users don’t hit a dead end. I proposed measuring it through qualitative customer feedback and clicks on the footer link.

I left before this was finalized, so this reflects my proposal, not what shipped.

Design challenge 3: Visibility of notifications and messages

Unlike HubSpot's web experience, Slack is a collaborative environment where messages and notifications compete for attention. The challenge was maintaining a healthy signal-to-noise ratio by determining when Breeze interactions should be visible to an entire channel, contained within threads, or shown privately - without overwhelming users or disrupting existing conversations.

I treated this as a principle, not a single decision. Whenever the team had to choose where a Breeze message should land (the channel, a thread, a DM, or an ephemeral message only the asker sees), I asked: who needs to see this, and what does it cost everyone else if they do?

‍Where I’d push further: audit every Breeze message type and decide its home deliberately.

A failed reply is useful to others in the channel, so anyone viewing the thread can trace it.
The account selector posts in the thread but only matters to the person setting it up, so it could be ephemeral.

Reflect: Outcomes & learnings

Proposed validation

I left before these designs could be tested with users, so this is what I’d measure first.

Quantitative metrics
  • Adoption and retention: how many Slack users try Breeze in Slack, and how many come back within 30 days.
  • Answer quality: thumbs up and down over time, and how they change after each quality improvement.
  • Follow-up questions: how often the question card is answered, skipped or ignored.
  • Notification load: mutes and opt-outs among Breeze in Slack users, to confirm it isn’t adding noise for reps who were already overwhelmed.
Qualitative feedback
  • Task-based sessions with reps and managers, using the prompts from my exploration (meeting prep, deals at risk, logging activity), to see what they expect and where they hesitate.
  • Trust and visibility: whether people understand who can see an AI answer in a channel versus a DM, by asking them to explain it back.
  • Scanning the cards: whether reps can find what they need in a record or history card without opening HubSpot.

Key takeaways for designing cross-platform AI features

Design for trust
With AI, trust decides whether people adopt a feature at all. AI pulls from real data, and where the answer lands decides who sees it, which matters even more across platforms. Make visibility obvious and give people control over it.
Retrofit with care
Adding AI to a product people already rely on means protecting what already works. AI makes it easy to generate more, but reps were already overwhelmed by Slack notifications, so managing the load mattered as much as the answer.
Scope the control
The experience of creating and editing AI-generated material cross platform doesn't carry over one to one. Decide up front how much control each platform should offer, such as light edits in place and heavier work handed off, and make that boundary clear to the user.