Join the LadVen OS testing programRequest a demo
Skip to main content

Task rules

A task rule is an automatic step: "when an event happened and the conditions are met — do an action." Rules remove manual routine: you don't need to manually change the status, assign an assignee, set a due date, or write a repetitive comment — the portal does it for you according to the process you described.

Rules are configured on the task automation page at /tasks/automation, the "Rules" tab. This is the workplace of the task process administrator.

When you need task rules​

A rule is worth creating where the same manual step repeats across tasks. Typical cases:

  • when a task of a certain type is created, immediately assign an assignee;
  • when a task moves to the "In review" status, set a due date and notify the manager;
  • when a comment is added by the customer, change the priority;
  • when the due date changes, automatically create a reminder subtask.

If a step happens rarely or is different each time — you don't need a rule, it's easier to do it manually.

Where to configure​

Open /tasks/automation. The task automation page is split into tabs:

  • Rules — event → conditions → action;
  • Guards — blocking checks before an operation (see Operation guards);
  • Recurring — scheduled tasks (see Recurring tasks);
  • History — what fired and when.

This page is about the "Rules" tab. Managing them requires task automation permissions; without them, rules are visible read-only.

What a rule consists of​

Every rule is assembled from three parts:

  1. Trigger — the event that starts the rule.
  2. Conditions — additional checks under which the rule fires (optional).
  3. Action — what the portal will do. A task rule has a single action.

First describe the process in words: "when… and if… — then…", and only then move it into the rule form.

Triggers​

A trigger is chosen from a set of task events:

  • task created;
  • task changed;
  • status changed;
  • due date changed;
  • comment added;
  • time logged.

For field-change events (status, due date) you can specify which value the transition went from and to — this turns a general trigger into a precise one.

Conditions​

Conditions narrow the firing so the rule doesn't run on every task indiscriminately. A condition checks a task field: for example, only a specific project, priority, type, or a particular "from" → "to" transition. Several conditions are combined together, so the rule fires only on the needed slice of tasks.

The more precise the conditions, the fewer false triggers and the clearer the run history.

Action​

A task rule performs a single action. Available actions include:

  • change the status;
  • assign an assignee;
  • set or shift the due date;
  • add a comment;
  • notify participants;
  • create a subtask;
  • create a related deal in CRM.

If a single event requires several actions in a row or branching — that's no longer a task rule but a CRM robot or a workflow.

Preview before enabling​

Before you enable a rule, run it through a preview (simulation): the portal will show which tasks the rule would apply to and what it would do, without changing any data. The preview is available with the corresponding permission.

The preview is the main way not to break your work: it reveals overly broad conditions and unexpected firings before the rule touches real tasks.

Enabling and ownership​

A rule starts working only after it is enabled. Every rule should have a clear owner — the person responsible for the process and the one people go to with questions. The rule's change history is visible in the list: who changed it and when.

Don't enable a rule "as a test" on live tasks without a preview and without an owner — a forgotten rule with broad conditions creates noise and errors.

States and limitations​

  • the rule is disabled — it doesn't fire;
  • the preview found no matching tasks — the conditions are too narrow or incorrect;
  • the rule fired partially — some tasks didn't pass the conditions or permissions;
  • no management permissions — the rule is available read-only;
  • the run was blocked by an operation guard — the action did not execute, check the guards.

Good practices​

  • Describe the process in words before configuring: "when… and if… — then…".
  • Make the conditions as precise as possible, not "for all tasks".
  • Always run a preview before enabling.
  • Assign an owner to every rule.
  • Regularly check the "History" tab: what fired and what was blocked.
  • One event — one clear action; build complex logic with a workflow.

Common mistakes​

Enabling a rule without a preview. Broad conditions mass-change the wrong tasks, and rolling back is expensive.

Making a trigger with no conditions. A "on any status change" rule fires too often and clutters the history.

Hiding several actions in one rule. When you need a chain or branching, use a robot or a workflow, not a pile of rules.

Leaving a rule without an owner. When automation misbehaves, it's unclear who to turn to.

How to verify the result​

  • the "History" tab shows the rule firing on the intended task;
  • the task received the expected status, assignee, due date, or comment;
  • the rule did not touch tasks outside the conditions;
  • blocked runs are explainable (an operation guard fired or there were no permissions).