> For the complete documentation index, see [llms.txt](https://docs.cogram.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cogram.com/guides/workflows.md).

# Workflows

A workflow writes a report on a schedule. You tell Cogram which projects to read, which data to use, and what to write; Cogram runs it on your schedule and emails you the result.

Typical uses:

* A Monday morning owner update covering last week's meetings and correspondence
* A daily brief for the project team on an active site
* A month-end summary for each project you run

Workflows are in **Agent → Workflows**. The reports they produce are under **Agent → Workflow runs**.

## Creating a workflow

1. Go to **Agent → Workflows** and select **New Workflow**.
2. Give the workflow a name.
3. Work through the steps on the canvas. Select any step to configure it: **Trigger**, **Data sources**, **Prompt**, **Report output**, and **Notifications**.
4. Select **Save**.

A new workflow is saved as **Draft**. It does not run until you activate it.

### Trigger

Choose how often the report runs. Set a **Frequency** (Daily, Weekly, Every 2 weeks, or Monthly), a **Day of week** where the frequency needs one, and a **Time**.

### Data sources

This step decides which projects the report covers and what it reads.

Under **Input projects**, choose one of:

* **Specific projects**: pick the projects yourself
* **Projects I'm an owner of**
* **Projects I'm a member of**
* **Projects I'm an owner or member of**

The three role-based options are re-checked on every run, so a project you join later is picked up without editing the workflow. See [Choosing input projects](#choosing-input-projects) below.

Under **Include data from**, select any combination of **Meeting minutes**, **Emails**, and **Field reports**.

Under **Time range**, choose how far back each run reads: Last 24 hours, 3 days, 7 days, 14 days, or 30 days. Match this to your frequency. A weekly report that only reads the last 24 hours will miss most of the week.

When a workflow covers more than one project, choose a **Report mode**:

* **Separate reports**: one report per project, sent as separate emails
* **Combined report**: one report covering all projects

### Prompt

Write the instructions for the report: what to cover, how to structure it, and who it is for. Be specific about what matters to the reader.

For an owner update, for example, you might ask for progress since the last report, decisions taken, outstanding RFIs, and items awaiting the owner's response.

### Report output

Set the **Report title**. Titles support a date, so a recurring report is easy to tell apart in a list.

**Include source references** links report sections back to the documents they came from. Leave this on when someone will need to check a statement against the original minutes or email.

### Notifications

Turn on **Email notification** to get an email when the report is ready. The email includes a link to the full report in Cogram.

## Activating a workflow

A workflow only runs on its schedule once it is **Active**.

Open the workflow and select **Activate**. To stop it without deleting it, select **Pause**. A paused workflow keeps its configuration and stops running.

To test a workflow before you rely on it, select **Run now**. This runs it immediately against the current data, which is the fastest way to check that your prompt produces what you want.

## Choosing input projects

**Specific projects** is the right choice when the workflow covers a fixed set of projects that does not change.

The role-based options suit people who run many projects and do not want to revisit the workflow every time their portfolio changes. Cogram resolves them fresh on each run, using your project roles at that moment.

Two rules apply to the role-based options:

* **A workflow covers at most 20 projects.** If more than 20 match, Cogram uses the 20 most recently active and tells you in the builder how many were left out.
* **Dormant projects are left out.** A project with no meetings, emails, or field reports in the last 90 days is skipped. A project you created recently counts as active even before anything is filed to it.

The builder shows which projects match right now, so you can check the list before saving. That preview is a snapshot: the projects are worked out again on every run, so the set can change.

Role-based selection follows the roles of the person who created the workflow, not whoever is looking at it. If you open a colleague's workflow, the projects shown are the ones their roles resolve to.

## Owner project

Every workflow belongs to a project, shown as its **Owner project**. This controls who can see and change it:

* Members of the owner project can see the workflow and its runs
* Owners of that project can edit it
* Only the person who created the workflow can move it to another project

Leave the owner project as your **Personal workspace** to keep a workflow to yourself. Set it to a shared project when the team should see it.

The owner project is separate from the input projects. A workflow can sit in one project and report on others.

## Reading the results

Go to **Agent → Workflow runs** to see every run, its status, and the report it produced.

A run is **Completed** when the report is ready. **Failed** means the run did not finish; open it to see the error.

Reports are drafts written by AI. Before sending one to an owner, a client, or a contractor, check it against the source material: names, dates, decisions, action items, numbers, and anything contractual. Keep **Include source references** on to make that check quick.

## Troubleshooting

**The report is empty or thin**

*Likely cause:* The time range is shorter than the gap between runs, or the selected data sources hold nothing for the period.

*Fix:* Widen the **Time range** to at least cover the interval between runs, and confirm that the projects have meetings, emails, or field reports filed for that period.

**A project is missing from a role-based selection**

*Likely cause:* The project has had no activity for 90 days, you do not hold the required role on it, or more than 20 projects matched and this one fell outside the 20 most recently active.

*Fix:* Check your role on the project under [Projects](/guides/projects.md). If more than 20 projects match, switch to **Specific projects** and pick the ones that matter, or narrow the role you select on.

**"Nothing to run" when using Run now**

*Likely cause:* No project currently matches the role-based selection, so there is nothing to report on.

*Fix:* Confirm you hold the selected role on at least one project with recent activity. Nothing is wrong with the workflow; it will run as soon as a project matches.

**The workflow never runs on its own**

*Likely cause:* It is still in **Draft** or has been **Paused**.

*Fix:* Open the workflow and select **Activate**.

**The report does not cover what you asked for**

*Likely cause:* The prompt is too general, or the data source the content lives in is not selected.

*Fix:* Make the prompt specific about sections and audience, and confirm **Include data from** covers the right material. Use **Run now** to test each change.

## Next steps

* [Agent](/guides/agent.md): ask questions across your projects on demand
* [Projects](/guides/projects.md): project roles and membership
* [Notifications](/guides/notifications.md): control the emails Cogram sends you


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cogram.com/guides/workflows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
