<p>Teams group people so you can organize projects and access around your real
structure — engineering, design, support, and so on.</p>
<h2 id="creating-a-team">Creating a team</h2>
<p>Create a team, give it a name, and add the relevant people to it. A person can
belong to more than one team, which is useful when a person works across product,
engineering, or customer-facing groups.</p>
<h2 id="teams-and-projects">Teams and projects</h2>
<p>Use teams to give a whole group access to related projects at once, instead of
adding members one at a time — handy as your workspace grows.</p>
<p>Teams also give you a useful way to browse related work. A project can be linked
to a team, while still remaining a project with its own task list, views, and
project members.</p>
<h2 id="team-roles">Team roles</h2>
<p>Teams have Admin, Member, and Guest membership roles. The distinction is broad:
team-admin actions require a team Admin, team-member actions allow Admins and
Members, and team-guest actions allow all three roles. Do not treat this as a
fine-grained content-permission system; see <a href="/docs/members-and-roles">Members &#x26; Roles</a>.</p>

Group people into teams that mirror how your company is actually organized.

Teams

every file uploaded to lane opens in a viewer with a discussion panel beside it, and images can be marked up directly — arrows, highlights, freehand drawing, and pinned comments placed on the image itself. design feedback, bug reports, and document review stay attached to the file instead of scattering across a channel. open a file in the viewer click any attachment to open the viewer. it works wherever files live in lane: - attachments on a task , and on individual task comments - files shared in a project channel message - files in a project's files panel - screenshots submitted through the feedback widget images, video, audio, and pdfs preview inline. other file types show a download prompt instead — use download to save the file, or the open-in-new-tab button to view it outside lane. links pasted into a message open a simple preview without a discussion panel, since there is no file stored in lane to attach comments to. comment on a file the panel on the right of the viewer is a conversation about that specific file. comments support rich text and mentions, and a mention notifies that person in their inbox with a link straight back to the file. comments appear for everyone with the file open after they have been saved. you can edit or delete your own comments — an edited comment is labelled so the history stays honest. individual comments are limited to 2,000 characters. annotate an image with an image open, use the pencil button in the viewer header to enter annotation mode. a toolbar appears under the image with the drawing tools, and done saves your work while cancel discards it. | tool | what it does | | ------------------- | -------------------------------------------------------------------------------- | | select and move | drag an annotation to reposition it. highlights get corner handles for resizing. | | comment | drop a numbered pin on the image and type a message against it. | | highlight | draw a box that dims everything outside it, to focus attention on one region. | | draw | freehand strokes for circling and underlining. | | arrow | point at the exact thing you are talking about. | | erase | click an annotation to remove it. | the palette button sets the colour used by the drawing tools. pick a colour before drawing — it applies to new annotations rather than to the current selection. annotations are saved onto the file itself, so anyone who opens it afterwards sees the same markup. outside annotation mode, comment pins are read-only: click one to read its message. only one person can annotate an image at a time. while someone is editing, the pencil button shows a lock for everyone else and becomes available again when they finish. annotation mode also closes if the live connection is lost, so an offline edit cannot overwrite newer markup. widget screenshots retain their original capture and annotations. you can edit their markup in the same viewer; subsequent saves are stored with the attachment. download saves the original file, not a flattened image of the current markup. pinned comments or panel comments? both are useful, and they answer different questions: - pinned comments answer where — "this padding", "this label". they only exist on images, and they live on the image for everyone who opens it later. - panel comments answer what next — the back-and-forth, decisions, and sign-off. they work on every file type, support mentions and notifications, and read as a conversation in order. a common pattern for design review is to pin the specific problems on the image, then use the panel to agree on what changes and who does it.

Review files in place — draw and comment directly on an image, and keep the discussion attached to the file.

Attachments & Annotations

manage your lane subscription, plans, and invoices from your workspace billing settings. this page covers the questions we hear most — for anything else, email licensing@lane.work. free trial every workspace comes with a full-featured 1 month trial — no limits and no credit card required. it is the best time to try the workflows that matter to your team before committing to a subscription. plans & preview pricing lane offers per-seat and flat-rate team plans. because lane is in its preview release, pricing is still settling — but if you subscribe during preview, your founding-member rate is locked in for as long as your subscription stays active, even after general-availability pricing changes. managing your subscription upgrade, downgrade, or cancel at any time from your workspace settings in the app. prefer us to handle it? email licensing@lane.work. changing a plan affects the workspace subscription, not individual projects. review who has access to the workspace before changing the number of seats or moving to a team plan. refunds fees are charged in advance and are generally non-refundable, except at our discretion on a case-by-case basis. if something doesn't seem right with your billing, get in touch and we'll work it out. storage & fair use all plans include unlimited storage under a fair-use policy — meant for project-related content like files, images, and attachments, not for use as a general-purpose file host or backup service. fair use also applies to platform resources such as api activity. if usage is far outside normal project collaboration, lane may contact you to discuss it or restrict access as described in the terms. full terms for the complete details, see our terms of use and legal & privacy.

Plans, your free trial, managing your subscription, refunds, and fair use.

Billing & Licensing

budgets turn tracked time into a simple view of planned capacity or project spend. each project has its own currency, default hourly rate, and one or more budget periods. configure project economics open a project's ••• menu, choose settings , then open time & budget . set the project's currency and default hourly rate under project economics . the project rate is used for new time entries. to give one person a different rate, open the members settings and add an hourly rate override beside their name. a member override takes precedence over the project default. every entry keeps the rate and currency that applied when it was created. later rate changes therefore affect new work without changing earlier reports or exports. create a budget period choose + beside budget periods , then select a budget unit: - money tracks billable value against an amount in the project currency. - hours tracks recorded duration against an hours allowance. add start and end dates when the budget belongs to a specific period. budget periods cannot overlap; leave a boundary open only when the budget genuinely has no start or end date. by default, non-billable time is not counted against a budget. enable count non-billable time against this budget when all recorded effort should consume the allowance. allocate a budget a budget can be allocated across project sections or cycles. enter an amount for each one and use the unallocated remainder to check what is still available. lane prevents the allocations from exceeding their parent budget. allocations are optional. a single project-level budget is usually the clearest place to start; add allocations when you need to compare parts of the project separately. monitor and update a budget select the project on the workspace time tracking page, or open the project's time & budget sidebar, to see planned time, actual time, budget used, and budget remaining. lane warns you when spend exceeds the budget or delivery is running materially ahead of the available allowance. you can edit a budget's amount and end date as plans change. once a budget has recorded usage, its unit and currency cannot be changed and it cannot be deleted. set an end date instead, preserving the historical report while allowing a new period to begin.

Set project rates, create money or hours budgets, and monitor usage without rewriting historical time.

Budgets & Rates

the calendar places dated tasks on a familiar month or week grid, so you can see timing at a glance. it is especially useful for finding collisions, empty periods, and work that has a date but no realistic place in the surrounding schedule. project vs. personal calendar a project's calendar shows that project's dated tasks, while your personal calendar brings together everything scheduled across all your projects in one view. tasks use their start and end dates when they are scheduled across a range. mark an item all-day when it should not imply a specific time of day. rescheduling drag a task to a new day to change its date right from the calendar — no need to open it. open the task when you need to change more than its timing, such as the owner, description, labels, or the project section it belongs to. calendar is a view of existing tasks, not a separate planning record. changing a date there updates the task everywhere it appears.

See scheduled work on a calendar — across a project or across everything assigned to you.

Calendar

lane is built from a small set of building blocks that combine to fit a wide range of team workflows. understanding these makes everything else click. workspaces the top-level container for your team. everything — projects, people, settings — lives inside a workspace. see workspaces. projects projects group related work and give it shared context. a project can also act as a channel for ongoing conversation. projects have their own tasks, sections, cycles, views, messages, and members. see projects. tasks tasks are the unit of execution — with assignees, due dates, labels, custom fields, subtasks, and comments. a task can be a regular task, milestone, or blocker, and can also be placed on the project roadmap. see tasks. threads threads are long-running conversations, often with customers, that connect inbound requests to the work they drive. in lane, a thread belongs to a project message: it keeps replies and participants around a specific discussion rather than becoming a separate chat system. see threads. teams teams group people so you can organize projects and permissions around how your company is actually structured. a team can own related projects, while people can belong to more than one team. see teams. the important distinction: workspace, project, and team a workspace contains the whole organisation. a project is the container for a body of work or a channel. a team is an organisational grouping that can be associated with projects. they overlap, but they are not interchangeable — use a project for the work itself and a team for the people who commonly work together.

The building blocks of Lane — workspaces, projects, tasks, threads, and teams — and how they fit together.

Core Concepts

custom fields let you attach structured data to tasks beyond the built-in fields — think a product area, effort estimate, customer segment, or any attribute your team needs to make decisions consistently. fields belong to a project, so use them for data that matters to that project’s workflow. field types fields support text, numbers, percentages, dates, tags, options, and time. choose the smallest useful type: options are useful for a controlled vocabulary such as priority, while text is better when the value is genuinely open-ended. creating a custom field create a field, give it a name and type, and (for dropdowns) add the options you want to choose from. you can describe a field, order it alongside the others, and hide it when it is no longer useful without having to remove the concept from a task immediately. using fields in views show custom fields as columns, group by them, and filter on them in your views — turning your own attributes into a way to organize work. avoid duplicating built-in task information. for example, use the standard due date and assignee rather than recreating them as fields; reserve custom fields for the information lane does not already model.

Add structured, custom data to tasks — dropdowns, numbers, dates, and more.

Custom Fields

customer requests connects feedback to the work it influences. requests submitted through email or the lane widget become tasks, while the original requester, customer, and wording remain attached as customer context. this lets you consolidate duplicate requests without losing the people behind them. set up the requests project open requests in the workspace navigation. lane provisions a customer requests project with email and widget intake enabled. it is a normal project behind the scenes, so you can use views, sections, assignments, labels, comments, and the rest of the task workflow as usual. new submissions arrive as unread tasks for triage. if a request represents work you intend to plan directly, move its task into the appropriate delivery project; its customer context moves with it. customer records when a request arrives from a business email address, lane matches the domain to an existing customer or creates one. requests from common personal email providers still record the contact, but are left without a company so you can triage them appropriately. open customers from the workspace navigation to search and sort customer records. you can add a customer before they have made a request, edit their name and domains, and record details such as tier, annual recurring revenue, or an external crm id. each customer detail panel brings together their request history across projects. a domain added to a customer is also used when matching future inbound requests. preserve the reason behind the work open a task’s requests tab to see who asked, which customer they belong to, when the request arrived, and the requester’s original wording. more than one request can point to the same task, giving the team a consolidated demand signal without duplicating the work itself. the request record is separate from the task’s live conversation. moving or merging a request does not rewrite the original contact or quote. merge duplicate requests use merge requests when an incoming request duplicates work that already exists. search for a destination task anywhere in the workspace, then confirm the merge. the selected request moves to the destination task and the source task is archived. only the selected request moves. if the source task has other requests attached, they remain on that task and are archived with it; lane calls this out before you confirm. merge those requests individually when they should all contribute to the same planned task. merge or archive customers customer records can be merged when domain matching produces duplicates, such as after a rebrand or domain change. the destination customer survives, receives the source customer’s domains and requests, and the source customer is archived. archiving a customer removes it from the active customers list without deleting its request history. notify requesters when work ships when publishing a release, enable notify requesters to email the contacts attached to its tasks. lane deduplicates recipients by email address. if the project’s shared page is enabled, the notification links to the published releases; if it is disabled, the update is sent without a public link.

Collect customer feedback, preserve who asked for it, consolidate duplicates, and close the loop when work ships.

Customer Requests

documents give a project a shared writing space for the things that do not fit in a task description — a brief, a plan, a decision log, a draft announcement. everyone in the project edits the same document at the same time, comments attach to specific passages rather than to the document as a whole, and a finished draft can be converted into a task in one step. create and open a document open a project and choose documents in the right-hand sidebar. the panel lists every document in the project, along with how many open comments each one has, so you can see at a glance which drafts still need attention. use + to create a document. it starts as untitled document and opens immediately. edit the title in the header — it saves when you click away, and an empty title falls back to untitled document . documents belong to their project and follow the project's membership and privacy rules. anyone who can open the project, including guest collaborators, can read and edit its documents. write together the document body uses the same rich text editor as tasks and messages, so headings, lists, formatting, and mentions all work the way you expect. editing is collaborative in real time. when two people have the same document open, their changes merge as they type — there is no save button, no lock, and no "someone else is editing this" warning to work around. comment on the text select a passage and add a comment. the selection is highlighted in the document and the comment opens as a thread in the panel on the right. threads and highlights stay linked: click a thread to highlight its passage, or click a highlight to bring its thread into focus. replies go in the same thread, so a discussion about one paragraph stays in one place. mentioning a teammate in a comment sends them a notification in their inbox. the header shows a running count of open threads. resolve closes a thread once it has been dealt with; reopen brings it back if the conversation is not actually finished. resolved threads remain readable in the panel rather than disappearing. you can delete your own comments. deleting the last comment in a thread removes the thread and its highlight from the document. threads whose text was removed if someone edits away the passage a thread was anchored to, the thread is not lost. it stays in the panel and is marked referenced text was deleted , so the discussion survives the edit and can still be replied to or resolved. convert a document to a task when a draft is ready to become work, use convert to task . lane creates a task in the same project using the document's title and body, notifies anyone mentioned in the content, and opens the new task. the comment highlights are stripped from the task description — they belonged to the drafting stage, not to the work itself. every thread must be resolved before a document can be converted; the button stays disabled while any comment is still open. this is deliberate: converting is a one-way step, and the document is deleted once the task exists. delete a document delete a document from the documents panel using the bin icon on its row. lane asks for confirmation first, because the document, its comment threads, and its history are removed permanently.

Write together in a project document, comment on the text itself, and turn the finished draft into a task.

Documents

a collection of common questions. if yours isn't answered here, reach out and we'll help. can i use more than one workspace? yes. most teams start with a single workspace and add more only when they need hard separation between products or clients. use projects, teams, and views before creating another workspace. a new workspace is the right choice when its members or data should not overlap with the first. how do customers take part without an account? through a project shared page. shared pages publish selected roadmap items and releases without giving a visitor workspace access. project channels and threads are workspace conversations, so someone taking part there needs to be invited as a member or guest. is there a free trial? yes — every workspace gets a full-featured 1 month trial with no credit card required. see billing & licensing for details. how is my data secured? your data is protected in transit and lane uses industry-standard safeguards. you can remove members and disable shared or join links, but the current role model is broad rather than a fine-grained permission matrix. use private projects or separate workspaces for stronger operational separation. see legal & privacy for more. can an external tool send updates into lane? yes. webhooks accept an incoming json request and post it as a message in a chosen project. they are currently inbound integrations, not outbound event delivery from lane. how do i get help? - search these docs — most answers live here. - head to support to contact us or report a bug. - for terms and data questions, see legal & privacy.

Answers to the questions we hear most often.

lane brings customer conversations, planning, and delivery together in a single workspace. the useful thread is simple: capture the context behind a piece of work, turn it into a task, decide where it belongs, and keep the conversation and delivery record close together. these docs are the reference for everything lane can do. if you're brand new, start with the quickstart, then read core concepts to understand how the pieces fit together. this documentation is a living resource. pages marked as a work in progress are being filled in — the structure below reflects what lane can do today. what lane is for lane is built for founder-led software teams that have outgrown a spreadsheet but don't yet have dedicated product operations. it connects the dots between what customers ask for, what you decide to build, and what you ship. it is not a rigid process. a small team might use one project as a product backlog and another as a conversation channel; a larger team might split work between team projects, cycles, saved views, and a public-facing shared page. the underlying task stays the same while the context around it changes. a practical loop 1. capture a request in a project message or a thread. 2. create a task for the follow-up and add the owner, dates, labels, or fields that make it actionable. 3. use a view, section, cycle, or roadmap to make the priority and timing clear. 4. publish a release when you want a durable, shareable account of what shipped. you can adopt only the parts that help. for example, labels and a list view are enough to get started; custom fields and cycles can wait until the team needs more structure. how the docs are organized - getting started — the mental model and your first workspace. - workspace & team setup — workspaces, members, roles, and teams. - projects & tasks — the core of day-to-day execution. - communication — messages, customer threads, scheduling, and reminders. - planning & delivery — your personal work surfaces, roadmap, and releases. - sharing & integrations — public links and webhooks. - support & legal — getting help, billing, and our terms and privacy. - help — shortcuts and faqs. ready? head to the quickstart.

Lane is the operating system for modern product teams — customer conversations, planning, and delivery in one workspace.

Introduction

lane supports keyboard interaction throughout the application, but it does not currently expose a product-wide shortcut palette or a stable catalogue of global navigation shortcuts. this page documents the shortcuts that are reliable today rather than promising a larger set. composing a message or comment when a rich-text composer is active, use cmd + enter on macos or ctrl + enter on windows and linux to submit it. this works for the message and comment composer, while a plain enter is still available for normal editing and mention selection. use escape to dismiss an open mention suggestion list. within that list, use the arrow keys to move between suggestions and enter to insert the selected one. standard controls many controls follow their normal browser and operating-system conventions: tab and shift + tab move focus, enter activates focused buttons, and space activates focused controls that behave like buttons. we will expand this page when a dedicated, stable application shortcut layer is available.

Move around Lane faster with keyboard shortcuts.

Keyboard Shortcuts

labels are workspace-wide tags you apply to tasks to categorize work and filter across projects — for example "bug", "feature", or "customer request". a task can carry more than one label, making labels a flexible cross-cutting category rather than a workflow stage. managing labels create labels once for your workspace, give each a name and color, and edit or remove them as your needs change. because labels are shared, they stay consistent across every project. keep their names short and stable: a label called works better than several near-duplicates that mean the same thing. filtering by label apply one or more labels to a task, then filter any view by label to focus on a specific kind of work — like everything tagged "bug". use sections for the stage a task is in and labels for what the task is about. that small distinction keeps a board or list readable while still making themes easy to find across projects.

Tag tasks with labels to categorize, filter, and report across projects.

Labels

this is a short, plain-language summary of the legal essentials from a support point of view. the full, authoritative documents are linked at the bottom. your data is yours you own the content you and your team create in lane — your projects, tasks, comments, files, and messages. you can export or delete it at any time, and we license it only to operate and provide the service. that limited licence lets lane host, store, process, and display customer data to run the service. it does not transfer ownership of the content to lane. privacy in short - we don't sell, rent, or trade your personal information. - we don't use your content for advertising. - we collect what's needed to run the service and improve it. you have the right to access, correct, delete, or export your personal data. to make a request, email support@lane.work. data deletion when you delete your account, we remove your personal data within 30 days , except where we're required to retain some of it for legal or legitimate business reasons. security your data is encrypted in transit, protected with industry-standard measures, and access within your workspace is governed by roles. no electronic storage or transmission method can be guaranteed absolutely secure. because the current role model is broad, use private projects and separate workspaces deliberately when you need stronger operational separation. the full documents this page is only a summary. for the complete and authoritative terms, read: - terms of use - privacy policy questions about anything legal or privacy-related? email support@lane.work.

A plain-language summary of how we handle your data, plus links to our full Terms and Privacy Policy.

Legal & Privacy

invite teammates to your workspace and assign a role. roles exist at workspace, project, and team level, but the current permission model is intentionally coarse: it is not a feature-by-feature or read-only permission system. inviting members invite people by email from workspace settings. an invite is redeemed by the recipient after they sign in, and it can be resent or removed while it is still pending. invite someone as a regular member or as a guest, then add the people who need access to the relevant project. what the roles currently mean there are four workspace roles: owner , admin , member , and guest . project and team memberships use admin , member , and guest . workspace administration routes require an owner or admin. at project and team level, admin-only routes require an admin, member routes allow admins and members, and guest routes allow all three roles. in practice, many everyday workspace routes currently admit every workspace role, including guest, and a number of project actions use the guest-level guard. that means guest should not be described as view-only, and a role alone does not tell the whole story of a person’s access. project membership and the specific action still matter. if you need a hard boundary, use a separate workspace or a private project and review its membership. treat the current roles as broad collaboration roles, not as an exhaustive security policy. guests guests are useful for external collaborators and people who should not be workspace administrators. they can be invited to a workspace or join a joinable project, which creates a guest membership. because guests can be allowed through several normal project and workspace actions, give them access only where that level of collaboration is appropriate. for people who do not need an account or to participate, use a shared page instead.

Invite people to your workspace and control what they can do with roles.

Members & Roles

use a channel for message-first conversation, or add a chat view to a regular project when discussion should sit beside its tasks and planning context. channels use the same project membership and privacy model as the rest of lane. posting messages write a message in a channel or project chat view and it appears for the project's members in real time. messages support rich text, teammate mentions, files, images, gifs, and links. click a shared file to open it in the viewer, where it can be commented on and — for images — annotated directly. see attachments & annotations. replies and threads hover over a message to reveal its actions. reply quotes that message in the main conversation. thread opens a sidebar for a focused conversation attached to the original message; posting the first reply starts the thread. threads you take part in are collected under threads in the left navigation. reactions react to a message with an emoji for quick, low-noise acknowledgement — a fast way to say "seen", "agree", or "done" without adding another message. attaching tasks use the task button in the message composer to find an existing project task or create a new one. the selected task is attached to the message as a card that teammates can open directly. keep channels useful use a message for a decision, update, or question that needs a response. create a task when there is an owner or outcome to track. this small discipline prevents the channel from becoming the only place where a commitment exists.

Talk to your team in project channels — real-time messages, reactions, and attachments.

Messages & Channels

the inbox is where relevant activity lands — mentions, assignments, replies, and updates on things you follow — so you can triage in one place. reading and clearing your inbox work through your inbox like email: open an item to jump straight to it, mark it as read, and archive it once it's handled to keep the list clean. marking a notification read does not change the task or message itself; it only clears your personal attention state. what generates a notification you'll get a notification when someone mentions you, assigns you a task, replies in a thread you're part of, requests your review, or updates something you follow. opening a notification takes you to its associated task, project message, or thread, including the relevant reply where available. triage without losing context use the inbox for things addressed to you, and use the project’s unread state for new channel activity. they solve different problems: inbox is personal attention; project unread markers help you catch up on a shared conversation.

Stay on top of mentions, assignments, and activity from your Inbox.

Notifications & Inbox

projects group related work and give it shared context — tasks, messages, files, and views all live together. a project can also act as a channel for ongoing conversation. it can be associated with a team, kept private, or made joinable for other lane users. creating a project create a project, give it a name, icon, and color, then decide whether it is a regular project or a channel. it appears in your sidebar right away and you can start adding tasks, messages, sections, and views. projects can also carry a status such as active, on hold, completed, or cancelled to make their state clear in project lists. organizing with sections inside a project, tasks can be grouped into sections and cycles so a long list stays readable and work is easy to plan. archiving projects when a project is finished, archive it to remove it from your active sidebar while keeping all of its history. you can restore an archived project at any time. membership and privacy projects have their own membership in addition to workspace membership. private projects are the right place for work that should not be visible in general workspace navigation. a joinable project creates a link through which signed-in lane users can join as guests; it is collaborative access, not a public read-only share. review members & roles before using roles as a security boundary. project overview and communication use the project overview and its messages to explain the outcome, decisions, and current state of the work. then keep the executable pieces as tasks. this makes a project useful to someone joining midway through, not just to the people who set it up. for longer pieces of writing — a brief, a plan, a draft announcement — use the project's documents panel, where the team can write together and comment on specific passages before the work is converted into a task.

Group related work into projects, organize it into sections, and keep the context in one place.

Projects

lane has three different link types, with different purposes. a project’s shared page is for publishing selected roadmap work and releases. a join link is for allowing signed-in lane users to become guest collaborators. a task upload link is for receiving files on one task. choose the link that matches the access you intend to give. shareable links enable the shared page in project settings to get a public link. you can add a description and image, and regenerate or disable the link when you no longer want to publish it. the public page is tied to that project’s selected roadmap items and published releases. what visitors can see visitors can view the shared content without a lane account. they do not get workspace access. signed-in visitors can comment on roadmap items, so treat the page as a lightweight feedback surface rather than a strictly read-only export. the rest of the workspace, including unshared tasks and internal project communication, is not exposed by the shared page. public roadmap for sharing your plan specifically, see roadmap. join links and upload links a project can be made joinable with a link. a person must sign in to use that link and joins as a guest, so it is collaboration access — review members & roles before sharing it. an enabled task upload link ( ) lets someone upload attachments to that specific task. it is not a task detail page. disable or regenerate either type of link whenever it is no longer needed.

Publish selected roadmap work and releases, or share the right collaboration link for the job.

Public Sharing

this guide gets you from sign-up to a working setup. it should take about five minutes. 1. create a workspace a workspace is the top-level home for your team. sign up and lane creates one for you — you can add more later. keep separate workspaces for work that truly needs its own people and data boundary, rather than creating one per project. see workspaces for details. 2. invite your team add the teammates who will work in the project. you can invite regular members or guests; use the roles as an access and membership signal, but do not rely on them as a detailed per-feature permission matrix. see members & roles for the current behaviour. 3. create a project projects group related work. create one, add a few tasks, then choose the view that makes the next decision easiest. a list is a good default; add a board, table, timeline, or calendar only when it answers a question the list cannot. 4. capture your first request start a thread to capture a customer conversation, then turn it into a task so it flows into planning and delivery. if the conversation is already happening in a project channel, you can start there instead. the aim is to record enough context that the task does not become an unexplained line item later. next steps - understand the building blocks in core concepts. - learn how tasks work. - set up a roadmap to communicate what's shipping.

Create a workspace, invite your team, and set up your first project in a few minutes.

Quickstart

releases turn the work completed in a project into a dated, customer-facing update. each release can bring together project tasks, explain the outcome in plain language, and publish the result alongside the project’s public roadmap. a release is a publishing record, not another task workflow. adding a task to a release does not complete, archive, or otherwise change that task, and a task does not need to be complete before you include it. open the releases panel open a project and select releases from the project tools on the right. the panel lists the project’s drafts and published releases, their publication dates, and the number of tasks in each one. select an existing release to edit it, or use new release to start one. releases belong to the current project: the task picker only searches that project, and a release cannot include tasks from somewhere else in the workspace. releases are for project members. guest collaborators do not see the releases panel and cannot create, edit, or publish a release. they can still read published releases on the project’s shared page, like any other visitor. create a release the release editor has two parts. the left side describes the release as a whole; the right side builds its public list of changes. 1. add a title . a release cannot be saved without one. 2. write a summary that explains what changed and why it matters. 3. choose a publication date , or leave it empty and let lane use the day you publish. 4. optionally add a jpeg or png cover image . 5. select add task and choose the project tasks included in the release. 6. review the public wording, reorder the items, and select preview before publishing. you can include up to 100 tasks in one release. the same task can appear only once within that release, but it can be used again in a later release when that accurately reflects the update. every selected task must also have non-empty public wording; remove unfinished items from the release or give them wording before saving. field limits: the title is capped at 200 characters, the summary at 10,000, and each item’s public wording at 1,000. a release that exceeds any of these is rejected when you try to save it. write public release notes when you add a task, lane copies its title into a separate public wording field. edit that wording freely: changing it does not rename the underlying task. this is useful when an internal title such as “fix pricing card wrapping at tablet width” should become “improved the pricing page on smaller screens.” drag release items into the order readers should encounter them. a useful release usually leads with the most meaningful outcome, uses the summary for context, and leaves the task list to explain the individual changes. use preview to check the cover, date, title, summary, and task wording together. the preview matches the structure used by the public changelog view. draft, publish, and unpublish use save draft while the release is still being assembled. drafts remain visible to project members in the releases panel but never appear on the public shared page. select publish when the update is ready. if no publication date is set, lane adds the current date. the date is descriptive rather than a publishing schedule: setting a future date does not delay publication. published releases can still be edited. update release saves the latest wording and media, while unpublish returns the release to draft and removes it from the public changelog view. deleting a release is permanent, but it does not delete or alter any of its tasks. deleting a task does change its releases. the task’s release item is removed with it, including from a release that has already been published — and, if requesters were notified, already emailed. the public release notes simply lose that line. archive the task instead of deleting it when it appears in a published release; archived tasks keep their release items intact. publish releases on a shared page enable the project’s shared page to make its published releases publicly accessible. visitors do not need a lane account. they can switch between the project’s roadmap and changelog views, browse the release feed, and read its public task wording. drafts, internal task titles, and the rest of the project remain private. published releases appear newest first in a chronological feed. each entry can show its publication date, title, cover image, summary, and ordered public release items. longer histories load progressively as a visitor scrolls. disabling the shared page removes public access to both the roadmap and changelog views. publishing a release does not enable the shared page automatically. notify the customers who asked if a release includes tasks with customer requests, enable notify requesters before publishing to email the attached contacts. lane deduplicates recipients by email address, so one person receives one update even when several of their requests are represented in the release. the notification uses the release title and summary. when the project’s shared page is enabled, it also links directly to the changelog view. when public sharing is disabled, lane sends the update without a public url. the toggle applies only to the current publish or update action and is off whenever you reopen the editor. leave it off when updating an already published release unless you intend to email the requesters again. saving a draft or unpublishing never sends an email. a practical release workflow for a clean, repeatable publishing pass: 1. finish or identify the project tasks that belong to the update. 2. create a draft release and add those tasks. 3. rewrite internal titles as concise customer-facing outcomes. 4. add a summary and optional cover image. 5. preview the release and check the item order. 6. publish it, optionally notifying the customers connected to the included work. this keeps the full path visible: the original customer signal stays attached to the task, the task becomes delivered work, the release explains what shipped, and the requester can be brought back into the loop.

Turn shipped project work into clear release notes, publish it for stakeholders, and update the customers who asked for it.

Releases

reminders belong to a task and notify its assignees. they can be one-off or recurring, and fire automatically in the background. use them for the moment a task needs attention, not as a general project announcement tool. creating a reminder open the task, set the time, repeat pattern, and timezone, and lane records the reminder against that task. the notification points back to the task so the next action is immediately clear. recurring reminders make a reminder repeat — for example daily or weekly — for the things that come around regularly, so you only set them up once. managing reminders review your reminders and edit or cancel any of them. cancelling a recurring reminder stops all of its future occurrences. reminders are handled by background jobs, so they trigger on schedule whether or not you're online. to notify someone else, assign them to the task. for a general project or team announcement, use a scheduled message instead.

Set one-off or recurring reminders so nothing slips through the cracks.

Reminders

reviews collects the tasks that need your sign-off, so approvals stay visible and don't get lost in the shuffle. it is a personal queue: tasks appear for the people added as reviewers, even when those tasks live in different projects. requesting a review add a reviewer to a task when it's ready to be checked. the task then shows up in that person's reviews queue and generates a review-request notification. a task can have more than one reviewer when an approval needs input from multiple people. reviewing work work through your review queue one task at a time, and either approve it or send it back with a comment — so the person knows exactly what's next. opening an item marks its review-request notification as read. the task remains the source of truth for the work itself, so add the reasoning or requested changes there rather than relying on a bare approval state.

Track the tasks waiting on your review so approvals never stall.

Reviews

the roadmap turns selected project tasks into a public view of what your team is planning and delivering. it stays connected to the underlying work: there is no second roadmap record to update, and changes to a task remain the source of truth. roadmap visibility is deliberate. a task appears only after you mark it for the roadmap, and the project’s shared page must be enabled before anyone outside the project can see it. set up the shared page open the project’s settings , choose shared page , and enable public sharing. you can add a background image and description, then copy the generated url. the description is a useful place to explain the project’s purpose, the time horizon of the roadmap, or how visitors should interpret it. the shared page contains both roadmap and changelog . roadmap communicates what is planned or underway; changelog explains what shipped. review public sharing before distributing the link. regenerating the shared url invalidates the previous link, while disabling the shared page removes public access without clearing the tasks you selected for the roadmap. add a task to the roadmap roadmap items are regular top-level project tasks. to add one: 1. enable the project’s shared page if it is not already enabled. 2. open the task you want to publish. 3. select show on roadmap from the task toolbar. the roadmap button becomes accented while the task is selected. select it again to remove the task from the roadmap. subtasks are not published as separate roadmap cards; promote work to a top-level task when it needs its own public roadmap entry. adding a task to the roadmap does not change its dates, section, completion state, or normal project workflow. completing a roadmap task keeps it on the roadmap so the public view can show progress rather than quietly removing shipped work. review the project roadmap open roadmap from the project tools on the right to see every selected task and its current roadmap signal. the panel shows the task title, dates, type or priority marker, completion state, and public like count. select a card to open the normal task detail and make changes at the source. the roadmap panel appears only once the project’s shared page is enabled — the same condition that reveals show on roadmap on a task. disabling the shared page hides both, but keeps the tasks you already selected for the roadmap. use sections and task ordering to shape the public story. a section can represent a stage such as todo , review , or up next , while tasks without a section appear under no section . changing the section or order in the project changes where the task appears on the public roadmap after the page is refreshed. what the public roadmap shows visitors can open the shared page without a lane account. roadmap cards are grouped by project section and can show: - the task title and completion state - start and end dates - whether a description is available - the number of public likes completed tasks remain visible with completed styling, and visitors can hide or show them. the public board scrolls horizontally when the roadmap has more sections than fit on screen. selecting a card opens its public detail. this view can include the task description, dates, task type, likes, and comments made from the roadmap. likes and roadmap comments any visitor can like a roadmap task. likes provide a lightweight signal around public interest; they do not change task priority, dates, or ordering automatically. roadmap comments are visible publicly. a visitor must sign in to a lane account to add one, but they do not need to join the project. comments submitted from the shared page are attached to the task and marked as roadmap comments for the project team. roadmap comments currently cannot be edited or deleted from the public page, so visitors should treat them as part of the published conversation. understand the privacy boundary marking a task for the roadmap publishes its existing title and description. review both before sharing; unlike a release item, the roadmap does not provide separate public wording. the public roadmap does not expose task assignees, labels, custom fields, the task attachment list, subtasks, or internal task comments. it shows only the selected top-level task’s roadmap fields and comments explicitly submitted through the roadmap. to remove public access to a task, turn off show on roadmap or archive the task. to take the entire roadmap offline, disable the project’s shared page. changes are not pushed to already-open public pages in real time, so refresh the page when verifying an update. keep the roadmap credible a useful roadmap communicates direction without turning every date into a promise: 1. publish work that is meaningful to customers or stakeholders. 2. give each task a clear title and enough description to explain the outcome. 3. use sections to communicate stage rather than inventing a parallel status system. 4. add dates only when they help readers understand timing. 5. keep completed tasks visible long enough to show progress, then use releases for the durable account of what shipped. because roadmap cards remain normal tasks, the public plan stays close to delivery and the team avoids maintaining the same work in two places.

Publish selected project tasks as a clear, shareable view of what is planned, in progress, and complete.

Roadmap

scheduled messages let you compose a message ahead of time and have it posted automatically at a future date and time — useful for announcements, standups, or reminders to a channel. they are project-channel messages, so schedule them where the people who need the update already collaborate. scheduling a message open the project’s scheduled messages panel and click + . write the message, choose select date , set the date, time, and timezone, then click okay and add scheduled message . lane posts it in the project’s messages view under the workspace name, even when you are offline. turn on repeat schedule for daily, weekly, monthly, yearly, or custom cron schedules. custom cron uses five fields (minute, hour, day of month, month, day of week) and is displayed as the exact expression you entered. one-time dates must be in the future in the selected timezone. managing scheduled messages click a message in the panel to edit its content or schedule, then choose update scheduled message . to cancel it, choose delete and confirm. project members manage the project’s schedules together. sent one-time messages leave the pending list; recurring messages remain until cancelled. reopen the panel to pick up schedule changes made by another user. under the hood, scheduled messages are queued as background jobs and posted at the scheduled time, so they send even if you're offline. keep the wording suitable for the audience at the time it will send. a scheduled message is not a live draft: check dates, links, and references before queueing it.

Write a message now and have Lane post it to a project at a time you choose.

Scheduled Messages

sections and cycles are two ways to structure the tasks inside a project. sections sections are named groups that keep a project tidy — for example "backlog", "in progress", and "done", or any grouping that suits your workflow. add sections, reorder them, and drag tasks between them as work moves along. a task belongs to a section, so sections are the clearest way to express a project’s primary workflow. cycles cycles are time-boxed iterations (sprints) you plan work into. create a cycle with a start and end date, assign tasks to it, and group a view by cycle to see exactly what’s committed for the current period. cycles are optional. use them when the team plans in periods; use sections alone when work flows continuously. removing a cycle from a project does not remove its tasks — their cycle association is cleared so the tasks remain available to plan again. a simple setup start with sections such as backlog, in progress, and done. add cycles only after the team has a reason to answer “what are we committing to this period?” keeping the two concepts separate avoids using a sprint as a substitute for task status.

Organize a project into sections and run time-boxed cycles to plan and pace delivery.

Sections & Cycles

lane publishes a live status page at status.lane.work. it's the fastest way to check whether lane is running normally or whether we're aware of an issue. what it shows the status page reports the health of each part of lane independently: - web app — the app you sign in to - api & database — the core backend and data layer - real-time collaboration — live updates and collaborative editing - background jobs — scheduled messages, reminders, and other queued work - redis — caching and real-time coordination - marketing website — lane.work itself each service shows a current state — operational , degraded , or down — along with its latest response time and when it was last checked. the component view is useful when only part of lane feels affected. for example, the main app may load while background jobs or real-time collaboration need attention, and the status page makes that distinction visible. how often it updates checks run automatically around every 15 minutes, so the page reflects current conditions without you needing to ask. it is a monitoring signal rather than a guarantee that every account-level action will succeed; refresh to see the latest reading. hosted independently the status page runs on separate infrastructure (cloudflare), apart from lane's own systems. that means it stays online to keep you informed even during a lane outage. still seeing a problem? if something's wrong for you but the status page looks healthy, it may be specific to your account or network — please reach out via support and we'll take a look.

Check live uptime and incidents for Lane at status.lane.work.

Service Status

need a hand? we're happy to help with anything — onboarding, billing, bug reports, or general questions about how lane works. contact support email us at support@lane.work and we'll get back to you. our normal reply window is within 48 hours . please do not include passwords, access tokens, or other secrets in a support request. when it's a bug, a few details help us fix it faster: - what you were trying to do - what happened instead - steps to reproduce it, if you know them - a screenshot or screen recording if you have one - which workspace you're in what we can help with - bug reports — we take bugs seriously and want to squash them quickly. - onboarding — getting your team set up and productive. - billing & licensing — see billing & licensing for the common answers. - anything else — if you're unsure where to start, just email us. for a billing or licence enquiry, you can also write to licensing@lane.work. service status check current uptime and any ongoing incidents at status.lane.work. see service status for what the page monitors and how it works. a note on the preview release lane is currently a preview release and under active development. we've worked hard to keep it stable, but you may hit the occasional rough edge — if you do, please report it and we'll jump on it. when reporting a problem, tell us whether it affects one project or workspace, or whether it happens everywhere. that distinction is often the fastest route to a useful diagnosis. legal & privacy for how we handle your data, and links to our full policies, see legal & privacy.

How to get help with Lane — contact us, report a bug, and check service status.

Support

tasks are the heart of lane. each task can carry assignees, due dates, labels, custom fields, subtasks, attachments, and a threaded comment history. tasks can be regular tasks, milestones, or blockers, so important dates and risks can be visible in the same views as everyday work. creating and assigning tasks create a task from any project or view, then give it an assignee and a due date. open a task to see its full detail, where you can edit everything in one place. you can schedule a start and end date, mark an all-day item, or make a repeating task where that is a better fit than creating duplicate tasks manually. descriptions & collaboration task descriptions support rich text, and multiple people can edit the same description at once — changes sync live, so there's no need to refresh or take turns. subtasks break a larger task into subtasks to track the smaller steps. completing subtasks shows progress on the parent, so you always know how far along it is. archive a task when it should leave active views without losing its history. archiving a parent also removes its subtasks from active work; restoring it brings the subtree back. comments, followers & reactions discuss a task in its comments, react to keep things light, and follow a task to get notified of updates even if it isn't assigned to you. files attached to a task or one of its comments open in a viewer with their own discussion panel, and images can be marked up in place — see attachments & annotations. planning and sharing tasks can be placed in a section and cycle, marked for the project roadmap, and included in a release. a task’s normal copied link is for people who already have access. the separate task upload link is for collecting files on that task; it is not a general public, read-only task page. custom fields add structured data to tasks — like priority or effort — with custom fields.

The unit of execution — assignees, due dates, labels, custom fields, subtasks, and comments.

Tasks

teams group people so you can organize projects and access around your real structure — engineering, design, support, and so on. creating a team create a team, give it a name, and add the relevant people to it. a person can belong to more than one team, which is useful when a person works across product, engineering, or customer-facing groups. teams and projects use teams to give a whole group access to related projects at once, instead of adding members one at a time — handy as your workspace grows. teams also give you a useful way to browse related work. a project can be linked to a team, while still remaining a project with its own task list, views, and project members. team roles teams have admin, member, and guest membership roles. the distinction is broad: team-admin actions require a team admin, team-member actions allow admins and members, and team-guest actions allow all three roles. do not treat this as a fine-grained content-permission system; see members & roles.

threads keep a focused conversation attached to a message without filling the main channel with every reply. the original message stays at the top of the conversation and the thread opens in a sidebar alongside the channel. every thread you are part of also appears under threads in the primary navigation, giving you one place to follow conversations across the workspace. starting a thread in a project channel or chat view, hover over the message you want to discuss and select thread . lane opens the thread in the sidebar with the original message included for context. write the first reply to start the conversation. you can mention teammates, attach files, react, or add further replies without leaving the channel you were viewing. following your threads select threads in the left navigation to see all the threads you are part of, regardless of which project they came from. each entry shows the original message, its project or conversation, its author, and its latest activity. open an entry to continue the conversation in the sidebar. new activity is marked unread, and opening the thread marks it as read. if you no longer want a thread in your list, hover over it and unsubscribe. connecting a thread to work use the task button in the reply composer to attach an existing project task or create a new one. the task is included with the reply, so anyone following the thread can open the work without losing the surrounding conversation.

Keep replies attached to a message and find every thread you are part of in one place.

Threads

time tracking connects the work happening in tasks with a workspace-wide report. use a running timer while you work, or add time manually when you are recording it afterwards. start and stop a timer open a task's menu and choose track time to start with the task, project, and description already filled in. you can also use the timer in the bottom-left corner of lane when the work is not tied to a task. the timer starts as billable. expand it to change the description, project, task, or billable setting. lane allows one running timer per person; starting another one stops and saves the previous timer automatically. add time manually open time in the workspace navigation and choose add time . enter a description and duration, choose whether the work is billable, then save the entry. when you open time from a project, the new entry is assigned to that project automatically. review workspace time the workspace time page brings tracked, billable, and non-billable time together. choose a project to include its planned time and current budget figures. use the controls above the report to: - select a project or work with no project; - choose a date range or clear it for all time; - show all, billable, or non-billable entries; and - group the summary by day, project, team member, cycle, or section. scroll to the bottom of a long report to load older entries. select an entry to edit its description, project, task, or billable setting; its duration can be edited directly in the list. choose csv to export the entries that match the current filters. workspace and project admins also receive the available rate, currency, and billable-value columns. rates are captured when an entry starts, so changing a rate later does not rewrite historical time. see budgets & rates to configure project economics and budget periods.

Track work with a timer or manual entry, then review time across projects, people, and delivery periods.

Time Tracking

lane gives you personal surfaces that cut across every project so you can focus on what's yours, right now. today today is a focused view of what's due and what you've planned for the day — the first place to look each morning. it is useful when you want to decide what to do now without opening every project that happens to have a task assigned to you. my work my work gathers everything assigned to you across all projects into a single list, so nothing gets lost between projects. use it for the broader queue, then move into the relevant project when you need its messages, sections, or planning context. workbench the workbench is a personal scratch space for pulling together the tasks you're actively working on, regardless of which project they live in. these are personal surfaces, not alternative project structures. updating a task from today, my work, or the workbench updates the same task in its project.

Personal planning surfaces that pull your tasks across every project into one place.

Today & My Work

every project can be seen through multiple views. switch between them without losing any data — each view is just a different lens on the same tasks. available views - list — a fast, dense list of tasks. - board — a kanban board grouped by status or field. - timeline — a gantt-style schedule over time. - calendar — tasks placed on a calendar by date. - table — a spreadsheet-style grid. pick the view that matches how you're working right now, and switch freely at any time. views are saved project objects, so you can name and order them for a recurring workflow — for example, a backlog list, an iteration board, and a release table. changing a view changes its configuration, not the tasks themselves. grouping, filtering & sorting group tasks (for example by section, cycle, or a custom field), filter down to just what you care about, and sort the results — so a busy project stays focused. use filters to make an existing project answer a specific question rather than creating a new project just for a temporary slice of work. saved views once a view is set up the way you like — with its grouping, filters, and sort — save it so you and your team can return to it in one click. a view can also be marked as a guest view, which is useful when you want to distinguish a view made for invited collaborators from the team’s working views.

See your work the way you want — list, board, timeline, calendar, and table views.

Views

webhooks let an external system send an http request into a lane project. each webhook has a receiving url that accepts json and creates a message in that project’s channel. they are useful for bringing deployment, monitoring, or other system updates into the conversation where the team works. creating a webhook create a webhook in a project, give it a meaningful name, and copy its receiving url into the external system. lane currently supports webhooks for incoming messages only; it does not send outbound event notifications to your endpoint. payloads the incoming json is rendered into the project message. leave the transformer blank to post the raw json body, or use a handlebars template to format the message. templates reference the body through , for example: with the template , the channel receives a readable update instead of a block of json. signing and delivery details lane creates a signing secret for each webhook. send an hmac-sha-256 of the raw request body in the header to have the request verified. keep the secret private. incoming payloads are limited to 256 kb, rate limited per webhook, and identical raw requests are deduplicated for a short period. build the sender so it considers a successful http response the confirmation that the project message was accepted.

Receive updates from external systems as messages in your Lane projects.

Webhooks

a workspace is the top-level container for your team. projects, people, labels, custom fields, and settings all live inside a workspace. most teams use a single workspace and add more only when they need hard separation between products or clients. creating and switching workspaces create a workspace from the workspace switcher in the top-left corner — give it a name and an icon and it becomes your team's home. use that same switcher to jump between any workspaces you belong to. workspace settings open your workspace settings to change its name and icon, manage people, and review workspace-level items such as labels. workspace administration is guarded separately from ordinary workspace membership; see members & roles for the important caveat about the current role model. sending domains you can connect a domain for project email sending. lane presents the dns records required to verify the domain, and verification is handled through the mail provider. a connected domain can be used by projects that send or receive mail; it is not an automatic-join rule for people with matching email addresses. keeping workspaces tidy use workspace-wide labels for categories that should mean the same thing across projects. keep project-specific workflow structure inside the project with sections, cycles, views, and custom fields. that division makes it easier to change one project’s process without disturbing the rest of the workspace.

Create and manage workspaces — the top-level home for your team and everything in it.