Slack and your project tool: what should go where

A designer asks in Slack whether the dark hero is approved. Someone says "yes, I think Tom liked it". Two days later nobody can find where that was decided, and the job still says In review. Most agencies live in two places at once: the chat where people talk, and the board where the work is tracked. The trouble starts when the two drift apart.

The fix isn't to pick one. It's to agree what each place is for, and then make the hand-over between them cost nothing. Here's how I'd split it, and how Skybase's Slack app keeps the two in step.

Why work ends up split between Slack and the board#

Slack is where people already are. It's quick, it's open all day, and a question there gets an answer in minutes. A project tool is where the work has a home: the brief, the files, the due date, the person who owns it.

Problems come from three habits:

• Decisions made in chat stay in chat. A thread scrolls away, and the job never hears about it.
• Updates are copied by hand. Someone moves a job and then types "moved to review" in the channel, or doesn't.
• Links lose their context. A pasted link says nothing until someone opens it, so people ask "which one is that?" instead.

Each one is small. Together they mean the board stops telling the truth.

A simple rule: hear about it in Slack, decide it on the job#

The rule I'd give a team is short. Slack is where you hear about work. The job is where it's decided and recorded.

That means:

• Updates flow from the job to Slack, automatically, so nobody types them.
• Quick replies can flow back from Slack to the job, so a "looks good" lands where the work lives.
• Anything that needs a record (a client's sign-off, a change of owner, a new due date) happens on the job.

The rest of this post is about making both directions effortless enough that people follow the rule without thinking.

Connect once, then give each project a channel#

An administrator connects your Slack workspace once, from the workspace's general settings, with Connect Slack workspace. Skybase joins Slack as an app called Skybase.

After that, each project picks its own channel under Project settings, then Slack, then Choose a Slack channel. Public and private channels both work. For a private channel, invite the app first with /invite @Skybase.

Each project posts to one channel, and several projects can share a channel. A small studio might give each client a channel, so the Northwind Rebrand and its follow-on work both post to #northwind-rebrand, while internal projects share one quieter channel.

Send test message checks the connection before anyone relies on it.

Choose what each project posts#

Each project has switches for 11 kinds of update, in three groups:

• Jobs: created, moved, renamed, description updated, due date changes, member assignments and archived.
• Comments & Files: comments and file uploads.
• Tasks & Approvals: task completed and file approvals.

Five start on: job created, job moved, comments, file uploads and file approvals. Turn on the rest only if the channel's readers need them. A busy board with every switch on becomes a channel people mute, which defeats the point. Save your choices with Save Settings.

Every post says who did what, names the project, and links the job's title straight back to the job. Nobody has to search the board for "that one".

When an automation made the change, the post names the rule, so a channel can tell a person's move from a rule's. Two kinds of automated change post nothing at all: a move a rule makes quietly, and a job an automation archives. Those are housekeeping, not news. How automations work covers quiet moves and the rules that archive.

Let replies come back to the job#

Updates going to Slack is half of it. The other half is the reply. Someone sees "Leo commented on Homepage hero concepts" and wants to answer. Before, answering meant opening the job. Now they can reply in Slack, and it lands on the job.

While replies are on, every post carries a line under it: "Reply in the thread to comment on this job". A reply in that thread becomes a comment on the job, posted as the person who wrote it. It's a normal comment, so @mentions, the inbox and emails work as they would if it had been written on the job page. Slack ticks the reply with ✅ once it's in.

How Skybase knows who wrote it matters, so here are the rules:

• It asks Slack for the email address on the replier's Slack account, and only uses it if Slack has confirmed that address.
• The replier has to be in the Slack workspace you connected, and has to be someone in the project who can see the job.
• It only works in the channel the project posts to, in the threads under Skybase's own posts.
• The reply is never posted back to Slack as a new message, so the channel doesn't echo.
• Files in a reply stay in Slack. Add them on the job.

If Skybase can't match the replier, nothing is posted. Instead, they get a private note in the thread that only they can see, saying why and linking the job. Skybase keeps a Slack person's name and email for a day, so it doesn't ask Slack on every reply.

The switch is Let people reply from Slack, per project. Turn it off for a channel where you'd rather every comment be written on the job.

Paste a job link, see what it is#

The third habit was bare links. With Show link previews in Slack on, a link to a job in a connected project unfurls into a short preview: the job's title, project and column, whether it's completed and up to three of its labels, who holds it, its due date, and its priority when it isn't Normal.

Previews are careful about who's looking:

• The preview only appears when the person who pasted the link can see the job in Skybase.
• Archived jobs, and jobs in archived projects, are never previewed.
• The description and comments are never shown.

As the switch itself says: "Everyone in the channel sees it." So treat a preview like any other message in that channel. If the channel includes people who shouldn't see a job's title or due date, leave previews off for that project.

What stays out of Slack#

Some things belong on the job, whatever the channel:

• Client sign-off. Choose Ask for approval on the job and name the client as the approver, so their decision is recorded on the job. A "looks good" in a thread isn't a record of who approved which file. Client approvals without the email chain explains why.
• Private notes. A job's Notes are visible only to the person who wrote them, and they never leave Skybase.
• Decisions that change the job. A new owner, a new due date, a move to Done: make the change on the job. The channel hears about it from the post, rather than the other way round.

If you work with several clients in one workspace and use client teams, guests are never named in Slack. They appear as "A guest from another team", because a channel can't know which client is reading.

A worked example: Harbour Studio#

Take a small studio, say Harbour, rebranding a client called Northwind. Maya Chen, the studio lead, connects Slack once and points the Northwind Rebrand project at #northwind-rebrand. She leaves the five default switches on and adds due date changes, because the team plans around dates.

Leo uploads a second round of hero concepts and comments on the job: "Second round is up: the dark variant is in the Files tab." The post appears in #northwind-rebrand with the job linked. Maya replies in the thread, "Love the dark one. Let's send it to Tom for sign-off." Slack ticks her reply, and it's on the job as her comment, where Leo and anyone else on the job are told about it.

Tom, the client, isn't in the studio's Slack. He doesn't need to be. Leo asks for approval on the final export and names Tom, who reviews it from the link in his email and approves it. The request and Tom's decision post to the channel, so the studio hears about both without anyone copying them across.

Later, the studio's automation that moves completed jobs to Done does so quietly. The channel stays readable.

If you connected Slack before October#

Replies and previews need a few more Slack permissions than the original app asked for. If your workspace connected Slack before they existed, the project's Slack settings say so, and an administrator chooses Reconnect Slack. Do it from Skybase rather than reinstalling the app in Slack, so Skybase records the new permissions.

A checklist for your channels#

• Connect Slack once, and give each client project its own channel.
• Keep the five default switches, and add others only when a reader needs them.
• Leave Let people reply from Slack on for working channels, so quick answers land on the job.
• Turn previews off in any channel shared with people who shouldn't see job details.
• Keep sign-off, ownership and dates on the job. Let Slack hear about them.
• If replies or previews show as unavailable, reconnect from the project's Slack settings.

The full list of what the Slack app does, and doesn't do, is on the Slack integration page.