Automations
Eliminate busy work by defining rules that run in the background. Every automation is a trigger, optional conditions, and one or more actions.
Build automations visually — trigger, conditions, action — and Lithora keeps a readable definition in sync.
Plan requirement
How it works
- Trigger. The event that starts the run — something happening in Lithora, in GitHub, or a scheduled time.
- Conditions. Optional filters on the event. Operators include equals, not equals, contains, greater / less than, is empty, is not empty, in list, not in list, and matches regex.
- Actions. One or more things to do. You can also branch: define if / then groups and the first matching branch runs, with an optional default.
Triggers
Work
- • Task created
- • Task updated
- • Task assigned
- • Task status changed
- • Task completed
- • Deadline approaching
- • Project created
- • Project updated
GitHub & CI/CD
- • Issue opened, closed, or reopened
- • PR opened, merged, or closed without merging
- • Commits pushed
- • Release published
- • CI check suite failed
- • Deployment started or completed
Collaboration & files
- • Comment added
- • User mentioned
- • File uploaded or deleted
- • Entities linked or unlinked
- • Team member added or removed
Time & schedule
- • Timer started or stopped
- • Manual time entry created
- • Scheduled run on a cron expression
A scheduled automation needs a valid cron expression
Actions
- Update task: Modify fields on the task that triggered the run.
- Change status: Move the task to To Do, In Progress, In Review, or Done.
- Change priority: Set Low, Medium, High, or Urgent.
- Assign user: Route the task to a specific team member.
- Add / remove tag: Keep labels accurate without anyone remembering to do it.
- Create task: Open follow-up work automatically.
- Post comment: Leave a note on the task explaining what happened.
- Add relation: Link the task to another entity in the work graph.
- Create notification: Send an in-app notification to a user.
- Send email: Send an email notification.
- Call a webhook: POST to an external URL. Destinations are validated to block internal-network targets.
- Run an integration action: Invoke a connected provider — post a Slack message, create a GitHub issue, redeploy on Vercel.
Agent actions
An automation can hand the job to the AI agent instead of doing it mechanically:
- • Decompose an issue into subtasks
- • Triage and label the backlog
- • Assign by expertise
- • Draft a PR description
These are the same capabilities the installable agents wrap — see Agents & presets. Runs that would write to GitHub stage a plan for approval rather than acting on their own.
Reading the run history
If an automation is not doing what you expect, open its Run History. Each run lands in one of these states:
- Success: The trigger fired, conditions passed, and every action completed.
- Skipped: The trigger fired but a condition did not match — this is normal, not a fault.
- Failed: An action errored — most often a permission problem, such as assigning to someone who is not in the team.
- Retrying: A transient failure is being retried before the run is marked failed.
- Awaiting approval: The run paused at an approval gate and is waiting for a person to confirm before continuing.
Nothing in the history? The trigger never fired. Check that the automation is Active, that its project or team scope matches where the event happened, and — for GitHub triggers — that the repository is connected and delivering webhooks.
Runs are deduplicated