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 and bookings, set prices, call a webhook or hand the record to AI.
Updated Aug 19, 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, room bookings, visitors, configuration items, assets, knowledge base articles, catering orders, service requests, users and inbound email.
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.
This page covers the anatomy of a rule. Once that feels familiar, two follow-up pages go deeper: Advanced automations explains every flow option (parallel branches, waits, condition gates), and Automation use cases walks through complete processes such as employee onboarding across IT, HR and Facilities.
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.
"Our processes live in someone's head"
Onboarding, approvals, follow-ups: one rule creates the tasks, waits for them and chases the stragglers.
"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, room booking, visitor, configuration item, asset, knowledge base, catering order, service request, user or inbound email. |
| Trigger | The moment of evaluation. One trigger per rule, eight to choose from (see below). An Updated trigger also names the watched fields, so the rule only wakes up for changes that matter to it. |
| 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. |
| Steps (actions) | One or more, in a set order. Fourteen types in six groups (see below). Each step can carry its own extra conditions, and steps can also run in parallel, behind a wait or behind a condition gate; that is the territory of the advanced page. |
| Apply to | Per step, which record it touches: the record itself, its parent, its children, all descendants, its tasks, the whole task subtree, a booking's visitors and catering orders, or the records an earlier step created. 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. |
| Only run the first matching action | Off: every step whose conditions match runs, in order. On: the steps become a ladder and the first one whose conditions match wins, the rest are skipped. That is how tiered outcomes like cancellation fees are built. |
| Stop on first failed action | On: the remaining steps 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 rule form gives you two views of the same rule: the Editor, a step list you fill in top to bottom, and the Diagram, a flowchart that draws the trigger, every step, every branch and every wait. Anything you change in one view is instantly reflected in the other.
The eight triggers
Created
A new record is saved for the first time.
Updated
A field you watch changes on an existing record. Combine with "changed to" conditions to catch one specific transition, like status becoming closed.
Created or updated
Both moments in one rule, for logic that must hold from the first save onwards.
Deleted
A record is removed. Useful for audit webhooks.
Conversation added
A new message lands on the record's Communication tab.
Reaction (emoji) 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 (reminder)
A reminder that watches a date field on the record and fires a chosen amount of time before or after it.
The picker only offers what the chosen entity supports: the conversation and reaction triggers appear on record types with a Communication tab, and inbound email only knows Created. If you are looking for a trigger like “priority changed to highest”, that is not a separate trigger: it is the Updated trigger watching the priority field, plus a “changed to” condition. That combination covers every field-specific moment you can think of, which is why the trigger list itself stays short.
The fourteen actions
Actions are grouped in the picker the same way as below. Every action can be aimed at the record itself or at a related record through Apply to, and every action can carry its own conditions.
| Group | Action | What it does |
|---|---|---|
| Create | Create ticket | Open a ticket from the record, for example from an imported email, with the sender as requester and the attachments copied along. |
| Create booking | Open a booking from a meeting invitation and put its guests on the visitor list. | |
| 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. | |
| Update | Update fields | Set values on the record, standard fields and custom fields alike: status, priority, assignee, classification. |
| Set price | Price a room booking, catering or service line from its base price: a percentage, a fixed amount, per unit, or free. A manual price overrule always wins. | |
| Conditions | Condition | A gate in the middle of the flow: continue only when the criteria match, otherwise skip the steps behind it. |
| Wait | Hold the steps below until the tasks above are done, a moment is reached or a record changes. This is what turns a rule into a process. | |
| Communication | Add comment | Post a note on the Communication tab, as an internal note, a client note or a public note. |
| 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. | |
| Send chat message | A message through the Gfacility bot in Microsoft Teams or Google Chat, from a bot template or written inline. | |
| AI & integrations | 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. |
| Webhook | A signed HTTP call to an external system. See 9.4 Webhooks. | |
| Compliance | Anonymize record | Keep the record but remove its personal data, for retention policies. |
| Delete record | Remove the record and its related data, softly or permanently. Both compliance actions re-check the author's permissions at execution time. |
Go deeper
Advanced automations →
Every flow option explained: parallel branches, waits, condition gates, joins, time limits and pending tasks.
See it applied
Automation use cases →
Complete processes, step by step: onboarding across IT, HR and Facilities, approvals, escalation ladders, feedback and retention.
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. Eleven 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 before a booking, alert on a cancelled booking, ask for feedback after a booking ends, ask for a rating on every tenth closed ticket, charge a late cancellation fee, 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, a condition or a wait kept the rule from acting yet.
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. The compliance actions check the author's permissions again at execution time.
Order of the rules
Rules on the same entity run in list order, and every matching rule runs, not just the first. Put the narrow rules above the broad ones.
Migration order
Rebuild the legacy rules that reach customers first (confirmations, escalations), then the internal housekeeping.