# Products

Products are the top-level organizational unit in Interlynk. Each Product represents a software artifact your organization builds, releases, and tracks — such as a web application, library, firmware image, or container. All SBOM data, vulnerability tracking, policy evaluation, and compliance reporting is scoped to a Product and its Environments.

***

## Overview

A Product groups all SBOM versions, vulnerability data, policies, and automation rules for a single software artifact. Products provide logical isolation — each has its own Environments, settings, labels, and notification subscriptions.

Products support:

* **Environments** — isolated contexts (e.g., Development, Production) with independent settings, automation rules, and policies.
* **Automation Rules** — conditional actions that modify SBOMs on import (e.g., set missing supplier fields, apply license expressions).
* **Labels** — color-coded tags for cross-cutting categorization (e.g., `compliance:fda`, `team:platform`).
* **Notifications** — per-environment subscriptions for vulnerability, license, and policy changes.
* **Settings** — per-environment controls for scanning, data retention, and integrations.

## Architecture

```
Organization
  └── Product (ProjectGroup)
        ├── Environment: Default
        │     ├── Versions (SBOMs)
        │     ├── Automation Rules
        │     ├── Settings (scan, retention, VEX)
        │     └── Policies
        ├── Environment: Development
        │     └── ...
        ├── Environment: Production
        │     └── ...
        ├── Labels
        ├── Notifications
        └── Change Log (Activity Audit)
```

**Interactions:**

* **Dashboard** — create, configure, disable, and delete Products.
* **CLI** (`pylynk prods`) — list Products, upload SBOMs (auto-creates Products).
* **API** — GraphQL mutations for creating, updating, and deleting Products (`ProjectGroup` model).
* **MCP** (`lynk-mcp`) — read-only queries for listing and inspecting Products.

***

## Product Lifecycle

| State        | Behavior                                                                                                                                                                  |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Active**   | Accepts SBOM uploads, vulnerability scanning runs, contributes to metrics and analytics.                                                                                  |
| **Disabled** | Stops accepting new Versions and SBOMs. Vulnerability updates halt. Excluded from platform metrics and analytics. Existing data remains accessible for historical review. |
| **Deleted**  | Permanently removed. All associated Environments, Versions, Components, and Vulnerabilities are deleted.                                                                  |

A disabled Product can be re-enabled. Deletion is irreversible.

{% hint style="warning" %}
Deleting a Product removes all associated data permanently. Disable Products instead if you need to preserve historical data for audit purposes.
{% endhint %}

***

## Creating Products

### Via Dashboard

1. Navigate to the **Products** page.
2. Click the **+** (Add Product) button in the top right.
3. Enter the **Name** (required) and optional **Description**.
4. Click **Save**.

The Product is created with three default Environments: Default, Development, and Production.

### Via CLI

The `pylynk` CLI creates Products implicitly on first SBOM upload if they do not already exist:

```bash
pylynk upload --prod "my-backend-service" --sbom sbom.cdx.json
```

To list existing Products:

```bash
pylynk prods
pylynk prods --output json
pylynk prods --output csv
```

| Parameter         | Required | Default                     | Description                                 |
| ----------------- | -------- | --------------------------- | ------------------------------------------- |
| `--output`        | No       | `table`                     | Output format: `table`, `json`, `csv`       |
| `--human-time`    | No       | Off                         | Display timestamps in human-readable format |
| `--token`         | No       | `$INTERLYNK_SECURITY_TOKEN` | Override authentication token               |
| `-v`, `--verbose` | No       | Off                         | Enable verbose output                       |

### Via API

```bash
curl -X POST https://api.interlynk.io/lynkapi \
  -H "Authorization: Bearer $INTERLYNK_SECURITY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "mutation CreateProduct($input: CreateProjectGroupInput!) { createProjectGroup(input: $input) { projectGroup { id name } errors } }",
    "variables": {
      "input": {
        "name": "my-backend-service",
        "description": "Core backend API service"
      }
    }
  }'
```

### Via MCP

The `lynk-mcp` server provides read-only access to Products:

```
list_products          # List all products
get_product            # Get product details with all environments
```

{% hint style="info" %}
Product creation via MCP is not supported. Use the Dashboard, API, or CLI to create Products.
{% endhint %}

***

## Disabling and Deleting Products

### Disabling a Product

1. Navigate to the **Products** page.
2. Click the **Active** toggle switch on the Product row to disable it.

A disabled Product:

* Stops accepting version creation and SBOM uploads.
* Stops updating vulnerabilities for existing versions.
* Does not contribute to platform metrics and analytics.
* Can be re-enabled at any time.

{% hint style="info" %}
If a disabled Product is not visible in the list, check the **Active** filter at the top of the Products table — it defaults to showing only active Products.
{% endhint %}

### Deleting a Product

1. Navigate to the **Products** page.
2. Click the **...** (Actions) on the Product row and select **Delete Product**.
3. Type `DELETE` in the confirmation modal and click **Yes**.

Alternatively, from inside the Product Environment page, click the **Delete Product** icon.

***

## Environments

Each Product is created with three default Environments: **Default**, **Development**, and **Production**. Environments provide isolated contexts within a Product — each has its own versions, automation rules, settings, and policies.

| Environment     | Typical Use                                                       |
| --------------- | ----------------------------------------------------------------- |
| **Default**     | Catch-all for SBOMs that do not match a specific environment rule |
| **Development** | Feature branches, development builds, pre-release testing         |
| **Production**  | Main/master branch, release tags, production deployments          |

Environments are mapped to incoming SBOMs via [Environment Rules](https://docs.interlynk.io/administration/environment-rules). You can create additional environments to match your deployment topology (e.g., `staging`, `qa`).

For full details on environment configuration, see [Core Concepts: Environments](https://docs.interlynk.io/interlynk-core-concepts/environments) and [Administration: Environment Rules](https://docs.interlynk.io/administration/environment-rules).

***

## Automation Rules

Automation Rules modify SBOMs automatically on import, reducing manual toil for recurring quality and compliance fixes. Rules consist of a **name**, a set of **conditions** to match, and **actions** to take when conditions are met.

### Rule Structure

Rules apply to one of two subject types:

| Subject       | Description                                               | Example                                                                                      |
| ------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **Version**   | Conditions and actions target version-level SBOM metadata | Set the Supplier Contact Name when it is missing                                             |
| **Component** | Conditions and actions target a specific component        | Set license expression to `Apache-2.0` when Component Name is `log4j` and license is missing |

{% hint style="info" %}
Automation Rules are configured per Environment. Rules can be copied from one Environment to another.
{% endhint %}

### Creating Rules Manually

1. Navigate to the **Products** page and click the Product Name.
2. Select the target Environment.
3. Click the **Automation Rules** tab.
4. Click **+** (Add Rule).
5. Enter a **Rule Name**.
6. Select conditions to match — once the first condition is specified, additional conditions apply to the same subject.
7. Add actions — actions only apply to subjects matching the conditions.
8. Click **Create**.

### Creating Rules from Checks

When an SBOM fails a check, you can create a rule directly from the check result:

1. Navigate to the Product and select a Version.
2. Click the **Checks** tab.
3. Click the **Fix** icon under Resolution.
4. Configure the fix.
5. Click **Save as Rule** to create an Automation Rule.

### Rule Priority and Ordering

Rules are evaluated in order. To reorder:

1. Navigate to the **Automation Rules** tab.
2. Use the drag handle on each rule to reorder.

Rules with higher position (lower in the list) execute last and can override earlier rules.

### Copying Rules Between Environments

1. Navigate to the **Automation Rules** tab.
2. Click the **...** (Actions) on the rule.
3. Select **Copy To \[Environment Name]**.

### Disabling Rules

* **Individual rule**: Toggle the **Active** switch on the rule row.
* **All automation for an environment**: Navigate to the **Settings** tab and toggle the **Automation** switch off.

{% hint style="warning" %}
Disabling automation in Settings is per-Environment. To disable automation across all Environments, repeat for each one.
{% endhint %}

### Rules Library

The platform ships with a library of common rules (e.g., copying Author Name to Supplier Name). These rules are disabled by default and can be enabled as needed.

### Applying Rules

* **Automatic**: Rules are applied on every SBOM import. Changes are logged in the SBOM's Change Log.
* **Manual**: Navigate to the Product Environment page, click **...** (Actions) on a Version, and select **Run Automation**.

***

## Product Settings

Each Environment within a Product has its own settings that control scanning behavior, data retention, and integration features. Settings are inherited from [Organization Environment Defaults](https://docs.interlynk.io/administration/environment-defaults) at creation time and can be customized per Environment.

### Import Actions

| Setting                                        | Description                                                          |
| ---------------------------------------------- | -------------------------------------------------------------------- |
| **Run SBOM Checks**                            | Execute quality and compliance checks on uploaded SBOMs              |
| **Always Use Latest Parts**                    | Keep component information updated with latest available data        |
| **Run Internal Labeling**                      | Identify and label internal components                               |
| **Run Auto Archive**                           | Automatically archive old SBOM versions                              |
| **Apply Automation Rules**                     | Execute configured automation rules on upload                        |
| **Run Vulnerability Scan**                     | Scan components for known vulnerabilities                            |
| **Run Component Support Analysis**             | Evaluate component support status (EOL, deprecated, maintained)      |
| **Retain Vulnerability Status with Version**   | Preserve VEX status when a new SBOM version is uploaded              |
| **Interpret License List as "AND" expression** | Treat multi-license declarations as requiring all listed licenses    |
| **Copy VEX Across Versions on Import**         | Carry forward VEX dispositions from previous versions to new imports |
| **Enable PR Comments**                         | Post SBOM analysis results as comments on pull requests              |

### Data Retention

| Setting            | Options                             | Default     |
| ------------------ | ----------------------------------- | ----------- |
| **Data Retention** | 1, 30, 90, 365 days, or Forever (0) | Forever (0) |

### Configuring Settings

1. Navigate to the Product and select the target Environment.
2. Click the **Settings** tab.
3. Toggle the desired import actions on or off.
4. Select a data retention period.
5. Changes are saved automatically.

***

## Support Status

Support status tracking monitors the maintenance state of components within a Product's SBOMs. When **Run Component Support Analysis** is enabled in Settings, the platform evaluates each component and assigns a support level:

| Support Level            | Description                                                      |
| ------------------------ | ---------------------------------------------------------------- |
| **Actively Maintained**  | Component is actively developed and receives updates             |
| **No Longer Maintained** | Component has stopped receiving updates but is not yet abandoned |
| **Abandoned**            | Component is no longer maintained or supported                   |
| **Unspecified**          | Support status could not be determined                           |

Support status data is visible on the Version detail page under the **Support** tab and can be included in downloaded SBOMs using the `--include-support-status` flag.

For support level overrides and organization-wide support management, see [Administration: Health Scoring](https://docs.interlynk.io/administration/health-scoring).

***

## Labels

Labels are color-coded tags applied to Products for cross-cutting categorization and filtering. Use labels to group Products by team, compliance requirement, tier, or any other dimension.

### Managing Labels

1. Navigate to the **Products** page.
2. Click the **Manage Labels** icon in the top right.

**Create a Label:**

1. Enter a **Name** for the label.
2. Type a color hex code or click the auto-shuffle icon for random colors.
3. Preview the label in the **Label Preview** badge.
4. Click **+ Add Label**.

**Edit a Label:**

1. Click the **Edit** icon next to the label.
2. Modify the name or color.
3. Click the Accept or Cancel icon.

**Delete a Label:**

1. Remove the label from all Products it is applied to first.
2. Click the **Delete** icon next to the label.

{% hint style="warning" %}
Labels must be removed from all Products before they can be deleted.
{% endhint %}

### Applying Labels to Products

1. Navigate to the **Products** page.
2. Click **...** (Edit Labels) on the Product row.
3. Select labels from the checkbox list.
4. Click outside the submenu to apply.

Labels are visible on the Products list and can be used to filter and sort Products.

***

## Change Log

The Change Log provides an audit trail of all modifications made to a Product's SBOMs. Every change resulting from automation rules, manual edits, or system processing is recorded.

### Viewing the Change Log

1. Navigate to the Product and select a Version.
2. Click the **Change Log** tab.

The Change Log displays:

| Column        | Description                                                   |
| ------------- | ------------------------------------------------------------- |
| **Timestamp** | When the change occurred                                      |
| **Action**    | What was changed (e.g., field update, component modification) |
| **Source**    | Whether the change was manual, automated, or system-generated |
| **Details**   | Specific values before and after the change                   |

***

## Notifications

Users can subscribe to notifications for changes within a Product's Environments. Notifications alert on vulnerability discoveries, license changes, and policy failures.

### Subscribing to Notifications

1. Navigate to the Product Environment page.
2. Click the **Bell** icon.
3. Select notification categories: **Vulnerabilities**, **Licenses**, **Policies**, or **All**.

Notifications are delivered based on configured integrations — [Slack](https://docs.interlynk.io/administration/slack), [Microsoft Teams](https://docs.interlynk.io/administration/microsoft-teams), or [Email](https://docs.interlynk.io/administration/email).

{% hint style="info" %}
At least one integration must be configured in **Settings > Organization > Integrations** before notifications become effective.
{% endhint %}

***

## Permission Matrix

| Permission                | Admin | Operator | Viewer |
| ------------------------- | :---: | :------: | :----: |
| View products             |   ✓   |     ✓    |    ✓   |
| Create products           |   ✓   |     ✓    |    —   |
| Update products           |   ✓   |     ✓    |    —   |
| Delete products           |   ✓   |     ✓    |    —   |
| Edit share link           |   ✓   |     ✓    |    —   |
| Edit product automations  |   ✓   |     ✓    |    —   |
| Edit product policies     |   ✓   |     ✓    |    —   |
| Edit product integrations |   ✓   |     ✓    |    —   |
| Edit product settings     |   ✓   |     ✓    |    —   |

For full permission details, see [Role Management](https://docs.interlynk.io/administration/role-management).

***

## Security Warnings

{% hint style="warning" %}
**Product deletion is irreversible.** All Environments, Versions, Components, Vulnerabilities, and audit history are permanently removed. Disable Products instead of deleting them if you need to preserve historical data.
{% endhint %}

{% hint style="warning" %}
**Automation rules execute on every import.** Misconfigured rules can silently modify SBOM data at scale. Test rules on a development environment before enabling them in production.
{% endhint %}

{% hint style="warning" %}
**"Apply to All Projects" overwrites per-project settings.** Use this action only when you intentionally want to standardize all projects. Per-project customizations will be lost.
{% endhint %}

***

## Common Misconfigurations

| Issue                                   | Symptom                                                   | Fix                                                                      |
| --------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------ |
| Duplicate Products for the same service | Fragmented vulnerability data, inconsistent metrics       | Consolidate SBOMs under a single Product; delete the duplicate           |
| Product name mismatch in CI/CD          | New Products created unintentionally on each pipeline run | Standardize the `--prod` value in pipeline configuration                 |
| Product disabled accidentally           | SBOM uploads rejected with no clear error                 | Re-enable the Product from the Products page (check the Active filter)   |
| Automation rules not running            | SBOM data not modified on import                          | Check that **Apply Automation Rules** is enabled in Environment Settings |
| Rules configured in wrong Environment   | Automation applies to development but not production      | Copy rules to the correct Environment or configure per-environment rules |
| Notifications not delivered             | No alerts on vulnerability changes                        | Verify at least one integration (Slack, Teams, Email) is configured      |
| Vulnerability scanning disabled         | No vulnerability data after SBOM upload                   | Enable **Run Vulnerability Scan** in Environment Settings                |
| Labels not deletable                    | Delete action fails silently                              | Remove the label from all Products before deleting                       |

***

## Recommended Best Practices

* **Use consistent naming conventions.** Adopt a pattern such as `team-service-name` or `org/repo-name` so Products are easily identifiable and sortable.
* **Use labels for cross-cutting categorization.** Labels like `compliance:fda`, `team:platform`, `tier:critical` allow filtering and grouping without duplicating Product definitions.
* **Avoid creating duplicate Products.** If a Product already exists, upload SBOMs to it rather than creating a new one with a similar name.
* **Disable rather than delete.** If a Product reaches end-of-life, disable it to preserve historical data for audit purposes.
* **Scope Products to compliance boundaries.** Products with different regulatory requirements should be separate so that policies can be tailored independently.
* **Enable vulnerability scanning and SBOM checks by default** in Environment Settings — these are core value-add features.
* **Enable "Retain Vulnerability Status with Version"** to avoid re-triaging vulnerabilities when SBOMs are re-uploaded.
* **Test automation rules in development** before enabling them in production Environments.
* **Configure notifications early.** Subscribe to vulnerability and policy alerts in production Environments to catch issues promptly.
* **Review the Change Log regularly** to audit automated and manual modifications to SBOMs.