Omnisnia CRM Docs / Workflow Automation

Workflow Automation

Workflow automation lets Omnisnia react to changes in your data without anyone lifting a finger: when a record is created or updated, a rule runs an action such as creating a task, updating a field, or assigning a record. Rules can also require a person to approve before the action runs.

Workflow rules

A workflow rule is a no-code “when this happens, do that” instruction. Each rule has:

  • A name — what the rule is for.
  • A trigger — what makes the rule fire:
    • Record created — the rule runs when a new record of a chosen type is created.
    • Record updated — the rule runs when a record of a chosen type is changed.
  • A trigger entity — which record type the trigger watches (for example clients or deals).
  • An action — what the rule does when it fires (see below).
  • Action settings — the details the action needs (for example the title of the task to create).
  • An active switch — only active rules run.
  • An optional require approval switch — see Approval steps .

What a rule can do

A rule’s action is one of Omnisnia’s built-in actions — the same catalog the Omni assistant uses. For example, a rule can:

  • Create a task — for example, open a follow-up task whenever a deal is created.
  • Update a field on a record.
  • Assign a record to a user.
  • Create a client, lead, deal, product, case, or channel; post a message; send an email; or generate a quote.

Workflow rules may run any of the standard (non-administrative) actions. The two administrator-only actions — creating reasoning rules and creating automations — cannot be run by a workflow rule.

Creating a rule

Add a rule, give it a name, choose the trigger and the record type it watches, pick the action and fill in its settings, and make it active. From then on, Omnisnia runs the action every time the trigger condition is met.

Approval steps

Sometimes an automated action should not run until a person signs off. Turning on require approval on a rule inserts a human step: when the rule fires, instead of running immediately, it creates an approval request and waits.

The approvals queue

Approval requests collect in an approvals queue. There you can:

  • See pending requests — you can filter by status to focus on what still needs a decision.
  • Approve a request — the action then runs.
  • Reject a request — the action is discarded and does not run.

This is useful when an action has consequences you want a person to confirm — for example sending an email or creating a deal — while still letting the routine parts of the workflow happen automatically.

← PreviousCollaboration