Requests between colleagues
What your colleagues need from you stops living in chat and in corridor conversations. A request lands in one list, becomes a task in one click, and the sender finds out when it is done.
One list instead of the corridor
A colleague writes what they need and by when. They pick no project and no column — they need to know nothing about your projects. You see everything waiting on you in one place.
A task in one click
Turn an incoming request into a task in any project. Title, description, priority and the suggested deadline come prefilled — confirm the date or rewrite it to suit you.
You can say no, but with a reason
A request is not an order. You can reject it or forward it to the colleague it belongs to. A reason for rejection is mandatory, so the sender knows what happens next.
The sender never has to chase you
Finish the task and the request closes itself, with a notification to the sender. They see the status the whole time — waiting, accepted, done, rejected.
Why have requests when we already have tasks?
A task is something a manager assigns you or you create for yourself. Most work, though, arrives differently — a colleague catches you in the corridor, writes in chat, mentions it in a meeting. None of that is recorded anywhere until you rewrite it as a task yourself, and part of it simply gets lost. A request is where it waits: the colleague writes what they need and by when, and you decide. It is deliberately not a task — the sender picks no project, no column and no binding deadline, and needs to know nothing about your projects.
How does a request become a task?
Open the request and click Make it a task. You choose the project it belongs to, and the task is created with the title, description, priority and suggested deadline already filled in. You can rewrite the deadline and the priority — the suggested date is a proposal, not a commitment, and this is exactly the moment the agreement is confirmed. You become the assignee, and the request stays linked to the task.
What if I don't want a request, or it isn't mine?
You reject it, but you have to give a reason — without one the rejection cannot be sent. That is deliberate: a request that disappears without explanation teaches the sender not to bother, and the feature dies within a month. If the work belongs to somebody else, you forward it. Forwarding does not start a new thread — the recipient changes and it stays visible who passed it on.
How does the sender find out it is done?
On their own. When the task created from a request moves to Done, the request closes itself and the sender gets a notification. The whole time they can see the status — waiting, accepted, done, rejected, withdrawn — in their Sent tab. Requests are available on every plan, Free included.