Workflow rules, conditions, actions and the rule owner

A workflow rule is an instruction of the form "when this happens to this kind of record, and these conditions hold, do these things in this order". Each rule watches one kind of record (an opportunity, a demand, a booking…), starts on one trigger, filters the records with conditions and runs up to 25 actions. The rule owner is the user whose permissions the rule's runs act with, so a rule can never do more than a real person in your organization could.

How it works in NirmaanOne

Where rules live

Rules are managed under Settings > Workflows > Rules. Seeing them needs the View permission on Workflow Rules; building, changing, switching and deleting need Create, Edit and Delete on the same module. In the default roles only the Administrator holds those three, so building automation is an administrator's job unless you grant the permissions. Every save is recorded in Settings > Audit log.

What a rule is made of

• Name (unique in the organization, "A workflow rule named '<name>' already exists") and an optional Description.
• Entity: the kind of record the rule watches, one of 17: Opportunity, Estimate, Booking, Allottee, Termsheet, Schedule row, Demand, Payment, Commission, Construction stage, Contact, Unit, Task, Project, Books, RERA sweep and Escrow withdrawal. It is fixed once the rule exists ("clone the rule to change it").
• Project scope: all projects, or one. A scoped rule ignores records of other projects. Contact rules are always organization-wide ("Contact rules are organization-wide"). Books belong to no project, so leave the scope empty on a Books rule.
• Priority from −1000 to 1000, default 0: when several rules match the same event, the lower number runs first (ties by the older rule).
• Active: "Inactive rules are kept but never run."
• Trigger: On Create, On Update, On Event, Scheduled or Manual. See Triggers and event types.
• Conditions, Actions and, under Advanced, an Emits event type.

Conditions

Conditions decide which records the trigger delivers actually run the actions. Leave them empty and every delivered record runs ("No conditions: the rule matches every record."). Otherwise you build a tree of comparisons joined by all of these (AND) or any of these (OR), with groups nested at most 5 levels deep and at most 50 comparisons in all.

A comparison has a field, an operator and a value:

• Fields: a column of the record (status, agreed_total_amount, valid_until); a field of a related row (contact.email, project.name, unit.unit_number); or context the trigger brings: input.<field> from a manual form, event.<key> from the event (event.days_overdue, event.side), changes.<column>.old / .new for On Update, and actions.<n>.<key> for the result of an earlier action (in an action's own Only when… block).
• Operators: ==, !=, >, >=, <, <=, IN, NOT IN, and CHANGED_TO (On Update only: true when the column just became this value).
• Values: numbers compare as numbers whatever the formatting, dates as dates, and the tokens TODAY, THIS_MONTH_START, THIS_MONTH_END, LAST_MONTH_START, LAST_MONTH_END, each with an optional +N or −N days (TODAY-7, TODAY+2), resolve on the day the rule runs. That day is the UTC calendar date, which is the Indian date except between midnight and 05:30. The builder offers Today, Today + days and Today − days for date fields.

Scheduled rules are different: their conditions are turned into a database query to find the matching records, so they may compare bare columns only ("Scheduled rules compare bare columns only.").

Actions

Actions run in order, top to bottom, and the rule needs at least one (or an emitted event): "A rule needs at least one action or an emitted event". Each action is one operation from the catalogue, in two groups:

• Side effects: Notify users (in-app notification to named users, users named on the record such as its assignee or creator, or every member of a role), Create task (assigned to a user, a user field of the record, or the least-loaded member of a role, with a due date N days out), Close open tasks (the record's Open and In Progress tasks become Cancelled, each with a note "Closed automatically: <note>."), Send email (a message template or inline subject and body, up to 20 recipients, up to 5 generated-document attachments), Update field (one of the record's non-financial columns), Call webhook (an HTTPS request to a public endpoint) and Generate document (a published document template rendered as PDF or Word, optionally emailed). Send WhatsApp and Send SMS are listed but "Not available on this server".
• Domain operations: the same changes a user would make from the screens, with the same rules: Cancel booking, Cancel the booked estimate, Cancel the allottee's offer, Reverse demand, Release unit, Assign opportunity, Mark opportunity lost, Reopen opportunity, Create demand run, Create payout run, Prepare revenue run and Post RERA sweeps (on a project: one sweep per clearing date for the receipts not yet swept from the collection account; on a payment: one sweep for that receipt alone, dated its clearing date; the escrow share in force to the RERA separate account and the rest to the operative account, as one Contra voucher; posted at once unless you untick it, in which case Draft sweeps wait under RERA sweeps; see RERA accounts and the daily sweep). Refund payment and Post charge are listed but unavailable; the cancellation wizard covers them.

Each action card shows what it needs ("Needs <permissions>"), and offers:

• Name (optional), Active (an inactive action is skipped) and Continue on error (a failed action is recorded and the run carries on; the run still ends Success with a note such as "1 action(s) failed and were skipped: SEND_EMAIL").
• Only when…: a condition block evaluated just before the step; when it is false the step is Skipped and the run continues. It can read earlier results, for example actions.0.created == true.
• Text settings (titles, bodies, recipients, reasons) take the same merge fields as message templates, and the results of earlier steps as {{ actions[0].run_no }} or {{ actions[0].task_id }}.

The "least-loaded member of a role" is the active member with the fewest open tasks (for tasks) or open opportunities (for assignments), ties broken by email, so work spreads evenly over time.

Chaining rules

Under Advanced, Emits event type names a custom event type of the same entity that is raised when the rule finishes successfully. Rules listening to that event run next. Nothing else a rule does triggers other rules: a task created by Create task does not fire "Task assigned", and a lead assigned by a rule does not fire rules on "Opportunity assigned". A chain may run at most two levels deep; beyond that the listening rules get a Blocked run.

Saving, versions and tests

• Saving validates everything at once: the trigger, watched columns, the schedule, every condition path ("conditions: <path> is not a field of <entity>"), every action's settings and template syntax, and, importantly, that you hold every permission the actions need. If you lack one, the save is refused with a message such as "actions[0]: CREATE_TASK needs …" followed by the missing permission.
• A new rule is version 1. Each save that changes the definition raises the version by one; runs record the version they ran, so old runs still make sense after a change. Switching a rule on or off does not change its version.
• Test dry-runs the saved rule against one real record without running any action: it shows Matches / Does not match, whether the record is In scope, each condition with its actual value, and per action Would run, Skipped by conditions, Inactive, Unavailable or Blocked: missing permissions.
• Clone copies a rule as "<name> (copy)", inactive, for you to change.
• A rule that has ever run cannot be deleted ("This rule has run before, so it is kept for history. Deactivate it instead of deleting."), so run history always points at a rule.

The rule owner

Every run acts as a specific user:

• Runs started by an event or a schedule act as the rule's owner: the last person who saved or switched the rule (the creator until then). For system rules that ship on, the owner is the administrator who created the organization (or, for rules added to an existing organization later, its earliest active Administrator).
• Runs started by hand from a record's Workflows menu act as the person who pressed the button.

The owner's permissions are read again at the moment each action runs, not from when the rule was saved. If the owner has lost a permission the action needs, or the owner's account was deactivated, the action fails with a "permission_revoked: the acting user no longer holds …" error that names the missing permission, and the run ends Errored. Actions that need no permission, such as Notify users, still run for a deactivated owner. To recover, restore the permission, or have someone who holds it switch the rule off and on (which makes them the owner), then Retry the run.

Because switching a rule on or off, even from the Active toggle on the list, hands ownership to whoever did it, the app re-checks the whole rule against that person's permissions every time it is switched, on or off, and refuses the switch if one is missing ("You do not have permission to do that." on the list).

This design is the reason a rule can never be used to get around permissions: the automation is only ever as powerful as the person who owns it.

Example

Sunrise Developers LLP wants its Finance Lead to sign off every booking above ₹2 crore in Sunrise Heights. Priya, the Administrator, builds the rule:

• Basics: name "High-value booking: finance sign-off", entity Booking, project scope Sunrise Heights, priority 0, Active ticked.
• Trigger: On Event, event type Booking created.
• Conditions: all of these: agreed_total_amount >= 20000000.
• Actions:
  1. Notify users, roles Finance Lead, title High-value booking {{ entity.booking_no }}: Rs {{ entity.agreed_total_amount | inr }}, body Buyer {{ contact.first_name }} {{ contact.last_name }}, Unit {{ unit.unit_number }}. Review the payment plan before the agreement.
  2. Create task, assign to A role Finance Lead, title Sign off booking {{ entity.booking_no }}, Due in days 3, Priority High, with Only when… actions.0.count > 0.

Saving needs Priya to hold the Create permission on Tasks (she does, as an Administrator). The rule is saved as version 1 with Priya as its owner.

On 3 Oct 2026 a Sales Executive books Unit B-1203 for Mr Rohan Mehta at an agreed consideration of ₹2,35,00,000 (booking BK-2026-27-00007). The event fires; the seeded rule "Booking created: accounts and legal (system)" and Priya's rule both listen at priority 0, so the older, seeded rule runs first. For Priya's rule, ₹2,35,00,000 ≥ ₹2,00,00,000 holds, so a run starts acting as Priya:

1. Both Finance Leads, Anil and Meera, get the notification "High-value booking BK-2026-27-00007: Rs 2,35,00,000.00". The result records count: 2.
2. actions.0.count > 0 holds. Anil has 4 open tasks and Meera has 2, so the task "Sign off booking BK-2026-27-00007" goes to Meera, due 6 Oct 2026, priority High, linked to the booking.

A booking the same afternoon at ₹1,80,00,000 fires the same event, but ₹1,80,00,000 < ₹2,00,00,000, so no run is created for Priya's rule; the seeded rule still runs. A booking in another project is outside the rule's scope and is ignored by it.

Three weeks later Priya leaves and her account is deactivated. The next qualifying booking runs action 1 as before (notifying needs no permission), then action 2 fails with a "permission_revoked" error naming the Create permission on Tasks, and the run ends Errored. Rahul, another Administrator, switches the rule off and on again, becoming its owner, and presses Retry on the run; it resumes at action 2 without notifying anyone twice.

Where you see it

• Workflows: the automation area and the engine banner.
• Rules: every rule with its trigger, scope, priority, last run, Active toggle, Test, Clone and Delete.
• New rule and Rule: the builder with Basics, Trigger, Conditions, Actions and Advanced.
• Event types: the events an On Event rule listens to and the custom ones a rule may emit.
• Runs: what each rule did, action by action, with Retry.
• Health: whether the engine is processing at all.
• Message templates: the wording Send email actions use.
• Booking and the other record pages with a Workflows menu, where Manual rules are started.
• Roles & Permissions: the permissions the owner must hold.
• Audit log: every change to a rule.

Related

• Triggers and event types
• Workflow runs and the outbox
• System rules and starter templates
• Message templates
• Roles and permissions
• Audit trail and record history