Automations | Help Center

Automations

Make Mployr do the routine work for you - when something happens, run the steps that always follow.

Overview

An automation is a rule in three parts:

Trigger - the event that starts it (an invoice went overdue, a leave request was submitted, a lead reached a stage)

Conditions - optional tests that decide whether this particular event qualifies

Actions - what Mployr does in response

Automations run on their own once enabled. Every run is recorded, so you can see what fired, what it did, and what it skipped.

Creating an Automation

Navigate to Automations

Click New Automation

Give it a name that says what it does ("Chase overdue invoices at 7 days")

Pick a trigger

Add conditions if the rule shouldn't apply to everything

Add one or more actions

Save, then enable it when you're ready for it to run

Mployr blocks a rule that duplicates an existing one - the same trigger with the same conditions - so you can't accidentally send everything twice.

Triggers

Triggers are grouped by the module they come from:

People - person created, person updated (optionally on a specific field), employment terminated, onboarding started or completed

Time & Attendance - timesheet submitted, approved or rejected; leave requested, approved, rejected or cancelled; clocked in or out; missed clock-out; left the work location while clocked in; shift swap requested, approved or rejected; roster published

Payroll - pay run created, approved or finalised

Accounting - invoice created, sent, paid or overdue; payment received; bill created, due soon or paid; expense created, submitted, approved, rejected or paid

CRM - lead created, activated, stage changed, won or lost; company and contact events; activity events; quote and order events

Recruitment - job posted or closed; application received; application status changed

Learning, Performance, Projects, Documents, Support, Memberships, Forms, WHS and Disputes - the main lifecycle events in each

System - date-based rules that sweep on a schedule rather than reacting to an event

Triggers that need it take their own settings - "Bill Due Soon" asks how many days before the due date, "Leave Requested" can be limited to one leave type, "Application Status Changed" to one status.

Conditions

Conditions decide whether a triggered event actually qualifies. Build them with:

Operators - equals, doesn't equal, contains, doesn't contain, greater than, less than, is empty, is not empty, is one of, is not one of

Groups - combine conditions with AND or OR, and nest groups for anything more involved

Multi-value tests - "is one of" takes a list, so one rule can cover several stages, statuses or types

Conditions can read the record that triggered the rule and its related records - a lead's stage, value, product or service and assignees; a project's owner; an activity's type.

Actions

Communicate - send an email (from a template or written inline), send an in-app notification, send an SMS

People - create or update a person, start onboarding, start offboarding

Time & leave - approve or reject a timesheet, approve or reject a leave request

Payroll - create a pay run

Accounting - create an invoice, send an invoice, send a payment reminder, record a payment

CRM - create a lead, update a lead's stage, create an activity, assign to a user, update or archive an order

Recruitment - update an application's status, send an application email

Delay - wait a set time before the next action, so a rule can chase something up later rather than immediately

Actions can use values from the record that triggered them, written as placeholders like {{person.email}}.

The Create Activity action is worth knowing in detail: it can assign to several people at once, set a due date either as "in N days" from the trigger or as a specific date, and links the activity to the company behind a lead or contact, not just the contact.

Organising Automations

As the list grows, group rules into folders - by module, by team, or by the outcome they serve. The folder tree sits alongside the list, and rules can be moved between folders.

Watching Automations Run

Every execution is recorded as a run, showing:

Which trigger fired and on which record
Which conditions passed or failed
Each action's result
Where a run is waiting on a delay, and when it will resume

Start a new rule disabled, watch a few runs, then enable it properly once it's behaving.

Frequently asked questions

My automation isn't firing

Check three things in order: the rule is enabled; the trigger is the event you think it is (a leave request being submitted is a different trigger from being approved); and the conditions aren't excluding the records you expect. The run history shows events that triggered the rule but failed its conditions, which usually points straight at the problem.

Can one automation do several things?

Yes - add as many actions as you need and they run in order. Use a delay action between them when the later steps shouldn't happen immediately.

Can I stop an automation emailing people while I test it?

Build the rule with only an in-app notification action first, watch the runs, then swap in the email action once you're happy with what it's matching.

Why was my new rule rejected as a duplicate?

Mployr blocks a rule with the same trigger and the same conditions as one that already exists, because both would fire on the same events. Find the existing rule and add your actions there, or change the conditions so the two rules cover different cases.

How do automations decide who to assign work to?

Assignment actions take a specific user, and Create Activity takes several. Where the rule works on a lead, its assignees are available as a condition, so you can route work to whoever already owns the opportunity.

Tips

Name rules after the outcome, not the trigger - you'll be reading the list months later
Start narrow, with tight conditions, then widen once you trust the rule
Use folders from the start; a flat list of forty rules is hard to reason about
Check the run history after any change to a rule
Prefer a delay over a separate scheduled rule when you want a follow-up - the run stays in one place

In this guide