Tool

Automations

A rule is a sentence: when this happens, do that. Blina Desk watches the database you actually work in, not a copy of it.

See it instead of reading it

Recorded in the running product, with real data — not an animation.

A rule that runs on its ownFrom template to active rule: what triggers it, what it does, and who may change it.
Building a rule from scratchName, event, conditions, actions — and the dry run, before anyone receives anything.
The log: what actually happenedSucceeded, skipped, error: three different outcomes, with the reason spelled out.

What sets a rule off

18 tables, 7 modules

Leads, contacts, companies, opportunities and activities in CRM; quotes, orders, invoices, deals and payments in Sales; tickets in Helpdesk; employees and contracts in HR; properties and leases in Real estate; purchase orders and suppliers in Purchasing.

Created, changed, deleted

The trigger sits in the database, not in the interface. So a rule fires just as well when the record arrives through the API, through an import, or from another automation.

Conditions on fields

Only when status turns to «won», only for priority «high», only for one category. With no condition the rule runs on every event, and you notice.

More than 70 ready templates

Reminder before a contract ends, acknowledgement of a new ticket, assignment by category, follow-up on quiet quotes. Activating a template creates the rule inside your company, and you can edit it afterwards.

What a rule can do

  1. Send an email, with the record's values in the text and in the recipient's language.
  2. Send a notification to a person or a group inside the software.
  3. Send a WhatsApp message, when the WhatsApp tool is active.
  4. Set a field: status, priority, assignment, note.
  5. Create a task, with a due date and an owner.
  6. Create an activity in the history, so what happened automatically stays visible later.

What a rule cannot do, deliberately

The engine runs in a background process where nobody is logged in: there is no user whose permissions could be checked. What an automation may do is therefore fenced in by construction, not allowed case by case.

  • No free-form records in arbitrary tables. There are two named actions (task, activity) instead of one that could write anywhere.
  • Written fields come from a closed list: status, priority, assignment, notes. Never keys, never totals, never stock, never accounting.
  • Incoming email triggers nothing. A rule «when an email arrives, send an email» would feed itself: a table the engine writes to must not also start it.
  • Chains have a depth limit. A rule that fires a second one, which fires the first again, stops instead of keeping the system busy.