Contract approval in Bitrix24 (Alaio) is built with a business process: the document travels a route of approvers, each one approves or rejects, and the process tracks the deadlines itself and writes the result into the card. The stock "Document approval" action covers the basic scenario; everything else — routes by amount, control dates, escalation to a manager — is assembled from conditions and robots. Below is a working scheme, step by step.
Which stock action should approve the document?
The business process designer has two suitable actions. "Document approval" is a vote: you set a list of approvers and a threshold ("everyone", "anyone", "majority"), and the action returns "approved / rejected". "Document acknowledgement" is weaker: it only records that an employee viewed it. For a contract use "Document approval": it blocks the process until a decision is made and stores who voted and when. The rejecting approver's comment comes back as a variable — write it into the card so the manager sees the reason without digging through the log.
How do you build the approval route step by step?
A working scheme for a deal with a "Contract under approval" stage: step one is a completeness check — the Compound condition robot makes sure the amount, requisites, and validity period are filled in; otherwise the process assigns the manager a task and stops. Step two is a fork by amount: below the threshold the contract is approved by the department head, above it the CFO is added. So as not to hardcode specific people into the template, the Get employee manager robot takes the responsible person's manager from the org structure — one template for all departments. Step three is "Document approval" itself with the approvers it found. The finale is a stage change and a notification: "approved" moves the deal forward, "rejected" returns it for rework with the comment.
How do you control approval deadlines?
A contract must not hang forever. Turn the deadline into a concrete date at the start of the route: pauses are counted in calendar days, so "three days" from a Thursday means a Sunday nobody will act on. The Nearest date by condition robot takes the approval start date and returns the nearest working day — or the next Monday, or the end of the month — as the control date. From there, two techniques: in parallel with the approval, launch a branch that pauses until the control date — if there's no decision, the process sends a reminder to the approver and their manager; and write the deadline into the card right away so it's visible in the deal list and reports. In practice, "escalate to the manager on the control date" cuts the median approval time more than any regulations.
How do you insert the amount in words and requisites into the contract?
If the contract is generated from a Bitrix24 document template, the rule is simple: whatever the template can't work out for itself is worked out before generation. Both parties' requisites need no preparation — they are merge fields, and the template pulls them from the counterparty's card and from your own company details. Everything calculated is the process's job: a discounted total, a validity period, a payment date. The technique is always the same — compute it with robots, write it to a deal field, and the template inserts that field on equal footing with the others; the number's formatting is then handled by the template's own modifiers.
Common mistakes in approval processes
The first: approvers are hardcoded into the template by name — someone goes on vacation and the process stalls; use roles and the org structure. The second: no rejection branch — the process accounts only for the happy path, and a rejected contract hangs with no rework task. The third: a deadline set with no slack — it lands on a weekend or a holiday week, and escalation fires for nothing. The fourth: the approval result isn't written to the card — the status is visible only in the process log, and managers chase approvers by hand.
In summary
Contract approval = "Document approval" + a completeness check up front + a route by the org structure + a control date that lands on a working day + both outcome branches. All the missing bricks are in the Roboteka catalog; if what you need is missing — describe the task and we'll build the robot for free.