Automations and Elise at a glance
The Library list for every rule that runs on its own, plus Elise's chat, run history, and review queues, in one screenshot.
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, and the System group of rows here runs out of the box with no configuration from you.
Hide system automations
Every automatic rule shows here by default, the portal's own built-in rules and your team's side by side, each one 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. Organize and Execution, next to it, are two views of that same list: Organize groups rules into folders, Execution shows the order email intake actually runs them in.
New Automation
New Automation opens the same 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. An automation always runs the same steps for the same trigger. Use an automation when the rule never changes, and use Elise instead when the right move depends on the case.
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.
Chat
Chat is Elise's home. Ask a question and it gathers the client, ticket, or billing context it needs before answering, or ask it to act and it proposes the action as a card you approve first. It already knows the client or ticket you're on if you opened Chat from that page; otherwise, name it, paste a ticket number, or search. A new chat also offers a few common starting points as buttons you can tap instead of typing, and New Chat asks first before it puts the conversation you were on away - the one you leave stays in Recent chats, one click from the list icon.
Action History
Action History logs every action Elise has taken or proposed, 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.
Agent Runs
Agent Runs lists every multi-step loop Elise has run on its own: the prompt or trigger that started it, each step's plan and result, total tokens, and how it ended. Open a run and scroll its timeline to see exactly 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 are capabilities Elise wants to run, held for a one-tap approve or reject. Drafts are artifacts like replies or reports you copy, edit, and send by hand. KB Review and Procedure Review hold drafts written from a resolved ticket, a knowledge-base article for a one-off fix or a numbered procedure for a repeatable one, never both from the same ticket. Gated Actions are destructive or compliance-sensitive moves that need an explicit confirm and a typed reason before they run.
Why it works this way
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 requires a typed reason that is stored on the audit trail and shapes what Elise proposes next time.
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
Settings and RMM policies
Turn on a setting like ticket auto-close, or tick a box on an RMM patching policy.
Ask Elise
Ask Elise in Chat to build an automation or a workflow for you in plain language.
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, Devices and Security. 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 moves the rail to the match. Each Area has two views. Organize groups rules into folders. Execution shows the intake order first, then the event rules by trigger. A row gives you its type, trigger, source and status, plus a switch to turn it on. The menu at the end of a row holds only what that row lets you do. On a rule you wrote, that is Edit, a move into a folder, and Delete. A row with the Engine source adds View activity and Duplicate. If your account can only look, the menu holds View activity and nothing more. A row owned by a connected app cannot be deleted here. Disconnect the app instead. Click a row to open it. Use New Automation to write one.
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?
Capabilities Elise wants to execute on your behalf - close this ticket, reply to this email, charge this invoice - held until you approve. Each proposal shows the capability, parameters, source (chat / agent loop / scheduled), and a one-tap Approve / Reject.
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-and-Accept, or Reject each draft before it joins the searchable KB.
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 compliance-sensitive (waive a charge, change a billing rate) actions that Elise won't execute without a human explicitly confirming + supplying a reason. The reason is required and stored on the audit row.
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 Approve or Reject 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?
Every Elise-driven action, proposed, confirmed, executed, or rolled back, is recorded with the action taken, the entity it touched, the tech who ran it, and its status. Filter by status or by entity type. Executed actions that captured a before-snapshot show a Rollback button, and an errored action expands its row to show the details.
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 and records the reversal. Read-only actions capture nothing, so there is nothing to undo. Destructive actions are confirmed up front, which is what keeps most rollbacks from being needed.
What goes into Elise Review?
Five queues sit under Review. Proposals are capabilities Elise wants to run. You approve or reject each one. Drafts are artifacts you apply yourself, like emails or talking points. KB Review holds KB drafts made from resolved tickets. Procedure Review holds step-by-step procedures drafted from resolved tickets. Gated Actions are destructive or compliance-sensitive actions. They wait on your explicit confirm.
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 workflow-template runs, a reusable procedure applied to a ticket: the template, the client, who started it, status (In Progress, Completed, Cancelled, or Failed), and how many steps are done. Use it to pick up a multi-step procedure a teammate started. Event-driven automation runs are separate; find those under Automations > History, which shows each run's trigger, per-node results, and terminal state (Running, Waiting, Completed, Failed, Timed Out, or Cancelled).
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?