Add Automation Rules
Add Automation Rules turns an existing plugin into a workflow-enabled app with automation defaults, a Workflows tab, and CRUD screens for managing rules. Use it when you want record-triggered notifications, status-based follow-ups, and overdue reminders without building automation from scratch.
Trusted by frontline teams 15 years of frontline software
Built for: Facilities Management · Manufacturing · Healthcare Operations · Education · Property Management
Overview
Add Automation Rules is an edit-mode template for an existing plugin that needs workflow logic without a full rebuild. It adds the automation capability, seeds sensible automation_defaults, and creates a Workflows UI so users can manage _automation_rule records from the app instead of editing code.
Use this template when your plugin already has record types with a clear lifecycle, such as incidents, maintenance requests, equipment sign-outs, inventory items, or visitor logs. It is especially useful when records need a notification on creation, a field_changed trigger on the primary status or category field, or a schedule-based reminder for overdue items. The template also includes CRUD routes and views so rules can be listed, toggled, edited, and deleted in a predictable way.
Do not use it for static reference content, one-off forms, or apps where automation would duplicate a first-party workflow product. It is also a poor fit if the plugin has no meaningful status field, no time-bound follow-up, or no clear role separation for who can manage rules. The value of this template is in making workflow behavior visible, editable, and tied to the record model the plugin already uses.
Standards & compliance context
- For incident, inspection, or secure-facility visitor records, automation should support auditability and consistent follow-up aligned with common recordkeeping and access-control expectations.
- If the plugin handles regulated operational records, keep rule changes visible and reviewable so administrators can show how notifications and reminders are configured.
- When automation supports time-bound follow-up, align reminder timing and retention practices with your organization's policy and any applicable industry recordkeeping requirements.
General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.
How to use this template
- Add the automation capability to plugin.rb and expose a Workflows navigation tab so the rule manager is reachable from the app.
- Define automation_defaults for the plugin's record types, including a creation notification, a field_changed rule for the main status or category field, and a schedule rule when overdue reminders make sense.
- Create workflows_controller.rb with index, new, create, edit, update, destroy, and toggle actions for _automation_rule records.
- Build the workflows index view to list each rule with its enabled state and controls for toggle, edit, and delete.
- Build the new and edit wizard views so users can choose a trigger, add conditions, define actions, and save the rule with the right scope.
- Add the workflow routes, then test the defaults with sample data to confirm the rules fire on the intended record types and statuses.
Best practices
- Tie each rule to one clear record type and one primary status or category field so the workflow logic stays understandable.
- Seed only a few defaults at first, because too many starter rules make the Workflows screen hard to trust and harder to debug.
- Use schedule rules only for records that truly need follow-up, such as overdue maintenance, pending approvals, or unreturned assets.
- Show the enabled or disabled state prominently in the index view so users can tell which rules are active without opening each record.
- Photograph or attach evidence only when the underlying record type benefits from audit context, such as incidents or inspections.
- Keep role and permission boundaries explicit so only the right users can create, edit, or delete automation rules.
- Test each default rule with sample data on first open to confirm the trigger, condition, and action chain behaves as expected.
What this template typically catches
Issues teams running this template most often surface in practice:
Common use cases
Frequently asked questions
What does this template add to my plugin?
It adds the automation capability, a Workflows navigation tab, workflow routes, and a workflows_controller with full CRUD for automation rules. The template also includes index and wizard-style new/edit views so users can create, toggle, edit, and delete rules. It is meant to extend an existing plugin, not replace its core record types.
What kinds of automation rules are included by default?
The template seeds 2-3 sensible automation defaults based on the plugin's record types. Typical defaults include a notification when a record is created, a field_changed rule for the main status or category field, and a schedule rule for overdue or reminder scenarios when the data model supports it. These defaults help the app demo well on first open and show the intended workflow pattern.
Which plugins is this template a good fit for?
It fits plugins that manage operational records such as maintenance logs, incident logs, visitor check-ins, equipment sign-out, inventory items, or room bookings. If the plugin already has a clear primary status field and a few record types that benefit from notifications or reminders, this template usually fits well. It is less useful for static reference apps with no record lifecycle.
Who should manage the workflow rules?
Usually an admin, operations lead, or power user should manage them because they control trigger logic, conditions, and actions. The template's CRUD screens make rule management visible and editable instead of hiding it in code. If your team needs tighter control, you can restrict create, edit, and delete permissions while still allowing read-only access.
How often should automation rules be reviewed?
Review them whenever the underlying record process changes, such as a new status, a new SLA, or a new notification recipient. A periodic review is also useful after rollout to catch duplicate alerts, stale reminders, or rules that never fire. If the plugin supports time-bound records, overdue rules should be checked more often than simple creation notifications.
Does this template support compliance or audit needs?
Yes, when the plugin tracks regulated records such as incidents, inspections, or secure-facility visitor logs, automation can support consistent follow-up and auditability. The template helps preserve a visible rule set, which is useful for showing who gets notified and when. It should still be paired with your organization's retention, access, and review policies.
What are the most common mistakes when using this template?
A common mistake is creating too many overlapping rules, which leads to duplicate notifications and confusion. Another is using vague conditions instead of tying rules to a specific status, category, or overdue state. Teams also sometimes forget to seed realistic sample data, which makes the workflow screens look empty or untested.
Can I customize the triggers and actions?
Yes, the template is designed as a starting point for your plugin's specific record types and business rules. You can adjust triggers, conditions, actions, labels, and the default rules to match your process. The wizard-style form is intended to make those changes easier for non-developers once the app is built.
How does this compare with handling automation in spreadsheets or ad hoc scripts?
Compared with spreadsheets, this template gives you a single source of truth for rules, visible status, and a repeatable workflow UI. Compared with ad hoc scripts, it makes automation easier to review, toggle, and maintain inside the app. That reduces the risk of hidden logic and forgotten reminders.
Related templates
Ready to use this template?
Get started with MangoApps and use Add Automation Rules with your team — pricing built for small business.
