Workflow rules

Every rule follows a When / If / Then structure:

• When — the trigger event that causes the rule to be evaluated.
• If — one or more conditions that must match for the rule to fire.
• Then — the action taken when the conditions are met.

Rules are evaluated in priority order each time their trigger event occurs for a service request.

• Request submitted — fires when a new service request is received, before duplicate checking or AI classification.
• Triage complete — fires after AI classification has run and the request has a suggested category, priority, and confidence.
• Request needs review — fires when a request is routed to manual review for any reason.
• Request converted — fires when a service request is converted into a work order.

Conditions filter which requests the rule applies to. You can require all conditions to match or any condition to match.

• Source — how the request was submitted, such as the FM app, the occupant portal, email, or API.
• Priority — the priority assigned during triage.
• Service category — the category assigned or selected during submission.
• Site — restrict the rule to requests for a specific site.
• Safety flag — whether the request text was flagged as a potential safety issue.
• Duplicate found — whether a potential duplicate was detected.
• Review reason — the specific reason the request was sent to manual review.

• Send email notification — sends a branded email using a configured workflow template. Choose the template and recipients when setting up the rule.
• Route to manual review — sends the request to the review queue regardless of AI confidence or other policy settings.

• Account — the rule applies to all service requests for the account.
• Client — the rule applies to all service requests for sites under the selected client.
• Site — the rule applies only to requests for the selected site.

• Rules are evaluated in ascending priority order. A rule with priority 1 runs before a rule with priority 2.
• If a rule has stop processing enabled, no lower-priority rules are evaluated for that request after it fires.
• Use stop processing to prevent multiple conflicting actions from firing on the same event.

• Draft — the rule is saved but is not evaluated. Use draft while configuring a rule before making it live.
• Active — the rule is evaluated on every matching trigger event.
• Inactive — the rule is saved but not evaluated. Use inactive to pause a rule without deleting it.