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

# Applications

Business-level groupings of the repositories and services that deliver a product capability — where tier and ownership are set once and propagate to every member service.

An **Application** groups the repositories and services that work together to deliver a business outcome. It's how Heeler connects technical assets to what the business actually cares about — and it's where you set context **once** and have it flow everywhere it's needed.

<figure><img src="https://414480750-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXP3dp2kecwKA2KvYkntz%2Fuploads%2Fgit-blob-68f978511a67cd29f3d7627960fccf9ce64e734b%2Fcc-cat-applications.png?alt=media" alt="The Applications inventory with business impact, tier, findings, and ownership."><figcaption><p>Applications — business impact and tier alongside aggregated findings and ownership.</p></figcaption></figure>

{% hint style="info" %}
**Prerequisites:** Applications appear once repositories and services are grouped into them (see [Map Your Organization](/mrecEO40m5D6bt7Pq5pE/get-started/map-your-organization.md)), which requires a connected source-code (SCM) provider — and a connected cloud provider (CSP) for their runtime services.
{% endhint %}

Context you set at the application level — **Tier, Tech Lead, Security Lead** — propagates automatically to all of the application's services, so you don't configure ownership or priority service by service. That propagation is also what makes prioritization meaningful: a vulnerability on a Tier 1, revenue-critical application is scored very differently from the same vulnerability on an experimental one.

## The listing

| Column                        | What it shows                                                         |
| ----------------------------- | --------------------------------------------------------------------- |
| **Name**                      | Application name.                                                     |
| **Business Impact**           | Classification — High, Medium, Low.                                   |
| **Tier**                      | Tier designation (Tier 1–4).                                          |
| **SCA Findings**              | Dependency findings across all services, by severity (C / H / M / L). |
| **SAST Findings**             | Source-code findings by severity.                                     |
| **Validated Secrets**         | Active validated secrets.                                             |
| **Team**                      | Owning team(s).                                                       |
| **Tech Lead / Security Lead** | Points of contact.                                                    |
| **Repositories**              | Repositories contributing to the application.                         |
| **Services**                  | Services in the application.                                          |

Filter by Business Impact, Tier, Tech Lead, and Security Lead. See [Filtering and Exports](/mrecEO40m5D6bt7Pq5pE/operate/dashboards/filtering-and-exports.md).

## Reading an application

Selecting an application opens its [**detail view**](/mrecEO40m5D6bt7Pq5pE/catalog/applications/application-detail.md) — the repositories, services, and infrastructure that compose it, its security posture aggregated across every member service (SCA, SAST, secrets, compromised dependencies, license violations), and the ownership that propagates to them all. A whole-application CycloneDX SBOM is available from the same view.

## Domains

A **Domain** groups applications, one level above the application itself. Where an application groups the repositories and services behind a single capability, a domain groups the applications that belong to the same part of the business. **Domain** is also a filter on the dashboards and finding views, so a view can be narrowed to one part of the business without selecting its applications one at a time.

{% content-ref url="/pages/c12I2qe7rWjXJI4D905I" %}
[Domains](/mrecEO40m5D6bt7Pq5pE/catalog/domains.md)
{% endcontent-ref %}

## Related

* [Application Detail](/mrecEO40m5D6bt7Pq5pE/catalog/applications/application-detail.md) — the tabs, controls, and aggregated posture.
* [Services](/mrecEO40m5D6bt7Pq5pE/catalog/services.md) — the runtime services an application is made of.
* [Map Your Organization](/mrecEO40m5D6bt7Pq5pE/get-started/map-your-organization.md) — how applications, tiers, and teams are set up.


---

# 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.heeler.com/mrecEO40m5D6bt7Pq5pE/catalog/applications.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.
