How-To · 7 min read
Can You Build Resource Booking With Slack Workflow Builder?
Lockit Team · 2026-10-20
Before installing yet another Slack app, a lot of teams ask a fair question: can't we just build this ourselves with Workflow Builder? It's already in Slack, it needs no code, and the requirement sounds small. Track who has the staging server, let people claim it and release it, post updates to a channel.
The short answer: you can build a usable basic version, and you'll run into a few specific gaps. This post walks through how to build it, with the Workflow Builder capabilities checked against Slack's help center in October 2026, and is direct about where it stops.
What Workflow Builder can do in 2026
The current Workflow Builder is quite capable. According to Slack's help center:
- Plan requirement: Workflow Builder is available on paid Slack subscriptions. By default, all full members can build workflows, though admins can restrict access.
- Triggers: a workflow can start from a link (including a shortcut people can click), on a schedule, from a webhook, when a list item is updated, when a message containing specified keywords is posted, when someone joins a channel, or when an emoji reaction is used.
- Steps: Slack steps that act inside Slack, connector steps that act in third-party services, and custom steps built by developers. List steps include adding an item to a list, updating a list item and deleting a list item.
- Buttons and forms: a button pauses the workflow until someone clicks it, and can continue the workflow, start another one, or show a form.
- Branching: conditional branches, driven by things like button clicks and form answers, are available on the newer version of the Business+ plan and on Enterprise plans.
- List automations: lists can notify a channel when a chosen field changes and send due-date reminders. These automations are on paid plans.
That's enough building blocks for a simple booking system.
The design
One Slack list holds the state. Two or three workflows change it.
The list: "Shared resources"
| Column | Type | Example |
|---|---|---|
| Resource | Text | staging-api |
| Status | Select: Free / In use | In use |
| Held by | Person | Priya |
| Until | Date | Today |
| Notes | Text | Testing payments refactor |
Add one row per resource. Share the list in your environments channel so everyone can see it.
Building it
Workflow 1: Claim a resource
- Create a new workflow, triggered from a link, so it appears as a shortcut in the channel.
- Add a form step asking for: which resource (a select field matching your list rows), how long, and a note.
- Add an Update a list item step: set Status to In use, Held by to the person who ran the workflow, Until and Notes from the form.
- Add a message step posting to
#environments: "{person} claimed {resource} until {until}: {note}."
Workflow 2: Release a resource
- Another link-triggered workflow.
- A form step: which resource.
- Update a list item: Status to Free, clear Held by and Until.
- Post "{resource} is free" to the channel.
Workflow 3: Daily nudge
- A scheduled workflow, running each weekday at 17:00.
- Post a message to the channel: "Reminder: release anything you're finished with. Current holders are in the Shared resources list."
Optional: change notifications
Use the list's own automation to notify #environments whenever the Status field changes. That gives you a channel feed of claims and releases even when someone edits the list directly.
This takes an hour or two to set up and works.
Where it runs out
Here's what you'll find after a few weeks of real use.
Nothing stops a double claim
Workflow 1 updates the list item whether or not someone already holds it. If Priya has staging-api and Sam runs the claim workflow, Sam's claim overwrites hers. Both of them think they have it.
You can reduce this with branching, if you're on a plan that has it, by adding a confirmation step ("Is the resource shown as Free?") and branching on the answer. But that relies on the person checking. Slack's branching documentation describes branches driven by things like button clicks and form answers, so the workflow is asking the user rather than enforcing a rule. Two people claiming within the same minute will still collide.
Claims don't expire
"Until" is just a field. When it passes, nothing happens. The list still says In use until someone releases it. The daily nudge helps, but a forgotten claim from Tuesday afternoon still blocks Wednesday morning.
A scheduled workflow runs on a fixed cadence for the whole workflow, not per item at each item's end time, so there's no clean way to release each claim when its own time is up.
No "tell me when it's free"
The list can notify a channel on every status change. That's a broadcast, not "ping me, specifically, when staging-api is released." In a busy channel, people miss it and go back to asking.
No polite takeover
When you need something urgently, the DIY version gives you a DM to the holder. There's no structured request with "approve and hand over" or "reject" buttons that updates the list when answered. You can build pieces of this with buttons and a second workflow, but it gets fragile.
CI can trigger it, but can't ask it
A webhook trigger means a pipeline can start the claim workflow. But the pipeline gets no answer back about whether the resource was free. It can't wait, retry or fail cleanly. For CI, you need something that returns a yes or no. We cover that pattern in locking staging from CI/CD.
Plan cost
The whole approach needs a paid Slack plan. The double-claim mitigation needs branching, which needs Business+ (new version) or Enterprise. If you're on Pro, you get the basic version without branches.
Summary of the trade-off
| Requirement | Workflow Builder + Lists | Purpose-built lock bot |
|---|---|---|
| Claim and release from Slack | Yes | Yes |
| Visible current holder | Yes, in the list | Yes |
| Channel updates | Yes, via list automation | Yes |
| Refuse a claim when it's held | No, overwrites | Yes |
| Automatic expiry at end time | No | Yes |
| Personal alert when released | No, channel broadcast only | Yes |
| Structured takeover request | Partly, with effort | Yes |
| CI gets a yes/no answer | No | Via API |
| Slack plan needed | Paid; branching needs Business+ / Enterprise | Priced separately by the bot vendor |
When DIY is the right call
Build it yourself when:
- You have two or three resources and a small team with good habits.
- Collisions are an annoyance, not an outage or a ruined test run.
- You're already on a paid plan and someone enjoys maintaining workflows.
It's also a good way to find out whether your team will actually use a booking system before you adopt one.
When a dedicated bot is less work
Lockit is a Slack, Discord and Microsoft Teams bot for exactly this job, and it covers the gaps above:
@Lockit lock staging-api
@Lockit release staging-api
@Lockit list
- A lock on a resource someone else holds is refused. You see who holds it and until when.
- Every lock ends automatically: the duration chosen when locking, else the resource's default, else the workspace default, else 48 hours.
- Alert when released pings you personally when the resource frees up.
- Ask for takeover sends the holder Release and Approve and Reject Request buttons.
- Each resource can post lock and release updates to a channel you choose.
- On paid plans, a REST API and an MCP server let pipelines and coding agents take the same locks and get a clear answer. See the API docs.
Lockit's plans are separate from your Slack plan. Its free plan covers two resources with unlimited locks and members, and Starter is $17/month for up to 100 resources. If you do want Lockit wired into your own Slack workflows, that's part of the Custom plan. See pricing.
It doesn't do calendars or future-dated reservations, so if what you really need is "book this for next Tuesday," neither approach in this post is the right tool.
For a broader comparison of options, see the best tools to reserve shared resources in 2026, and if you're coming from a sheet, the spreadsheet alternative for environment booking.
FAQ
Is Workflow Builder available on Slack's free plan?
Slack's help center lists Workflow Builder as available on paid subscriptions. Conditional branching specifically requires the newer Business+ plan or Enterprise.
Can a workflow automatically release a claim when its time is up?
Not cleanly. Scheduled triggers run on a set cadence for the whole workflow, not at each item's own end time. You can post a scheduled reminder, but the claim stays until someone clears it.
Can I stop two people claiming the same resource at once?
Not reliably with Workflow Builder. A claim workflow updates the list item regardless of its current state. Branching can add a confirmation step, but it depends on the user answering correctly and doesn't prevent simultaneous claims.
Can Lockit and Workflow Builder work together?
Custom Slack workflows built around Lockit are part of its Custom plan. Contact hello@lockitbot.com to discuss what you need.