What Automations and Elise do for you
One list of every rule that acts on its own across your portal, plus Elise's chat, history and review queues so nothing she does goes unseen.
Library
The Library is the one list for every rule that acts on its own, whatever runs it: engine pipeline steps, SLA evaluations, event-driven automations, and read-only rows synced from a Setting or an RMM patching policy. Use it whenever you need to see, open, or turn off something the portal or your team does automatically. Each row shows its Area, Type, Trigger, Source, and Status. A System group of built-in rows is part of the list. A rail on the left lists the Areas, such as Tickets, Clients, Billing, Devices, Security and Alerts, and you look at one Area at a time. It opens on the Area you used last, and on Tickets the first time. Search looks in every Area, and opening a match moves the rail to it. Under Alerts sit the 14 daily alert checks as locked rows: you can read them and switch one on or off, but not edit or add them. The switch is the same as the one in System, then Alerts & Notifications, so a check turned off in either place is off in both. Click a rule's name to open it: an Automation opens in the canvas, and an Engine rule opens a read-only page. The menu at the end of a row holds only what that row allows; a locked system row holds View activity only.
Hide system automations
Every automatic rule shows by default, the portal's own built-in rules and your team's side by side, each tagged so you can tell who owns it: Locked or System for a built-in rule, Setting or RMM policy for one generated by a page elsewhere, an app's name for one owned by a connected integration. Turn this on to see only the rules your team wrote; the portal remembers your choice. Organize and Execution, next to it, are two views of the same list: Organize groups rules into folders, Execution shows the order email intake runs them in, then the event rules by trigger.
New Automation
New Automation opens the trigger-and-steps editor used for every automation your team writes: choose a trigger, such as a new ticket, then add the steps to run when it matches. Use an automation when the rule never changes, and use Elise instead when the right move depends on the case.
What a rule can do
A rule's steps are not limited to tagging tickets. The actions the editor and the Library name include, for example: Assign the ticket, Set the priority, Escalate a ticket at risk of missing its SLA, Close the ticket, Notify the team, Send an email, Open a ticket for the device alert, Run a repair on the device, Change the service plan, Set the client status, Create the recurring ticket, Call a webhook and Run a workflow. So one rule can open a ticket for a device alert, a second can escalate a ticket that is heading for an SLA miss, and a third can move a client's service plan, each without anyone touching it.
Browse
On this page
Elise and Workflows in the side bar
Workflows
Workflows opens a separate area for reusable, ordered ticket templates: onboarding, offboarding, a compliance audit, any process with a known sequence of steps. Build a template once on its Library page and apply it to any client; each step becomes its own trackable ticket. Workflows > History shows every workflow run's progress, and Automations > History shows the same for automations. A workflow is a human-driven checklist, while an automation is event-driven and fires on its own, though one can trigger the other (a rule can use the Run a workflow action).
Chat
Chat is Elise's home. Ask a question and she gathers the client, ticket or billing context she needs before answering, or ask her to act and she proposes the action as a card you confirm first. Her range runs from lookups to drafts: "give me a rundown for this client" pulls their tickets, invoices, quotes and hours in one answer; "which clients used the most time this quarter" ranks them; "draft a reply to this ticket in my voice" writes the reply for you to send; "list our service plans" reads the plan catalogue. She already knows the client or ticket you are on if you opened Chat from that page; otherwise name it or paste a ticket number. A new chat offers a few starting points as buttons, and New Chat asks first before it puts the conversation you were on away: the one you leave stays in Recent chats.
Action History
Action History logs the actions Elise has taken or proposed, whether approved, executed or rolled back, with the entity it touched and the tech who handled it. An executed action that captured a before-snapshot shows a Rollback button that restores what changed. A read-only action leaves nothing to undo, because it never changed anything. A row marked Ran without release is an action that Elise's own chat would send to a second person to release, but it ran through a connected AI app on the person's own rights and no one released it.
Agent Runs
Agent Runs lists the multi-step loops Elise has run on her own: the prompt or trigger that started each one, each step's plan and result, total tokens, and how it ended. Open a run and scroll its timeline to see where a stuck or wrong run went off track.
On Demand Runs
On Demand Runs are agent runs you trigger yourself right now, rather than one that fires from a chat message or a schedule. Use it to point a known capability at a specific client or device without going through Chat first.
Review
Review holds five queues for anything Elise wants a human to look at before it counts as done. Proposals: actions she proposed as a card in chat that still wait for an answer; you confirm or cancel each on its card in chat, and here you mark a row Acted once handled, or Dismiss if it was not wanted. Drafts: replies or reports you copy, edit and send by hand. KB Review and Procedure Review: drafts written from a resolved ticket, an article for a one-off fix or a numbered procedure for a repeatable one, never both from the same ticket. Gated Actions: destructive or money moves, such as deleting an invoice or sending an agreement as a quote, that she files instead of running. A second person who holds that action's own permission releases one with a click, or declines it with a reason picked from a short list. An unreleased row expires on its own: after 4 hours for a money action, and after 24 hours by default for the rest (an admin setting).
Dashboard
Elise > Dashboard shows her usage this month: API Calls, Tokens Used, Cost This Month and Avg Cost / Call, plus Usage by Feature and Usage by Client, so you can see what the AI is doing and what it costs.
Actions
Elise > Actions lists everything she can do, grouped by area (Ticket, Billing, Time, Documentation, Infrastructure, Client, Workflow, Reports and more), with a search box. There are more than 200 actions, and each shows the permission it requires and a badge: Read, Draft, Safe Write, Sensitive Write or Destructive. Read it before you ask, to see the range.
Why it works this way: What Automations and Elise do for you
A row tagged Setting or RMM policy is read-only in the Library on purpose: it is a synthesized copy of a dropdown on another page, so there is exactly one place the real decision lives.
Nothing above a read-only action runs unattended without a record of why: Elise snapshots the prior state before a safe write so it can be rolled back, and a gated action in Elise's own chat sits filed until someone other than the requester, holding that action's own permission, releases it with one click or declines it with a coded reason. Both land on the audit trail.
A resolved ticket can only ever produce one Elise draft, a KB article or a procedure, never both, so Review never asks about the same ticket twice.
Other ways to do this: What Automations and Elise do for you
Settings and RMM policies
Turn on a setting like ticket auto-close, or tick a box on an RMM patching policy.
Ask Elise
Describe the rule in Chat, for example "when a critical device alert fires, open a ticket and notify the on-call tech". She either drafts it switched off for you to review, or opens the rule editor with your request filled in. Needs the permission to approve automations.
Ticket Rules
Open Service Desk > Ticket Rules, the same email-intake pipeline scoped to one board.
Questions this page answers
What is on the Library page?
The left rail lists Areas, such as Tickets, Clients, Billing and Devices. You look at one Area at a time. It opens on the Area you used last, or on Tickets the first time. Search looks in every Area, and opening a match moves the rail to it. Organize groups rules into folders, and Execution shows the email intake rules first, then the other rules by trigger. Click a rule's name to open it: an Automation opens in the canvas, and an Engine rule opens a read-only page.
What does the "Hide system automations" switch do?
Nothing is hidden unless you turn it on. By default you see every rule that acts on its own, ours and yours alike. Each one is tagged so you know who owns it. A safeguard tags Locked or System. A rule from a connected app tags with that app name, like ThreatLocker. A rule made by a setting tags Setting. One made by a patching policy tags RMM policy. Locked and System only tell you the rule is built in. The other tags name what owns the rule, and you can click them. A Setting or RMM policy tag opens the page that controls the rule. An app name opens Integrations. Turn this on to see only your own rules. In the intake list, hidden rows fold into one line that says how many run before yours, so the numbers never lie about order.
What does an automation do?
An automation watches for one thing, then acts. You pick the trigger, such as a new ticket. You add the steps to run. It runs every time the trigger matches. A step can send an email, post a note, open or change a ticket, run a workflow, or call a webhook.
What are workflows?
Workflows are reusable step-by-step templates for recurring processes (onboarding, offboarding, compliance audits, etc.). Create a template with ordered steps, publish it, then apply it to any client. Each step becomes a trackable ticket.
What are Proposals?
Proposed actions that still wait for an answer. Elise shows a proposed action as a card in the chat. If the tech leaves before answering, the card is listed here. Each row shows the action, who asked, the ticket, and the time. You confirm a proposed action on its card in the chat. This page does not run anything. Each row has two buttons. Acted records that the matter was handled. Dismiss records that it was not wanted.
What are Drafts?
Artifacts Elise prepared for human application - drafted email replies, meeting talking points, KB drafts that need editorial review, reports. Unlike Proposals, drafts don't auto-execute on accept - you copy, edit, and send manually. Marking as Acted records you used it; Dismissed teaches Elise to stop drafting that shape.
What is KB Review?
Resolved tickets generate KB draft entries - Elise pulls the question, the resolution steps, and the affected systems into a draft KB article. KB Review is where you Accept, Edit & accept, or Reject each draft before it joins the searchable KB. The same drafts also show in each client's Knowledge Base list with a Draft / proposed badge, so you can review them where the articles live. KB Review is the queue across all clients.
What is Procedure Review?
When a closed ticket reads as a repeatable, ordered sequence - an onboarding, an offboarding, a migration, a recurring fix with real setup steps - it gets drafted as a procedure: a title, a "when to run this" blurb, and numbered steps. Procedure Review is where you Approve, Edit and approve, or Reject each draft. Approving publishes a real procedure, immediately searchable and attachable to tickets.
What are Gated Actions?
Destructive (delete records) or money (delete an invoice, send an agreement as a quote) actions Elise files here instead of running. Release needs the SAME permission the action itself needs, from someone other than whoever asked for it, and runs it with one click - no typed reason. Decline picks a reason from a short list instead. An unreleased row expires on its own: 4 hours for money actions, 24 hours for the rest, or the window your admin set.
What can I do in Elise Chat?
Ask a question and Elise gathers the context it needs (clients, tickets, billing, docs) before answering. Ask it to do something and it proposes that action right there - a card you Confirm or Cancel before anything runs. Any message can carry both: ask what is open for a client and to close the duplicate, and you get the answer plus the card. Elise only proposes actions your own role has permission to run, and when it cannot run something it says so instead of going quiet. A new chat also offers a few common starting points as buttons - tap one to send it instead of typing. New Chat asks before it puts a conversation away. The one you leave stays in Recent chats, so you can open it again from the list icon.
What's in Action History?
Action History lists every action Elise proposed or ran, with its status. Each row shows the action, what it touched, and the tech who ran it. You can filter by status or by entity type. An executed action with a saved snapshot has a Rollback button, and an errored action expands its row to show the details. A row marked Ran without release is an action that Elise's own chat would send to a second person to release, but no one released it. Point at the badge to read that it ran through an AI app on the person's own rights.
What are Agent Runs?
Agent Runs lists every multi-step agent loop Elise has executed - the prompt that started it, each step's plan + result, total tokens, total wall time, and final outcome. Each run is bound to one initiating chat message or scheduled trigger.
What are On-Demand Runs?
Manually-triggered agent runs (vs. scheduled by a cron). Use this when you want to fire a known capability against a specific entity right now - e.g. "regenerate the meeting agenda for X client" - without going through chat.
Can I roll back an Elise action?
Before Elise runs a write, it captures a snapshot of the prior state. Any executed action with a snapshot shows a Rollback button that restores what changed. Read-only actions capture nothing, so there is nothing to undo. In Elise's chat, a destructive action waits for a second person to release it. Run through a connected AI app, the same action runs on the tech's own rights with no release, and its row shows Ran without release.
How is this different from Elise?
An automation is fixed. The same trigger always runs the same steps. Elise reads the case and picks what to do. Use an automation when the rule never changes, like closing a quiet ticket after 30 days. Use Elise when the right move depends on the case.
What's the difference between a workflow and an automation?
Workflows are repeatable ticket/project templates - the human-driven equivalent of a checklist. Automations are event-driven: something happens, an effect fires. Workflows can be triggered by automations (workflow.run effect), but they're distinct. Apply a workflow template to a ticket to create the project structure, sub-tickets, and handoff steps.
How do I create a workflow template?
Go to Workflows > Library and click "New Workflow". Give it a name and description, and choose a cascading mode that controls whether the tickets all open at once or unlock one after another as earlier ones close. Then add the steps, each step becomes a ticket with a subject and optional instructions, and you can drag to reorder or nest them as sub-tickets. Click "Create Workflow" to save; the template is ready to use right away (there is no separate publish step). To put it to work, open the template and click "Apply Template" to create its tickets on a client.
How do I apply a workflow to a client?
Open a published workflow and click "Apply Template". Select the client and optionally a project board. With a project board, a parent project ticket is created with sub-tickets for each step. Without a board, flat individual tickets are created. Each ticket is linked to its workflow step.
Where do I see workflow and automation run history?
This page, Workflows > History, lists the workflow templates that have been applied. Each row shows the template, the client, who started it, how many steps are done, the status and the start time. The status reads In Progress, Completed, Cancelled or Failed, and the filter offers the first three. Use the list to pick up a multi-step procedure a teammate started. Finished runs older than 90 days are removed. Event-driven automation runs are separate, under Automations > History.
Where do the "Policy ...: ticket on failed OS patches" rows come from?
From your patching policies. Each of the two dropdowns on a policy, set to On, makes two real rules here, named after that policy. One opens the ticket the first time a device hits the problem. The other opens it when the same device hits it again later and no ticket is open for it. So every ticket the portal opens on its own is in one list. The rows show by default, tagged RMM policy. You cannot edit them here, and that is on purpose: there is one place the decision lives. Open the row and follow the link to that policy. Then change the dropdown. Setting it to Off removes both rows from this list. Each row keeps a log, so you can see every run and why it chose to do nothing.
Was this helpful?