Core Concepts
A short tour of the five ideas that everything else in Aevon builds on. If you read one page before diving in, read this one.
Worklog
A worklog is a single time entry. It always has:
- an issue (the Jira issue the time was spent on)
- a date and start time
- a duration
…and optionally a description, an account, a billable flag, and any custom attributes your admin has defined. Worklogs are the atomic unit of everything in Aevon — the calendar, reports, approvals, and billing all operate on them.
Aevon worklogs are stored as native Jira worklogs, so they're visible on the issue's Work log tab and queryable with JQL.
Period
A period is a single Monday–Sunday week. It's the unit you submit for approval. A period moves through a lifecycle:
Draft ──► Submitted ──► Approved
▲ │
└───────────┘
Recall / Reject
- Draft — you're still logging and editing
- Submitted — sent for approval; the week is locked from your edits (recall to make changes)
- Approved — every approval request for the week has been approved
- A reject or a recall sends the week back to Draft
Account
An account is a cost centre or billable bucket — for example a client engagement, an internal initiative, or a capitalized project. Each account has:
- a category (its finance classification — see below)
- a default approver (who reviews time logged to it)
- a status (Open or Archived)
Logging a worklog to an account is what makes it routable for approval and billing. Accounts are optional — you can run Aevon as a pure time tracker — but they unlock the approval and billing-review workflows. See Accounts.
Category
A category is the finance classification applied to an account. Aevon seeds four:
| Category | Typical use |
|---|---|
| Billable | Client-billable work |
| Capitalized | Work that's capitalized rather than expensed |
| Operational | Day-to-day operational work |
| Internal | Internal, non-billable work |
You can add your own to mirror your finance taxonomy. See Categories.
Routing
Routing decides which account a worklog belongs to. Aevon resolves it with a clear waterfall:
1. Account custom field on the issue (highest priority)
2. The project's default account
3. No account
So a per-issue Account custom field value always wins; otherwise the per-project default applies; otherwise the worklog has no account. This lets admins set sensible project-wide defaults while still allowing exceptions on individual issues.
Approval flow
When you submit a week, Aevon splits it into approval requests grouped by account (or by project, for worklogs with no account). Each request routes to its own approver:
Your week Approval requests
┌─────────────────────┐
│ 12h → Account A │ ─────► Request 1 → Approver A
│ 8h → Account B │ ─────► Request 2 → Approver B
│ 5h → Project (none) │ ─────► Request 3 → Project lead
└─────────────────────┘
The week is Approved only when every request is approved.
- Worklogs against an account go to that account's default approver
- Worklogs against a project with no account fall back to the last approver used for that project, then the project lead
- You can override any group's approver before submitting
- The week as a whole is Approved only when every request is approved
- Rejecting any request requires a comment and sends the week back to Draft
This per-account fan-out is what lets one person's week reach several finance leads at once, each seeing only the hours they own. See Submitting timesheets and Approval statuses.
Putting it together
Log worklogs ──► Submit the week ──► Per-account approval ──► Billing review
(calendar) (split by account) (each approver) (reviewer pivot)
That's the whole loop: log time on the calendar, submit the week, let each approver decide, and roll the approved hours up in the billing review.