Good news, @everyone! Starting today, Flowdock has a new way to reach the right people in a flow: @team. You can decide whether you’ll be notified for @team on a flow by flow basis. Using @team instead of @everyone helps reduce unnecessary notifications – a win for all!

@team in action

One of the major benefits of using Flowdock is increased transparency across your company. With open flows, you can jump directly into the flow that you’re interested in. Getting answers to questions, gathering feedback and solving problems is a lot easier (and faster!) when you don’t have to figure out who the right contact person is, and can just start a conversation in a team’s or subject area’s flow.

The end result is that flows are made up of two types of people: core team members and “spectators” – people who are interested in whatever the flow is about, but aren’t necessarily responsible for the subject area.

This presents a problem. If you’re a spectator, you don’t want to be notified whenever someone uses @everyone with a question or comment for the core team. On the other hand, as a team member, it’s important not to miss these messages.

@team in Notifications list

Enter @team. It’s a new @mention targeted at a flow’s core team. By default, everyone will receive a notification when someone uses @team, but users can decide to opt out of them per flow. Looked at from the opposite point of view: as someone with a message for the core team, using @team will only disturb the people who want to be disturbed. You’ll see a “Team” label next to all these people in a flow’s user list.

User list shows who belong to @team and who don't

What about @everyone?

@everyone (and its synonyms @all, @everybody, @anyone and @anybody) will continue to work as before, highlighting your message for all members of a flow. Since it’s nearly always better to use @team rather than @everyone, we will try to nudge people towards using @team:

Warning before using @everyone

Remembering to use @team instead of @everyone is a practice that needs to be learned and will take some time. Be patient with your coworkers! A gentle reminder about how using @team is more considerate than @everyone should help.

Design retrospective

Many versions of this feature have been on our drawing board. Design work was actually started from another often requested feature: custom @groups. The idea was carefully studied, resulting in the realization that people had very different ideas of how @groups should work. For some, it meant highlighting certain words whenever they’re mentioned in any flow. For others, it meant flow-specific roles, such as @tester or @on_call.

With organization-wide @groups, the resulting naming conflicts would have been horrendous. We could also imagine the headaches that would ensue (with flow-specific @groups) from having to recall the different @groups for each flow. We decided to trust our existing model of having flows play the part of organization-level groups, but improve on their configurability.

“@everyone spam is evil and should be avoided” is a best practice that we heard from many of our users. The problem wasn’t so much about @everyone per se, but rather about getting @everyone spam from flows where it wasn’t relevant to your work.

Our first attempt at a solution was to give users the ability to ignore @everyone per flow. While the results were promising, the design experiment had a few uncomfortable side effects:

  1. There were cases when reaching every person in a flow was still needed, and this was no longer possible.
  2. As a sender of a message, you were no longer sure who would be notified with @everyone.
  3. @everyone no longer meant, well, “everyone”. Not good.

We had to come up with a way of reaching the core people in a flow without making @everyone a misnomer. And this lead us to the current implementation with @team.

What’s next? Design futurospective

In the end, @team, @everyone and @groups are about notifications: being able to define what’s important, both as a sender and receiver of information. They are all ways to direct certain peoples’ attention to specific content.

Many of you have written us asking for better notification configurability per flow. Flows are Flowdock’s built-in way of classifying content, and you should obviously be able to classify certain content as more important than others. Flow-specific notification settings is a no-brainer, and a feature that we’ll be working on soon. We’ll also focus on improving notifications in general, including push notifications.

As always, we’d love to hear about your feedback and use cases. How would you imagine @groups would work in your flows? How would you configure notifications per flow? Send all your thoughts to the Flowdock team at