A business process task is a step where the process pauses and waits for a person to act: approve a document, acknowledge it, fill in some data. Unlike a regular task, a business process task doesn't appear in the "Tasks and Projects" section — it lives in the "Business Processes" list and blocks the process from running until it gets a response. Let's look at which actions create these tasks, where an employee sees them, and how to keep them from stalling for weeks.
How is a business process task different from a regular task?
A task is a standalone entity: it has an owner, a due date, checklists, it can be delegated and commented on, and it stays in the history of the "Tasks and Projects" section. A business process task is a pause inside the process: the workflow designer has reached a "ask a person" step and is waiting. Until the assignee responds, the process stands still, and with it every step that follows — notifications, stage changes, document generation. A completed task disappears from the list, leaving its trace in the process log. The confusion is compounded by the fact that a business process can also create regular tasks — via the "Create task" action — but that's a task in the general section, with a life of its own. If an employee "got nothing" even though the process is running, they're almost always looking for the task in the wrong place.
Which actions create these tasks?
Three stock actions in the workflow designer. "Approve document" — the assignee gets "Approve" and "Reject" buttons and the process branches on the result; this is the basis of any approval. "Review document" — it's enough to confirm you've read it, with no branching: orders, regulations, new instructions. "Request additional information" — the assignee fills in the specified fields and returns the data to the process; that's how you collect missing requisites or a clarification to a request. In all three, the assignees, the name, and the description of the task are configurable. The description is the key field: put the amount, a link to the document, and the gist of the question there, so the decision can be made from the task itself, without digging through the card. For how to assemble a route from these steps, see the walkthrough of document approval.
Where does an employee see their tasks?
In the left menu — the "Business Processes" item: there you'll find the list of tasks awaiting you, with a counter of outstanding ones. In parallel, a notification arrives in the notification center — the task opens and is completed straight from it. The third place is the item's card: in a deal or a smart process you can see the running business process and its current step. The most common reason for "stalled approvals" is that the employee doesn't know about the "Business Processes" section and is waiting for a regular task, which business process tasks never reach. The cure is a single internal post with a screenshot and the habit of checking the counter in the menu — cheaper than any policy.
How do you keep tasks from stalling?
Two techniques. First — an honest deadline. Count a task's deadline in business days, not calendar days, or an approval issued late on a Friday will "go overdue" over the weekend. The Date + N business days (RU) robot adds the required number of business days to a date by the Russian production calendar — weekends and holidays aren't counted — and returns the date in two formats: one for a field and one for a notification text. Second — escalation. If the deadline has passed with no response, the process finds the assignee's manager with the Get an employee's manager robot: it returns the direct manager's ID, name, and email from the department structure, plus a "found" flag — and the next task goes to them.
How do you check the data before issuing a task?
The worst task is one you can't make a decision on: an invoice approval with no amount, a contract with no counterparty requisites. Every such case is an extra "rejected, sent back for rework" round and a loss of trust in the process. Before the "Approve document" action, place the Check that a field is filled in robot: it takes the entity type, its ID, and the field code, and returns a Y/N flag and the current value. If the field is empty, the process doesn't issue the task but returns the card to the responsible person with a note on exactly what to fill in. Approvers quickly learn: if a task has arrived, everything is ready for a decision — and they respond noticeably faster.
Bottom line
A business process task is a process step that waits for a person: approval, review, or filling in data. Look for these tasks in the "Business Processes" item of the left menu and in notifications, not in "Tasks". To keep them from stalling: deadlines in business days, escalation to the manager via the org structure, and a filled-in check on fields before the task is issued. Ready-made bricks for all of this are in the Roboteka catalog: installed from the Bitrix24 Market and working in the same workflow designer, right next to the stock actions. Don't have the one you need? Describe the task — we'll build the robot for free.