Triggers and event types
The five ways a workflow rule starts (On Create, On Update, On Event, Scheduled, Manual), the catalogue of system event types the app raises, the daily due-date events for instalments and overdue demands, how recurrences are counted, and custom event types that chain rules.
Triggers and event types
A trigger is what starts a workflow rule. NirmaanOne has five: a record being created, a record being changed, a named event happening to a record (a demand issued, a payment cleared, an offer signed), a calendar schedule, and a button a user presses. An event type is the name of one of those events. The app raises a fixed catalogue of system event types itself; you can add custom event types so that one rule can hand over to another.
How it works in NirmaanOne
The five triggers
You choose the trigger in the rule builder's Trigger section. Every kind of record offers all five.
| Trigger | Starts when | What the rule can look at |
|---|---|---|
| On Create | a new record of the entity is saved | the record and its related rows |
| On Update | a record of the entity changes; with Watched columns ticked, only when one of those columns changes | the record, plus changes.<column>.old / .new and the CHANGED_TO operator |
| On Event | the chosen event type is raised for a record | the record plus the event's details, event.<key> |
| Scheduled | the recurrence comes round; runs once per record that matches the conditions | in conditions, the record's own columns only (actions still read related rows) |
| Manual | a user picks the rule from the record's Workflows menu and fills in the Input form | the record plus input.<field> |
Details that matter:
- An update counts only when a value really changed; the created and updated stamps never count. A rule with no watched columns runs on every update of the record.
- Project scope applies to every trigger: a scoped rule ignores records of other projects.
- Changes made by rules themselves start no rules. Only a rule's Emits event type chains, at most two levels deep.
- The builder offers all five triggers for every kind of record, but two combinations do nothing useful: a Manual rule on Unit has no button, because no unit screen carries the Workflows menu, and the scheduler has no way to look up allottees, so do not create a Scheduled rule on Allottee.
System event types
Every organization is seeded with 63 system event types, listed under Settings > Workflows
Event types with a lock icon. Three groups:
- 32 domain events the app raises at business steps. By record kind:
- Opportunity: Opportunity stage changed (with
event.from_stage), Opportunity assigned. - Estimate: Estimate sent, Estimate finalized, Estimate approval requested, Estimate approved, Estimate rejected, Estimate cancelled, Estimate expired (validity passed, unit released).
- Booking: Booking created, Booking cancelled, Possession offered, Possession handed over, Conveyance registered.
- Termsheet: Termsheet issued, Termsheet accepted, Termsheet signed, Termsheet
reopened, Termsheet cancelled (each with
event.side,tenantfor a member's offer orbookingfor a buyer's term sheet). - Demand: Demand issued, Demand cancelled, Demand overdue (daily).
- Payment: Receipt recorded (when a receipt is entered, before it clears), Payment cleared, Payment bounced, Payment cancelled.
- Construction stage: Construction stage commenced, Milestone achieved, Milestone reopened.
- Commission: Commission approved, Commission cancelled.
- Schedule row: Installment due (daily).
- Opportunity: Opportunity stage changed (with
- 30 generic record events, "<Entity> record created" and "<Entity> record updated" for each of the 15 entities. These are marked "reserved": On Create and On Update rules use them internally, and an On Event rule cannot pick them ("Reserved: generic record events cannot be used by On Event rules (use On Create / On Update instead)").
- Scheduled rule matched, an internal type carrying each record a Scheduled rule matched.
On a system event type only the description, the order in pickers and the Active flag can change ("A system event type: the engine raises it itself. Only the description, order and active flag can change."); deactivating one hides it from new rules but rules already listening keep working.
Custom event types
New event type (the Create permission on Workflow Rules) adds your own: a code in capitals, digits and underscores, unique in the organization and not one of the engine's own ("This code is reserved for the engine's own event types."), a name, the entity it is about, a description and a sort order. A custom event is raised by a rule that names it under Advanced > Emits event type; rules with trigger On Event and that event type run next. Both rules must be about the same entity ("<CODE> is about <x>, not <y>"), and a rule cannot emit the event it listens to. Switching a custom event type off stops the chain: the emitting rule still runs, but the rules listening to that event no longer start. An event type that rules listen to cannot be deleted ("Rules listen to this event type. Deactivate it or change those rules first.").
The two daily due-date events
Once a day at 08:00 Indian time the engine looks for money that is about to fall due or is overdue, but only in organizations where an active On Event rule listens to that event type:
- Installment due (daily) is raised for each payment-schedule row that is Pending or
Partially Paid, whose demand is not fully paid, and whose due date is today or within the
next 7 days. The event carries
event.days_until_due(0 to 7) andevent.outstanding(the row's amount less what is paid on it). - Demand overdue (daily) is raised for each buyer's demand (a demand on a booking) that is
Issued or Partially Paid and whose due date has passed. Demands raised on a member's offer
do not get this event. It carries
event.days_overdue(1 on the day after the due date) andevent.outstanding(the demand total less what has been received).
Each record gets at most one such event per day, so a rule that should act on a particular day
compares the count: event.days_overdue == 7, event.days_until_due IN [7, 3, 0]. Without such a
condition the rule fires every day until the money is paid.
Scheduled rules and recurrences
A Scheduled rule carries a recurrence: a Start date, a Time (default 09:00), "Repeat every" N day, week (with weekday chips), month (on a day 1–31) or year (a day and a month), and an optional Until date. The engine checks every minute for rules whose next run is due, finds up to 1 000 records matching the conditions, and stages one Scheduled rule matched event per record, so each record gets its own run. Rules to know:
- The interval is counted from the start date: "every 2 weeks" runs in the start date's week and every second week after it; "every 3 months on day 10" runs in the start month and every third month after. A month without the chosen day (the 31st in November) is skipped.
- Times are in the server's time zone, which is Indian time (Asia/Kolkata) unless your provider has set it otherwise.
- When the Until date passes, the rule switches itself off. A rule whose schedule cannot be read is also switched off.
- The same record is never staged twice for the same firing, so a delayed engine cannot run one scheduled occurrence twice.
- Conditions on a Scheduled rule compare bare columns only, because they are turned into the query
that finds the records. Date tokens work:
valid_until == TODAY+2,updated_at < TODAY-7. - Use a cron expression replaces the calendar picker with a five-field cron line for people who prefer it ("minute hour day month weekday; the server checks the expression when you save.").
The date tokens (TODAY and the others) and the {{ today }} merge field resolve on the UTC
calendar date, which is the Indian date except between midnight and 05:30 IST; schedules at the
default 09:00 are unaffected.
Manual rules
A Manual rule is a button. Its Input form (1 to 20 fields: text, number, date, yes/no, a
choice list…) is what the user fills in before it runs, and the values reach conditions and
actions as input.<field>. The Workflows menu on a booking, payment, opportunity, estimate,
commission or demand page lists the active Manual rules of that record kind, in the record's
project. A rule whose conditions the record does not meet, or whose actions need permissions the
user lacks, is explained rather than run ("This workflow cannot run right now: the record does not
meet its conditions." / "You lack the permission it needs: …"). Such rules still appear in the
menu, marked as unavailable. Starting a run needs the
Create permission on Workflow Runs, which in the default roles only the Administrator
holds. The run acts as the person who pressed the button.
The split into five triggers is what lets one rule catalogue serve very different needs: On Event for the moments that matter in the business, On Update for "tell me when this field changes", Scheduled for the weekly sweep of cold leads or late stages, and Manual for the judgement calls that should stay with a person but be done the same way every time.
Example
A demand through its due-date events. Demand DM-2026-27-00042 on Unit B-1203 (Sunrise Heights) is issued on 30 Sep 2026: instalment ₹12,50,000.00 plus GST ₹62,500.00 makes a demand total of ₹13,12,500.00; the buyer deducts TDS of ₹12,500.00, so ₹13,00,000.00 is payable by 15 Oct 2026. The organization has the seeded rules "Demand 7 days overdue: call the buyer (system)" and "Demand 30 days overdue: escalate (system)" on, and has also switched on "Demand overdue: remind the buyer by email (system)".
event.outstanding is the demand total less what has been received, so it includes the TDS the
buyer deducts: before any payment it reads 13,12,500.00, ₹12,500 more than the amount payable.
| 08:00 on | Event raised | event.days_overdue |
event.outstanding |
Rules that run |
|---|---|---|---|---|
| 15 Oct 2026 | none: the due date has not passed | — | — | — |
| 16 Oct 2026 | Demand overdue (daily) | 1 | 13,12,500.00 | reminder email (matches 1 or 7) |
| 17–21 Oct 2026 | Demand overdue (daily), one per day | 2 to 6 | 13,12,500.00 | none: no rule matches those counts |
| 22 Oct 2026 | Demand overdue (daily) | 7 | 13,12,500.00 | reminder email; "7 days overdue: call the buyer" (Accountants notified, a call task for the least-loaded Sales Executive due 24 Oct 2026) |
| 23–26 Oct 2026 | Demand overdue (daily) | 8 to 11 | 13,12,500.00 | none |
| 26 Oct 2026, after 08:00: a payment of ₹5,00,000 clears; the demand is now Partially Paid | ||||
| 27 Oct – 13 Nov 2026 | Demand overdue (daily) | 12 to 29 | 8,12,500.00 | none |
| 14 Nov 2026 | Demand overdue (daily) | 30 | 8,12,500.00 | "30 days overdue: escalate" (Finance Leads and Sales Managers notified, a High task for a Finance Lead due 17 Nov 2026) |
| the day after the balance of ₹8,00,000 clears (status Paid) | none | — | — | — |
The events are staged only because a rule listens; an organization with no rule listening to
Demand overdue (daily) gets no outbox rows for the demand at all. Only cleared payments count
as received, so a cheque that is recorded but not yet cleared does not change event.outstanding.
A recurrence. A rule set to "Repeat every 2 weeks on Mon and Thu at 09:00" starting on Tuesday 29 Sep 2026 runs on Thu 1 Oct (the start week), skips the week of 5 Oct, runs on Mon 12 Oct and Thu 15 Oct, skips the week of 19 Oct, runs on Mon 26 Oct and Thu 29 Oct, and so on. Monday 28 Sep is in the start week but before the start date, so it does not run. The same rule with Until 31 Oct 2026 runs for the last time on Thu 29 Oct and then switches itself off.
Watched columns. The seeded rule "Task reassigned: tell the new assignee (system)" is On Update
on tasks, watching only the assignee. Changing a task's due date or description raises nothing;
handing it from Anil to Meera raises "Task record updated" with changes.assigned_to holding the
two users, the condition "assignee is not empty" holds, and Meera is notified.
Where you see it
- Event types: the system catalogue, the "reserved" badge, the count of rules listening, and New event type.
- New rule and Rule: the Trigger section with the five cards, Watched columns, Event type, the recurrence picker and the Input form.
- Rules: the Trigger column ("Weekly on Mon at 09:00", "button on the record", "every new record").
- Outbox: each raised event with its origin and details.
- Runs: the Trigger event column ("manual", "scheduled", "record created", "record updated" or the event's code).
- Health: the scheduler's last run and the daily due-date check.
- Demand, Payment, Booking, Estimate, Opportunity and Commission: the Workflows menu for Manual rules.
- Demand runs and Payout runs: Schedule automatic … runs, which opens a Scheduled rule ready-made.
- Construction stages: where the milestone events come from.
Related
Related
- Event typesScreen
The named events a rule can listen to: the system events NirmaanOne raises itself and the custom events you add to chain rules or to raise from your own integrations.
- New ruleScreen
Build an automation rule on a full page: which records it watches, what starts it, which records qualify, and the ordered actions it carries out.
- RuleScreen
One automation rule's page: read or change its basics, trigger, conditions and actions, test it against a record, clone or delete it, and switch a system rule on or off.
- RulesScreen
Every automation rule in your organization, system and custom, with filters, the switch that turns each rule on or off, and shortcuts to edit, test, clone, see the run history of or delete a rule.
- OutboxScreen
The events recorded when records change, on their way to the rules that listen to them, with the runs each event produced and the panel from which a failed event is requeued.
- RunsScreen
Every time a rule ran: what started it, which record it worked on, how each action went, and the panel from which an errored run is retried.
- HealthScreen
Whether the automation engine can process what the rules produce: the engine flag, its message queue, its worker, the outbox and run counts, and the scheduler's heartbeat.
- DemandScreen
One demand: the installments it bills, its amounts with GST, the expected TDS and what is payable in money, the receipts and TDS credits against it and how the money is placed on the charges, with the actions to edit, issue, cancel or delete it.
- PaymentScreen
One receipt or payout: its details, amounts and allocations, and the actions to clear it, bounce it, cancel it, edit it or delete it.
- Demand runsScreen
Every demand run of the chosen books, the dialog that previews and drafts a run billing everything due on a project, and the scheduled rules that create runs automatically.
- Payout runsScreen
Every payout run of the chosen books, the dialog that drafts a new run of member benefits, commissions or refunds, and the scheduled rules that draft runs automatically.
- Booking overviewScreen
A booking's home page: the applicant and unit, parking, dates, money summary, termsheet status and possession, with the buttons to edit the booking, see its history, jump to the opportunity or cancel it.
- EstimateScreen
One estimate version: its charges by group, payment plan, approvals, unit and parking hold and validity, with the lifecycle actions to send, finalize, request approval, approve or reject, extend, cancel, version and book.
- Opportunity (Overview tab)Screen
One buyer's enquiry on one project: who they are, what they want, the current estimate, the latest activity, documents and tasks, with the pipeline actions (estimate, assign, book, mark lost, reopen) in the header.
- CommissionScreen
One channel-partner commission: the partner, the brokerage with GST and TDS, the payouts against it, and the actions to edit, approve, cancel or delete it.
- Construction StagesScreen
Plan the project's construction stages (plinth, slabs, possession…) with their shares and dates, record commencement and completion, and keep the certificates and photos for each stage.
- Workflow rules, conditions, actions and the rule ownerConcept
What a workflow rule is made of (one kind of record, one trigger, conditions, ordered actions, an optional chained event), how conditions and action settings are evaluated, how versions, tests and clones work, and why every rule has an owner whose permissions its runs use.
- Workflow runs and the outboxConcept
How a change becomes automation: the outbox event written with the change, the pick-up that hands it to the engine, one run per listening rule with a recorded result per action, the statuses each passes through, and how Errored runs are retried and Failed events requeued.
- System rules and starter templatesConcept
The 53 automation rules, six email templates and six draft document templates every organization starts with: which ship switched on, why the customer-facing ones ship off, what is locked, and how to switch, clone or customise them.
- Demands, demand runs and the GST splitConcept
A demand is the bill raised on a buyer's installments (or a member's offer charges): numbered by financial year, billing the full total with the buyer's expected 194-IA TDS shown apart, posted as a sales voucher with GST split as CGST + SGST or IGST by place of supply; a demand run raises one demand per buyer for everything due by a date.
- Payment plans: lumpsum, cadence, custom and construction-linkedConcept
A payment plan says how the buyer's total is collected: all at once, in equal installments on a cadence, on agreed dates, or as construction stages are achieved; it lives on the estimate as numbered versions, is finalized with the price for approval, and becomes the booking's schedule.
- Estimate validity and the unit holdConcept
A sent estimate holds its unit (and the parking slots it picked) for that buyer until its Valid until date; the hold starts on sending, can be extended with a reason, and an hourly job expires the estimate and frees the unit the day after the date passes.