Automation

Automation is what makes HotCRM do work for you — sending notifications, updating fields, creating tasks, escalating cases, all without anyone clicking a button. Five kinds of automation are available, each suited to a different job.

How HotCRM implements them: validation + field logic run as object hooks (beforeInsert / beforeUpdate); everything multi-step, scheduled, or approval-based runs as flows; and approvals are approval nodes inside a flow (ADR-0019), not a standalone process type. The platform also supports standalone workflow rules and approval-process metadata — listed below for completeness.

The five kinds

Validation rules

The simplest kind. They block a save if a condition is true.

Built-in examples:

• "End date must be after start date" (on contracts).
• "List price must be greater than zero" (on products).
• "A campaign member must have either a Lead or a Contact, not both" (on campaign members).
• "Discount % must be between 0 and 100" (on quote line items).

To add one:

1. Setup → Object → Validation Rules → New.
2. Write the condition (the fail condition).
3. Write the error message shown to the user.
4. Activate.

Workflow rules

Fire when a record matches a condition after save. Each rule can perform one or more actions.

Action types:

• Field update — change a field on the same record or a parent record.
• Email alert — send a templated email to specific recipients.
• Create task — for the record owner or another user.
• Outbound message — fire a webhook.

Built-in examples:

• Lead created with rating = Hot → email to sales manager + create a "qualify within 24 hours" task.
• Opportunity won, amount ≥ $100K → email celebration to the team, post in #wins channel.
• Case priority changed to Critical → notify on-call engineer.

Flows (multi-step)

When a single field update isn't enough — branching, loops, waits, multi-object writes, approvals — use a flow. A flow is a visual graph of nodes: get data → decide → create/update records → notify → wait → call a sub-flow.

A flow fires one of three ways, set by its start node:

• Screen — launched manually from a button/action; collects input on a screen.
• Record change — fires on insert/update (record-after-create / record-after-update).
• Schedule — runs on a cron schedule.

Auto-launch needs the triggers capability. Record-change and scheduled flows only fire when the stack's requires list includes triggers — it installs the record-change + schedule trigger providers (schedule triggers also use the job service). Screen flows are always launched manually.

Built-in flows in HotCRM (10):

Notifications inside flows are delivered by the notify node (inbox + email via the messaging service) — not the legacy script/email step, which is a no-op in 7.4.

See Customization › Extending Objects if you need to build new flows.

Scheduled automation

Time-based automation is implemented as scheduled flows — flows whose start node carries a cron schedule. See the four Schedule rows above (campaign enrollment, contract renewal, SLA monitor, stalled-deal alert). They run via the job service, so the triggers capability is paired with job (both ship in the default slate).

Date-driven field logic that needs no orchestration — defaulting a quote's expiration date, freezing an expired/accepted quote, deriving a forecast period — lives in lightweight object hooks (beforeInsert / beforeUpdate) rather than a scheduled sweep.

Approvals

Since ObjectStack 7.4, approvals are modeled as approval nodes inside a flow (ADR-0019) rather than a standalone approval-process type. On entry the node opens an approval request, locks the record while the step is pending, mirrors the live status onto an approval_status field, and resumes down the approve / reject branch.

HotCRM's built-in Opportunity Approval flow chains two approval nodes for tiered sign-off (manager → director). See Revenue › Approvals for thresholds, what approvers see, and the audit trail.

Order of operations

When a record is saved, the order is fixed:

1. System runs auto-calculations (formula fields, auto-numbering).
2. Validation rules run — if any fail, the save is blocked.
3. The record is saved to the database.
4. Workflow rules fire.
5. Flow triggers fire.
6. Field updates from workflows / flows may cascade — re-evaluating workflows up to 5 times before stopping.
7. Email alerts are queued.

Understanding this order helps debug "why didn't my workflow fire?" questions.

Email templates

Most automation actions send email. Templates live in Setup → Email Templates and support:

• Merge fields — {{Opportunity.Name}}, {{Account.Owner.Email}}.
• Conditional blocks — show only if a condition is true.
• HTML + plain text versions.
• Attachments — quote PDFs, contract PDFs.

Built-in templates cover lead-routing, opportunity wins, case acknowledgments, contract activations, renewal reminders.

Where to monitor automation

• Setup → Process Monitor — last 24 hours of automation runs with success/failure.
• Setup → Workflow Queue — pending email alerts and field updates.
• Setup → Scheduled Jobs → History — past runs of each scheduled job.
• Object → audit log — what changed on the record, who/what made the change.

Tips for admins

• ✅ Validation rules are the cheapest way to enforce data quality — use them liberally.
• ✅ One workflow per condition is easier to maintain than mega-workflows with 10 branches.
• ✅ For anything more complex than 2 actions, use a flow — much easier to debug.
• ✅ Test in sandbox before activating in production — bad automation can cascade fast.
• ✅ Document what each rule does in its description field — your future self will thank you.

Tips for users

If a record isn't behaving as expected:

1. Check the audit log — was the field updated by a workflow?
2. Check the task list — did a workflow auto-create a task you missed?
3. Ask an admin to inspect the process monitor for that record.