Consolidating Fragmented Automations

Summary
Consolidate the platform’s two separate automation surfaces — Smart Rules (nested under Settings, covering devices and incidents) and Workflows (nested under Support Center, covering tickets) — into a single top-level “Automations” section in the primary navigation. From that one hub, admins would build and manage automated actions across every relevant object type: devices, incidents, tickets, users, and any future objects the platform adds.

Problem
Automation in the platform works, but it’s split across two locations that behave like separate products:
∙ Discoverability. Smart Rules live several clicks deep under Settings; Workflows live under the Support Center next to tickets. New admins routinely don’t realize both exist, and experienced admins have to remember which surface owns which object type before they can even start building a rule.
∙ Inconsistent mental models.
Because the two surfaces evolved separately, the terminology, trigger/condition/action structure, and UI patterns don’t fully match. Learning one doesn’t fully transfer to the other, and documentation and training have to cover both.
∙ Artificial object boundaries. Some real-world automations naturally span object types — a ticket that resolves should update the device status; an incident should open a ticket and change the device’s assignment; a user leaving the organization should trigger check-ins and status changes across their devices. Today those cross-object flows either can’t be built at all or require chaining rules across two different tools.
∙ Duplicated maintenance. Similar logic (notifications, status changes, assignment updates) is configured in two places with two different editors, making audits, reviews, and cleanup harder than they need to be.
∙ Scaling limits. As the platform grows to cover more object types (warehouse locations, insurance claims, lifecycle stages, etc.), continuing to add automation into whichever section “owns” that object will keep fragmenting the experience.
Proposed Solution
∙ Top-level “Automations” navigation item in the primary navigation pane, at the same level as Support Center — the single place to view, create, edit, enable/disable, and audit every automated action in the system.
∙ One unified builder with a consistent Trigger → Conditions → Actions structure, regardless of the object being automated. The first step in creating an automation is choosing the object type (Device, Incident, Ticket, User, and future types), which then scopes the available triggers, fields, and actions.
∙ Cross-object actions. Within a single automation, actions can operate on related objects — e.g., a ticket-triggered automation can update the linked device’s status, notify the assigned user, and log an entry on the associated incident.
∙ Migration path, not a rip-and-replace. Existing Smart Rules and Workflows are automatically migrated into the new hub as-is, preserving their behavior and history. The old entry points can either redirect into the unified hub or be retired after a deprecation window, whichever is less disruptive.
∙ Organizational features that scale:
∙ Folders, tags, or categories to group automations (by department, use case, object type, etc.).
∙ Search and filter across all automations.
∙ Enable/disable toggles per automation without deleting.
∙ Ownership metadata (created by, last modified by, last run).
∙ Run history and logs per automation, including successes, failures, and skipped conditions.
∙ Duplicate/clone and export/import for reuse across environments or tenants.
∙ Optional test/preview mode to dry-run an automation against sample records before enabling.
∙ Role-based access so certain teams can manage automations for their object types (e.g., help desk leads manage ticket automations; asset managers manage device automations) without needing full admin rights.
∙ Templates / starter library of common automations (auto-close stale tickets, notify on incident creation, flag out-of-warranty devices, etc.) to accelerate adoption.
Who Benefits
∙ System administrators — one place to build, find, audit, and maintain every automation.
∙ Help desk and support leads — ticket workflows sit alongside related device and incident automations, making end-to-end processes easier to design.
∙ Asset and IT managers — device and incident automations can now trigger ticket and user actions natively, without workarounds.
∙ New admins and trainers — one mental model and one UI to learn, with consistent terminology throughout.
∙ Leadership and auditors — a single source of truth for “what is this system doing automatically, and why?”
∙ The product itself — a scalable home for automation as new object types (warehouse locations, insurance claims, lifecycle events, etc.) are introduced, without further fragmenting the UI.
References / Comparable Implementations
∙ ServiceNow Flow Designer — one unified builder spanning incidents, requests, assets, users, and custom tables.
∙ Jira Automation — a single automation surface covering issues, projects, and related objects with a consistent trigger/condition/action model.
∙ HubSpot Workflows — a central hub handling contacts, companies, deals, and tickets from one place.
∙ Salesforce Flow — consolidation of previously separate automation tools (Workflow Rules, Process Builder) into a single builder, a direct precedent for exactly this kind of unification.
∙ Zendesk Triggers and Automations — a shared automation surface across the support object model.