Workflow embedding: Carry the value, don’t announce it

Look at what your Slack integration actually does. Usually the answer is that it posts a message saying something happened, with a link back to your app.

That is not embedding. That is an announcement, and it makes you one more source of interruption in a channel that already has too many. The user still has to leave, still has to log in, still has to find their place. Every notification is a request to context-switch, and requests to context-switch get muted.

The distinction that matters is whether the integration carries the value or merely reports it.

Where to embed, and why the boring surfaces win

The instinct is to build for whichever integration customers request loudest. That is a losing race: Zapier alone advertises connections to more than 9,000 apps, so the set of integrations you could build is effectively unbounded and no backlog will ever be finished.¹ The better rule is to build where the work already happens, which is a different and far more stable question.

Email and calendar are the surfaces worth checking first, because if your users live anywhere all day it is usually one of them. They are also unglamorous, which is why they are underbuilt. A scheduling link in a signature (Calendly, Cal.com and SavvyCal all work this way) reaches people who have never heard of the product and requires nothing of the sender after setup, which is why it doubles as acquisition.²

Team chat is where the work is discussed rather than done, which makes it excellent for delivering the value itself in place and terrible for notifications. It is also where the strongest version of this pattern lives: post the output there by default, without the user choosing to share it. Granola, the meeting-notes tool, can post the enhanced summary straight to the channel, which is useful to the person who made it and a demonstration to everyone else who reads it, which turns each use into an impression on people who never signed up. It is the highest-leverage place to be present and the easiest place to become noise.

There is a second way to deliver value in place, easy to miss because it produces no visible output at all: doing the tedious part for them. Logging the email, capturing the meeting, filing the record, updating the status. These are the steps users skip when they have to do them by hand, which means the data is incomplete, which means the product is less useful, which is a loop you can break from inside the tool where the work already happened. A product that quietly maintains its own data quality becomes very hard to remove.

The browser is where everything else happens. An extension that appears in the text fields you already type in is the most complete form of this pattern available to a small product, and it is why a tool like Grammarly works: nobody has to remember it.

The command line and the editor, for developer tools, are the equivalent of email. A tool invoked from where code is already being written has no adoption cost at all.

One thing to aim for while choosing where to embed: an improvement large enough that colleagues notice. If the difference between using you and not is visible across a desk, the question “what are you using for that?” does the marketing, and being present in a shared surface is what makes it visible in the first place.

What these surfaces share is that the user never chooses to open you. The choice was made once, at setup, and then the work does the triggering.

What is workflow embedding?

Workflow embedding means placing your product inside a tool people already have open, so that using it requires no decision to visit you. Done properly the trigger comes from the work itself, not from your notification schedule, which is why this is the pattern that applies to the widest range of products: it asks nothing of the user’s memory and does not depend on them wanting to visit you daily.

There are three depths, and they are not close in value.

A recording that can be watched inside the chat message is value in place: the recipient gets the thing they were sent without going anywhere, even if the sender’s own tools (comments, analytics, transcripts) still live in the product. An approval you can grant from the message is action. A message telling you an approval is waiting is a notification, and it is the depth most integrations stop at because it is the cheapest to build.

Set it up once, then never again

The failure mode specific to this pattern is a setup cost that recurs. An integration that needs re-authenticating, reconfiguring per project, or re-enabling after every update is worse than no integration, because it teaches people that the connection is unreliable and they route around it permanently.

Two consequences worth designing for:

Default to on, and default to sensible. An embedded surface that arrives silent and needs configuration will stay silent. Users rarely open the settings page you built.

Fail quietly and recover automatically. When a token expires or a permission changes, the embedded thing usually just stops. Nobody reports that; they simply stop relying on you. A dead integration is invisible churn, so alerting yourself when one stops firing beats most feature work.

Products that need their own window

The strategic version: become the connective tissue

There is a level beyond being present in one tool, and it is worth naming because it changes what you are.

A product that sits between several tools, moving work between them, stops being a destination and becomes plumbing. Nobody opens it for pleasure. Nobody has to. Removing it means re-establishing every connection it was quietly maintaining, which is a project, not a decision, and projects get postponed indefinitely.

That position is the strongest form of this pattern and the slowest to reach. It also has a specific risk: the tools you embed in can change their platform terms, deprecate the surface you built on, or ship your feature themselves. Depending on somebody else’s window means accepting that they own the window, and the products that survive it are the ones embedded in three or four places rather than one.

Integrations that stopped firing

The integration count on your marketing page is a vanity metric. What matters instead is how deeply the thing is wired in, and four questions get at it.

1. Do users with an integration connected retain better than users without, at the same tenure? They should, substantially. If they do not, your integration is decorative and the connect rate you have been optimizing is measuring enthusiasm, not value.
2. What share of the value is consumed inside the other tool? Rising is good, and counterintuitive: it means sessions in your product may fall while retention improves. Teams that watch only their own session counts read this as a problem and break it.
3. Which integrations have gone dark? Count connections that were active and stopped. This is the cheapest churn signal in the product and few teams instrument it.
4. How long does setup take, and how often does it need repeating? Time it yourself. Anything that needs doing twice tends to get done zero times.

Promote one integration

1. Audit what your existing integrations actually deliver, and sort them into notification, action, and value in place. Expect your own portfolio to be almost entirely the first category.
2. Promote one integration up a level. Take the one with the most connections and make the value consumable without leaving. This is usually the highest-return work available in this pattern.
3. Find where your users actually are all day by asking a handful of them what is open on their screen right now, rather than which integrations they would like.
4. Instrument integrations going dark, and treat a dead connection as a churn event, not a support ticket.
5. Check your setup is genuinely once. If it recurs per project, fix that before building anything new.
6. Do not depend on a single window. One platform decision should not be able to remove your distribution.

Being present where the work happens covers most products. A smaller set can go further, because the underlying job genuinely recurs every day, and for those the work itself can become the trigger without any integration at all. That is a narrower opportunity than the literature on it suggests, and getting it wrong is how products end up nagging people: habit loops only amplify a rhythm that is already there.

Updated August 2026