Automations
Automations
One rule engine for every module. Pick an entity, choose a trigger, add conditions, then let actions update fields, email people, create tasks, call a webhook or hand the record to AI.
Updated Jul 25, 2026
Configuration · Automation · 9.2
Automations are the conditional logic behind the platform: when this happens to that record, and these conditions hold, do the following. Where Gfacility used to have a separate rule screen per module, there is now one engine under Settings, Automations, Automation rules covering tickets, tasks, bookings, visitors, configuration items, assets, knowledge base articles, catering orders and service requests.
That matters for a reason beyond tidiness: a rule you learn to build for tickets works the same way for bookings. One mental model, one place to look when something fires unexpectedly, one run history for the whole company.
Why this matters to the business
"Nobody confirms a request"
Ticket created, email the requester their ticket number. No agent has to remember it.
"Escalations arrive too late"
Priority becomes highest, alert the assignee and the whole workgroup in the same second.
"Records go quiet and nobody notices"
Open and untouched for seven days, add an internal note and nudge the assignee.
"Our other systems never hear about anything"
A webhook pushes the change to your ERP or BI stack the moment it is saved.
Anatomy of an automation rule
| Part | What you decide |
|---|---|
| Entity | Which record type the rule watches: ticket, task, booking, visitor, configuration item, asset, knowledge base, catering order or service request. |
| Trigger | The moment of evaluation. One trigger per rule, seven to choose from (see below). |
| Conditions | A nested AND / OR / NOT tree over the entity's own fields and custom fields. Operators include equals, in, contains, greater than, is empty and between, plus the change-aware ones: changed, changed to, changed from. |
| Actions | One or more, in a set order. Seven types (see below). Each action can carry its own extra conditions. |
| Apply to | Per action, which record it touches: the record itself, its parent, its children, all descendants, its tasks, the whole task subtree, or a booking's visitors and catering orders. Optionally only the first match, or filtered by its own conditions. |
| Run limit | Every time, once per record, once per booking, or every Nth time. This is how you build "ask for a rating on every tenth closed ticket" without spamming everyone. |
| Stop on first failed action | On: the remaining actions are skipped when one fails. Off: everything runs regardless. |
| Active | A rule stays inactive until you switch it on, so you can build it in peace. The form says so plainly while it is still a draft. |
The seven triggers
Created
A new record is saved for the first time.
Updated
An existing record changes. Combine with "changed to" conditions to catch one specific transition.
Deleted
A record is removed. Useful for audit webhooks.
Conversation added
A new message lands on the record's Communication tab.
Reaction added
Someone reacts with an emoji, a light-touch signal you can act on.
On a schedule
A start date plus a recurrence, from hourly upwards, expanded in your company timezone. Optionally scoped to specific records you pick.
Before or after a date
A reminder that watches a date field on the record and fires a chosen number of minutes before or after it.
The seven actions
| Action | What it does |
|---|---|
| Update fields | Set values on the record, standard fields and custom fields alike: status, priority, assignee, classification. |
| Send email | To roles rather than addresses: assignee, creator, requester, watchers, workgroup members, organizer, host, the visitor, mentioned users, or a fixed address. Either an email template or a subject and body you write inline. |
| Create task | A follow-up task on the record, from a task template or spelled out, with type, classification, status, priority and a due-date offset. A task can wait on an earlier action in the same rule. |
| Webhook | A signed HTTP call to an external system. See 9.4 Webhooks. |
| Trigger AI | Hand the record to the AI assistant: run the matching AI use cases, or give one agent a custom instruction in your own words. |
| Send chat message | A message through the Gfacility bot in Microsoft Teams or Google Chat, from a bot template or written inline. |
| Add comment | Post a note on the Communication tab, as an internal note, a client note or a public note. |
Start from a preset, not an empty form
A new rule opens on a gallery of best-practice presets, each of which lands in the builder fully configured for you to adjust. Ten ship today, among them: confirm new tickets to the requester, escalate highest-priority tickets, notify the assignee of new replies, remind the assignee before the due date, nudge inactive records, remind external visitors three days before a booking, alert on a cancelled booking, ask for feedback an hour after a booking ends, ask for a rating on every tenth closed ticket, and an AI summary on new tickets.
Building from a preset is the fastest way to learn the engine, because you get to see a working combination of trigger, conditions and actions before you invent your own.
Test before you activate
Dry run
Pick a real record and see exactly what the rule would do to it, without changing anything. The run is logged as a dry run, so you can compare it with the real thing later.
Run history
Every execution is recorded per rule and company-wide, with a status of success, partial, failed, skipped or dry run, the entity it touched, and the old and new value of each field the rule changed.
Run history is the answer to “why did this ticket suddenly get assigned to me”. Filter by entity, open the run, read the resolved values. Skipped runs are as informative as failures: they tell you a run limit or a condition kept the rule from firing.
What happened to the old rule screens
Which decisions will you make?
Naming convention
"Ticket, highest priority, alert workgroup" still reads a year from now. "Rule 47" does not. The list shows your description, so write one.
Who may build automations
The automation permissions are separate from module rights. Grant them deliberately, to a small group.
Order of the rules
Rules on the same entity run in list order, which you set by dragging. Put the narrow rules above the broad ones.
Migration order
Rebuild the legacy rules that reach customers first (confirmations, escalations), then the internal housekeeping.