Smart Rules

Smart Rules are if / then automations that watch your devices and incidents and act on them — flipping statuses, sending emails, closing stale incidents, and more. You write the conditions; Manage1to1 applies them every time the record is created, updated, or on a schedule you choose.

A few examples of what a Smart Rule can do:

• When a device is marked Lost, email IT so they can chase reimbursement.
• When an incident has had no update in 30 days, automatically move it to Completed.
• When a brand-new incident at Oakwood High School lands in Investigating status, notify the building lead.
• When a device flips to Sold, send the admin team a heads-up.

Where to find Smart Rules

Go to Settings → Smart Rules.

The list shows every rule, its on/off status, what it targets, when it fires, what it does, and how many times it has run.

The toolbar in the top right has two actions:

• New Smart Rule — opens the rule builder.
• Run scheduled now — appears when you have at least one scheduled rule. Fires the scheduled sweep immediately instead of waiting for the next cron tick. Useful for testing a rule you just edited.

Click the green On / Off pill to enable or disable a rule without leaving the list. Click the pencil icon to edit, or the red trash icon to delete (with a confirmation).

Anatomy of a Smart Rule

Every rule has five tabs: Settings, Conditions, Actions, Test, and History.

1. Target — what the rule watches. Today: Devices or Incidents. (Settings tab)
2. Trigger — when the rule fires. (Settings tab)
3. If — one or more conditions that must be true. (Conditions tab)
4. Then — one or more actions that run when the conditions match. (Actions tab)
5. Try it — dry-run against a specific record or count how many would be affected. (Test tab)
6. See what happened — recent runs and a match-rate rollup. (History tab)

Targets

Target	What it watches
Devices	Every device row in your inventory.
Incidents	Every incident (e.g. broken screen, lost charger, water damage).

Switching the target after you've started building a rule clears the conditions and actions, because the available fields and actions are different per target.

Triggers

Trigger	Fires when…
Any save	A record is created or updated.
Only on create	A record is added for the first time.
Only on update	An existing record is edited.
Scheduled	On a cadence you pick — hourly, every 6 hours, daily, or weekly. Walks every matching record on each pass.

Scheduled rules are how you do things like "close incidents nobody has touched in 30 days". Pair them with conditions to narrow what gets touched.

Conditions ("If")

Add one or more conditions to decide whether a rule should run on a given record. Each condition is a field, an operator, and a value.

Available device fields:

• Device status — match against a device status (Active, Sold, Lost, etc.).
• Device location (building) — match against a building.

Available incident fields:

• Incident status — match against an incident status (In Progress, Completed, etc.).
• Incident building — match against a building.
• Days since incident last update — number of days since the incident was last touched. Great for stale-cleanup rules.

Use the toggle above the condition list to decide whether all conditions must match (AND) or whether any one is enough (OR). Need "match A AND (B OR C)" logic? Click Add sub-group to nest a section with its own AND/OR — sub-groups can nest as deep as you need.

Actions ("Then")

Actions run in the order you list them. Available actions:

• Set device status — change a device's status.
• Set device location (building) — move a device to a different building.
• Set incident status — change an incident's status (e.g. flip stale ones to Completed).
• Notify admin(s) by email — send a heads-up email. You can target a specific admin, a role, or every admin assigned to the relevant building.

Each action's parameters render the right pickers for you — pick a status from a dropdown, a building, or a recipient. No raw IDs to memorize.

Test before you save

The Test tab does two kinds of dry-run, with no side effects:

• Bulk preview — counts how many records currently match the conditions you've built.
• Run against a specific record — pick a single device or incident by ID and see exactly which conditions passed or failed.

Nothing is saved, no actions actually fire, and no run-log row is written. Use it to sanity-check a new rule before turning it on.

If a preview comes back with a surprisingly large number, your conditions are probably broader than you intended.

See what fired (History)

The History tab shows recent runs of this rule along with a 30-day rollup: how many records were evaluated, how many matched, the match rate, and the last time the rule fired.

Scheduled rules and the cron

Scheduled rules don't fire the instant you save them — they run on a regular sweep in the background. By default the sweep happens every 15 minutes; rules with their own cadence (e.g. Daily) wait until that interval has elapsed before they fire again.

If you want to fire scheduled rules right now for testing, click Run scheduled now in the toolbar of the list page. Manage1to1 will walk through every scheduled rule and process anything that's due, and report back how many records were affected.

Best practices

Always preview first

Before flipping a new rule on, click Preview affected to see exactly how many records would be touched. A typo in a condition can quickly turn into thousands of unintended updates.

Start narrow, then widen

When in doubt, start a rule with tight conditions, watch the Runs counter on the list page for a few cycles, and then loosen the conditions. It's much easier to add records than it is to unwind a sweep that updated the wrong fleet.

Disabling versus deleting

Toggle a rule Off when you want to keep its definition on file but pause it temporarily — for example, during a school-year rollover. Only delete a rule when you're sure you'll never need its conditions again.

Permissions

Smart Rules are gated behind the Manage Smart Rules permission. By default it's granted to the Technology Director role only, since a single rule can update many records at once. Assign it to additional roles from the user-roles management screen as needed.