Most of an IT team's queue isn't hard. "Can I get into the finance folder?" "Is this email real?" "Dana's last day is Friday." Each one takes the same few moves: look something up, check with the right person, make the change, write it down, and tell whoever asked. The decision takes a minute. The moves take the afternoon.
Here's how to hand those moves to Lodol for four kinds of request: phishing reports, access requests, offboarding and alerts. Lodol doesn't replace your service desk, your identity provider or your security tools. It runs the work between them: it reads the report, does the lookups, opens the ticket in Jira, ServiceNow or Freshservice, and, once a person confirms, changes access in Okta or Microsoft Entra ID. The paperwork closes itself. The decisions don't.
1. Phishing reports: a first pass in minutes, never a verdict
The chore: someone posts "is this legit?" in the security channel, and a person drops what they're doing to look.
The workflow: Triage reported phishing in Slack starts whenever someone posts in the channel you choose. AI reads the report for the usual signs: a sender that doesn't match, a lookalike domain, urgent or threatening language, a request for a password or a payment, links that don't go where they claim, an unexpected attachment. A reply lands in their thread with a risk level, what was seen and what to do next, and the report goes into a spreadsheet with the time, the reporter, the original text and the verdict.
What it won't do: call anything definitely safe. The AI is told never to, and every reply says it's an automated assessment and that anything in doubt should be treated as suspicious and escalated. Because every report is logged, a wrong call can be found afterwards.
If your people forward suspicious mail to a mailbox instead, Turn reported suspicious mail into Jira tickets opens one ticket per sender in the project your responders already work from, with later reports added as comments. Every line is copied from the message and nothing is scored, and a message is marked as triaged only once its ticket is written, so a failed run repeats a report rather than losing it.
2. Access requests: the owner says yes, then it's done
The chore: a request in a DM, a message to the person who owns the system, a wait, a change in the admin console, and a ticket written up after the fact, if at all.
There's no ready-made template for this one, because every company's groups are different, but it's a short workflow:
- The request comes in. Slack's New command in channel trigger starts a run when a message in your IT channel begins with a word you choose, such as "access". A form in a Lodol app works too.
- The owner decides. A Request approval step asks the person who owns that access, by email and in Lodol, and can post the request in a Slack channel too: "Add Priya Shah to the Finance Shared group in Okta?" Put the requester's email address in Prepared by, and they can't approve their own request; Slack's Get member step looks it up from the message's sender. Reminders and escalation chase a slow answer.
- The change is made. If it's approved, Okta's Add user to group, or Add a group member in Microsoft Entra ID, grants it.
- It's written down. The approval hands the decision, any comment, who decided and when to the steps after it, so the ticket in Jira Service Management, ServiceNow or Freshservice can record all of it. A reply in the thread tells the person it's done.
What it won't do: change anything on a no, or on silence. If nobody answers before the time limit, an approval is rejected unless you've chosen otherwise. The approvals guide covers every setting.
You don't have to build it step by step. Describe it to Claude or ChatGPT connected to Lodol, and it builds the workflow in your workspace. Or, since yesterday, mention @Lodol in Slack: anything that sends or changes data becomes a workflow, shown as a card with its steps, and nothing starts until you press Run.
3. Offboarding: one list, and a person presses go
The chore: remembering every place a leaver has access, on the day, without missing one.
The workflow: start it by hand with the leaver's email address. It lists their Okta groups, then asks for approval with the whole list in the request: "Suspend Dana Kim's account, sign her out everywhere and remove her from these nine groups?" Once someone approves, it does exactly that. On Microsoft, Entra ID can block her sign-in and sign her out everywhere instead, and password managers are covered too: LastPass can disable a user, and Bitwarden can revoke a member. The run ends by closing the ticket with what was changed.
What it won't do: anything you can't take back, unless you build it to. Okta's Suspend user keeps every group and app assignment, so Unsuspend user reverses it, while Deactivate user removes access to every assigned app. A user deleted in Entra ID can be restored, with their groups, for 30 days. Start with the reversible steps and deactivate after the handover. On Pro and Enterprise, admins can choose which apps and actions workflows may use, so Delete user can be ruled out for the whole workspace. Our guide to onboarding and offboarding covers the HR side.
4. Alerts: the lookups done before anyone opens the ticket
A new PagerDuty incident can start a workflow, and so can anything that can call a web address, through the Webhook received trigger, which can require that callers sign their requests. Say an alert reports a suspicious sign-in for dana.kim. The workflow looks her up in Okta, asks the on-call lead to approve suspending the account, suspends it and revokes her sessions, then opens a Jira ticket with the alert, the approval and the time.
Some alerts are worth having before anything breaks. Watch your websites for downtime checks the sites in your sheet every 15 minutes and tells you once when one goes down and once when it's back, never in between. Warn before SSL certificates expire sends one email for everything inside your warning window, and nothing when every certificate is fine.
On the record
Every run is traced step by step, so when someone asks when an account was suspended, who approved it and why, the answer is there. On paid plans, every change to a workflow is a version you can restore. Pro adds single sign-on, SCIM, custom roles, access controls down to the folder, and an audit log that records every approval decision and can be streamed to your own tools; our post on single sign-on and SCIM has more.
What it costs
Lodol charges per run, however many steps a run takes, and every plan has unlimited seats, so every approver can be a member at no extra cost. A run that waits two days for an approval still counts once. For a company whose staff report a few suspicious messages a day:
| Workflow | When it runs | Runs a month |
|---|---|---|
| Phishing triage in Slack | Once per message in the reports channel | 100 |
| Reported mail to Jira | Once per email to the reports mailbox | 100 |
| Access requests | Once per request | 60 |
| Offboarding | Once per leaver | 5 |
| Uptime watch | Every 15 minutes | 2,880 |
| Certificate expiry | Once a day | 30 |
| All six | About 3,175 |
That fits Builder's 5,000-run tier at $30 a month ($25 if you pay annually). If you need single sign-on, SCIM and the audit log, Pro starts at $120 a month for 10,000 runs. Give the mail workflow a mailbox of its own, since it wakes for every email that arrives there. The AI steps, such as the phishing triage's first pass, run on your own AI account, such as Anthropic or OpenAI, which bills you at its own rates; Lodol adds nothing.
Start with the phishing reports.
Point Triage reported phishing in Slack at your security channel and see the next report answered in its thread. Browse all of the IT and security workflows, or see how Lodol fits an IT stack on the IT and security page.