# Automations and workflows (https://docs.akollo.com/en/modules/automations)



This module covers the rules that make work move the same way every time. **Workflows** decide which statuses a work item can have, which moves are allowed and what evidence a move needs. **Approvals** hold a change until the right people agree, and **notifications** tell people when something needs them. Workflows are under **Projects → Workflows**, decisions under **My work → Approvals**, and notifications behind the bell in the top bar.

<Callout title="Planned">
  Automation flows drawn as triggers, conditions and actions are planned and not yet part of the current release. Workflows, approvals and notifications described here are available today.
</Callout>

## Who uses it [#who-uses-it]

| Role                | What they do here                                                                                         |
| ------------------- | --------------------------------------------------------------------------------------------------------- |
| Employee            | Moves work items through the allowed statuses, requests a change that needs approval, reads notifications |
| Approver or manager | Decides on requests under **My work → Approvals**, approve, reject or send back                           |
| Workflow owner      | Edits statuses, transitions and required evidence in a draft, validates and publishes it                  |
| Second publisher    | Publishes changes to a regulated workflow that someone else drafted                                       |
| Administrator       | Keeps an eye on the audit log and the usage meters, including automation runs                             |

## Main screens [#main-screens]

| Screen                        | What it shows                                                                                                                                       |
| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Projects → Workflows**      | Every workflow with its published version, whether a draft is open and whether it is regulated; a **Statuses** tab with the organisation's statuses |
| Workflow editor               | The draft: statuses, transitions, conditions and required evidence, with **Validate** and **Publish**                                               |
| **Versions**                  | Every published version with its changes, its publisher and, where needed, its second approver                                                      |
| Status control on a work item | Only the moves the workflow allows; moves marked **Needs approval**                                                                                 |
| **My work → Approvals**       | Requests waiting for your decision, the one due soonest first                                                                                       |
| **Notifications**             | Everything sent to you in the organisation, newest first, with **All** and **Unread**                                                               |
| **Settings → Notifications**  | Your channels and the language of notification e-mails                                                                                              |

<Screenshot src="/screens/en/work-approvals.webp" alt="Approvals page with filters for project, type and waiting time and a list of requests showing work item, status change, step, due date, requester and a Decide button" caption="My work → Approvals: the requests waiting for your decision." />

A transition can require evidence before the move is allowed: required fields, done checklists, met acceptance criteria, a number of attachments, a comment, no open blockers, done child items, a linked item in a given category, or a minimum of tracked time. For the full list, see [Workflows](/en/product-guide/workflows).

## Key tasks [#key-tasks]

### Change a workflow [#change-a-workflow]

<Steps>
  <Step>
    ### Open the draft [#open-the-draft]

    Choose **Projects → Workflows** and open the workflow. Editing needs a larger screen.
  </Step>

  <Step>
    ### Make your changes [#make-your-changes]

    Add or remove statuses, set the initial status, add transitions with an optional condition, and attach required evidence. Save the draft. If someone else saved it in the meantime, you are asked to reload.
  </Step>

  <Step>
    ### Validate and publish [#validate-and-publish]

    Select **Validate**, then **Publish** and confirm the summary of the changes. On a regulated workflow, a second person publishes; the person who drafted the change cannot.
  </Step>
</Steps>

### Undo a published change [#undo-a-published-change]

<Steps>
  <Step>
    ### Open Versions [#open-versions]

    Open the workflow and go to **Versions**.
  </Step>

  <Step>
    ### Restore the earlier version [#restore-the-earlier-version]

    Choose **Restore as new draft** on the version you want back. It is published at once, or on a regulated workflow it becomes a draft for a second person to publish.
  </Step>
</Steps>

### Request a change that needs approval [#request-a-change-that-needs-approval]

<Steps>
  <Step>
    ### Pick the status [#pick-the-status]

    On the item page, open the status control and choose the status marked **Needs approval**.
  </Step>

  <Step>
    ### Wait for the decision [#wait-for-the-decision]

    The item shows "Waiting for approval". Other status changes are disabled meanwhile.
  </Step>

  <Step>
    ### Resubmit if it comes back [#resubmit-if-it-comes-back]

    If the item shows "Returned for correction", fix what is needed and select **Resubmit**. The approval starts again from the first step.
  </Step>
</Steps>

<Mermaid
  title="How a status change is approved"
  chart="`flowchart LR
A[Change marked Needs approval] --> B[Approval steps one after another]
B -->|Approve| C[Status changes]
B -->|Reject| D[Status stays]
B -->|Send back| E[Returned for correction]
E -->|Resubmit| B`"
/>

### Decide on a request [#decide-on-a-request]

<Steps>
  <Step>
    ### Open Approvals [#open-approvals]

    Choose **My work → Approvals**. Filter by project, type or waiting time if the list is long. An "Overdue" label marks requests past their due date.
  </Step>

  <Step>
    ### Decide [#decide]

    Select **Decide** on the row, then choose **Approve**, **Reject** or **Send back**. Rejecting and sending back need a comment. If someone else acted first, you are asked to refresh.
  </Step>
</Steps>

### Choose how notifications reach you [#choose-how-notifications-reach-you]

<Steps>
  <Step>
    ### Open the notification settings [#open-the-notification-settings]

    Go to **Settings → Notifications**. The settings apply to the active organisation and only to you.
  </Step>

  <Step>
    ### Turn channels on or off [#turn-channels-on-or-off]

    Use **In-app notifications** and **Email notifications**. Both are on until you turn them off.
  </Step>

  <Step>
    ### Pick the e-mail language [#pick-the-e-mail-language]

    Choose Turkish or English under **Notification language**. Until you pick one, the organisation's default language is used.
  </Step>
</Steps>

<Screenshot src="/screens/en/notifications.webp" alt="Notifications page with All and Unread tabs, a list of notifications with their time and an Unread badge, a Mark as read button on each and Mark all as read at the top" caption="Notifications: everything sent to you in this organisation, newest first." />

Akollo sends reminders on its own, for example a reminder to owners and contributors the day before an item is due and when it becomes overdue, access review reminders 7, 3 and 1 days before the due date, a reminder to a project lead when a project has had no status update for 14 days, and a notice to owners and admins at 80 % and 100 % of a usage budget.

## Permissions [#permissions]

* Anyone who can work on an item sees only the moves its workflow allows. Required evidence is checked for everyone.
* Editing and publishing workflows is for the people who manage them. On a regulated workflow, the person who drafted a change can never publish it.
* Approvers decide on the requests assigned to them. Nobody can decide on their own request when the policy separates duties.
* Notification settings are personal: each person chooses their own channels.
* A support session can read what it is allowed to see and cannot change, approve or publish anything.
* Every status change is kept on the item's **History** tab, and each item's transition history is checked daily for tampering. Findings go to the audit log for administrators.

## What the AI can do here [#what-the-ai-can-do-here]

* **Writing help** in comment and reply boxes can shorten, expand or change the tone of your text. See [AI assistant](/en/ai/assistant).
* On the planned automations page you will be able to describe a flow in your own words. You see a suggestion and what it would change; saving keeps a draft, and nothing starts until you publish it yourself. See [Models that stay in the institution](/en/ai/local-models).
* In planned automation flows, agents that draft tasks or notifications stay inside an allowlist, a step that changes something important waits for a person who sees a preview, and a manager approves an assignment before it is carried out.

AI never approves a request or publishes a workflow for you.

## FAQ [#faq]

<Accordions type="single">
  <Accordion title="Can I build automation flows today?">
    Not yet. Visual flows with triggers, conditions and actions are planned. Today, workflows, approvals and notifications cover rules for how work moves and who must agree.
  </Accordion>

  <Accordion title="Why can't I move an item to a status?">
    Either the workflow has no transition from the current status to that one, or the transition requires evidence that is missing, such as a comment, a done checklist or no open blockers. A status marked **Needs approval** sends a request instead of changing at once.
  </Accordion>

  <Accordion title="Can I publish my own change to a regulated workflow?">
    No. On a regulated workflow a second person must publish; the person who drafted the change cannot.
  </Accordion>

  <Accordion title="What happens after I resubmit a returned request?">
    The approval starts again from the first step.
  </Accordion>

  <Accordion title="Can I keep e-mail notifications but switch off in-app ones?">
    Yes. In **Settings → Notifications**, turn off **In-app notifications** and keep **Email notifications** on. The choice covers all notification types together.
  </Accordion>

  <Accordion title="Why can't I archive a status?">
    A status that is still in use cannot be archived. Once it is no longer in use you can archive it, and restore it later if needed.
  </Accordion>
</Accordions>

## Related [#related]

* [Workflows](/en/product-guide/workflows)
* [Tasks and projects](/en/product-guide/tasks-and-projects)
* [Automation](/en/product-guide/automation)
* [Getting started](/en/getting-started)
* [Webhooks](/en/connections/webhooks)
* [Projects and work](/en/modules/projects)
* [My work](/en/modules/my-work)