> ## Documentation Index
> Fetch the complete documentation index at: https://docs.costgraph.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# What workflows can change

> Every change a workflow can propose, what it reads to confirm the result, and what it needs

A workflow can only make the changes on this page, and each one waits for
approval first. Under **What it may change**, a goal picks which kinds of
change its runs may propose. Anything not picked stays read only.

Every change runs as the person who created the goal, with that person's
role. Any member can create a goal, and a few changes below need a higher role.
If the creator lacks or later loses the role a change needs, the change fails
and nothing changes.

Before it changes a CostGraph record, the agent reads the record to get its
current state. After the change, it reads the record again to confirm the
change took effect.

## Budgets

These changes need **Budgets** under **What it may change**. The agent reads
your budgets, with spend so far, forecast, and status, before and after each
change. See [Budgets](/costgraph/budgets).

| Change | What it does |
| - | - |
| Create a budget | Adds a budget with alert thresholds. Its currency must match the currency the spend is billed in |
| Update a budget | Replaces the budget's scope, amount, thresholds, and owners |
| Delete a budget | The budget stops tracking spend and sending alerts |

## Reports

A workflow can create, edit, and duplicate reports in any goal. Sharing,
scheduling, and deleting a report need **Reports** under **What it may
change**. The agent reads the report before and after each change.

| Change | What it does |
| - | - |
| Create a report | Saves a new report owned by the goal's creator |
| Update a report | Renames a report, or changes its time range |
| Save a report document | Saves a new version of the report. If the report changed since the agent read it, nothing is saved |
| Duplicate a report | Copies a report into a new private report owned by the goal's creator |
| Set report visibility | Shares a report with everyone in the tenant, or makes it private again |
| Schedule a report | Sends a report daily, weekly, or monthly as CSV or XLSX. Sending to shared destinations needs an admin or owner |
| Send a scheduled report now | Sends one copy now to the schedule's recipients |
| Stop a report schedule | Deletes the schedule so the report is no longer sent |
| Delete a report | Archives the report. Its version history is kept |

## Split rules

These changes need **Cost allocation** under **What it may change**. The agent
reads your split rules and their targets before and after each change.

| Change | What it does |
| - | - |
| Create a split rule | Splits the spend of one tag value across other values of the same key: evenly, by fixed percentages, or in proportion to each target's own spend |
| Update a split rule | Replaces a split rule and all of its targets |
| Delete a split rule | The days it covered show unsplit again, or under the earlier rule |

## Tagging rules

Applying tagging rules needs **Tagging rules** under **What it may change**.
It makes the rules of a queued [virtual tag](/costgraph/virtual-tags/overview)
suggestion live, which changes how your spend is attributed. CostGraph applies
exactly the rules you approved, and changes nothing if the suggestion changed
since. The agent reads your virtual tags and their rules to confirm.

## Prices

These changes need **Pricing** under **What it may change**, and an admin or
owner as the goal's creator. See
[On-prem pricing](/costgraph/operator/on-prem-pricing).

| Change | What it does | What it reads |
| - | - | - |
| Change virtual machine tags | Sets or removes allowlisted tags on a virtual machine. Setting `costgraph.ai/pricing-id.compute` assigns one of your compute prices; removing it returns the machine to automatic pricing | The virtual machine, its price, and its disks |
| Set a disk price | Assigns one of your disk prices to a disk, or returns it to automatic pricing | The disk's price and where its pin comes from |

## Billing exports

These changes need **Billing export** under **What it may change**, and an
admin, owner, or billing admin as the goal's creator. The agent reads your
billing export connections and their meters before and after each change. See
[Billing exports](/costgraph/integrations/exports/overview).

| Change | What it does |
| - | - |
| Create a meter | Binds a virtual tag key to a meter in a connected billing platform, so each value of the key is billed as a customer there |
| Deactivate a meter | Stops the meter pushing usage. Everything it already reported is kept |
| Reactivate a meter | Resumes a deactivated meter from what it already reported |
| Run a billing export | Pushes settled usage for every active meter now, instead of waiting for the nightly run |

## Tickets

Filing a ticket needs **Tickets** under **What it may change**, and a
connected Jira, Linear, or GitHub. A workflow creates a ticket for an anomaly
or a recommendation, in a project or repository your connection allows.
Each anomaly or recommendation gets at most one ticket in each tool. CostGraph
records the ticket's key and link on the run. See
[Jira](/costgraph/integrations/jira), [Linear](/costgraph/integrations/linear),
and [GitHub issues](/costgraph/integrations/github-issues).

## Cloud changes

A workflow changes AWS resources through a connected AWS account with
**Let Workflows make approved changes** turned on. The change must fall in a
category the goal picked: **Compute**, **Databases**, **Snapshots**, or
**Storage**. The agent inspects resources with read-only AWS calls before it
proposes a change, and again afterwards to confirm it.

The following AWS changes are available:

* **EC2**: start or stop instances, change an instance's type, change an EBS
  volume's size, type, IOPS, or throughput, and add or remove tags.
* **Auto Scaling**: change a group's minimum, maximum, or target size.
* **EKS**: change a managed node group's scaling.
* **RDS**: change an instance's class or storage, and start or stop instances
  and clusters.

Cleanup needs **Also allow cleanup** on the AWS connection too. It lets a
workflow delete unused EBS volumes, EBS snapshots, and RDS snapshots, release
unused Elastic IPs, and set S3 bucket lifecycle rules.

## Pull requests

A workflow can open a pull request in a repository the CostGraph GitHub App
can reach. For example, it can lower a CPU request in a Helm values file. The change
must fall in a category the goal picked: **Compute**, **Databases**,
**GPUs**, **Snapshots**, or **Storage**.

You approve the pull request's title, repository, and instructions. After
approval, a separate repository agent makes the change on a new branch and
opens the pull request into the approved base branch. CostGraph checks every
GitHub write against your approval, and never writes to the default branch or
to `.github/workflows` files. CostGraph then checks the pull request on GitHub
and records it on the run.

Nothing merges on its own. Review and merge the pull request in GitHub, or
close it to discard the change.

## Connected services

A workflow can create, update, and delete resources in a connected service.
It needs **Integrations** under **What it may change**, and the service must
be one of the goal's **Connected tools**. The following services are
available:

* DigitalOcean
* Datadog
* Vercel
* Google Cloud
* Hetzner
* OVHcloud
* Vultr
* Linear
* GitHub

Each change follows the goal's approval setting. With **Ask before every
change**, every change waits for you. With **Allow any change**, changes run
without asking, up to the goal's decision limit. See
[Approvals](/costgraph/workflows/approvals#allow-any-change).

### Resource marking

When a workflow creates a resource, CostGraph marks it with a tag or label.
The same marking lets you find everything a workflow made.

| Key | Value |
| - | - |
| `costgraph.ai/managed` | `true` |
| `costgraph.ai/run` | The ID of the run that created it |

Some services don't accept `.` or `/` in tag keys. There, CostGraph writes the
key in the form the service allows:

| Service | Where | Key and value |
| - | - | - |
| Datadog | Tags | `costgraph.ai/managed:true` and `costgraph.ai/run:<run id>` |
| Hetzner | Labels | `costgraph.ai/managed=true` and `costgraph.ai/run=<run id>` |
| Vultr | Tags | `costgraph.ai/managed=true` and `costgraph.ai/run=<run id>` |
| Vercel | Deployment metadata | `costgraph.ai/managed=true` and `costgraph.ai/run=<run id>` |
| DigitalOcean | Tags | `costgraph-ai:managed:true` and `costgraph-ai:run:<run id>` |
| Google Cloud | Labels | `costgraph-ai-managed=true` and `costgraph-ai-run=<run id>` |

GitHub, Linear, and OVHcloud have no tag field for these changes, so those
resources aren't marked. Firewalls in DigitalOcean aren't marked either.

CostGraph always keeps the tags and labels you set. When a workflow updates a
resource, it adds the marking only if the agent sets tags itself, so an update
never replaces your own set.

### Find what CostGraph made

Filter by the tag or label in the service's own console or API:

* To list everything CostGraph created, search for `costgraph.ai/managed`, or
  the form in the preceding table, with the value `true`.
* To list what one run created, search for its `costgraph.ai/run` value. The
  run ID is on the run's page.

### Deletes

Before a delete, CostGraph reads the resource and checks for the marking. A
marked resource follows the goal's approval setting. A resource without the
marking, or one CostGraph can't read, always waits for your approval, even
under **Allow any change**.

## Next steps

<CardGroup cols={2}>
  <Card title="Approvals" icon="circle-check" href="/costgraph/workflows/approvals">
    Review, approve, or reject a change.
  </Card>

  <Card title="Workflows from Graph AI" icon="comments" href="/costgraph/workflows/graphai">
    Start a workflow from chat, Slack, or MCP.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.