# Products

## Definition

A Product represents a software artifact that your organization builds, releases, and versions. It is the top-level grouping for all SBOM data within the platform.

A Product may represent:

* A web application or API service
* A library or SDK
* A firmware image
* A container image
* A hardware appliance with embedded software

Products provide logical isolation — each Product has its own set of Environments, Versions, policies, automation rules, and settings.

## Multi-Tenant Isolation

Products are scoped to your organization. No data from one organization's Products is visible to another organization. Within an organization, access to Products is governed by role-based permissions.

## When to Create a New Product

| Scenario                                | Recommendation                                                                                 |
| --------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Monolithic application                  | One Product                                                                                    |
| Microservices (independently versioned) | One Product per service                                                                        |
| Microservices (released as a unit)      | One Product, use Parts to compose sub-SBOMs                                                    |
| Internal tool vs. customer-facing app   | Separate Products — different compliance requirements                                          |
| Mobile app + backend API                | Separate Products — different build pipelines and release cadences                             |
| Same codebase, multiple build targets   | One Product with multiple Environments, or separate Products if compliance requirements differ |

**Compliance boundaries matter.** If two artifacts have different regulatory requirements (e.g., one is FDA-regulated and one is not), create separate Products so that policies and compliance checks can be scoped independently.

## Managing Products

### Creating via UI

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

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

### Creating 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"
      }
    }
  }'
```

### Creating via CLI

The `pylynk` CLI does not have an explicit `create product` command. Products are created 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
```

### Creating via MCP

When using the `lynk-mcp` server with an AI assistant, Products can be discovered and queried:

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

{% hint style="info" %}
The MCP server provides read-only access to Products. Product creation is done via the UI, API, or CLI.
{% endhint %}

## 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. |
| **Marked for Deletion** | Scheduled for permanent removal. All associated Environments, Versions, Components, and Vulnerabilities will be deleted.                                                  |

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

## 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 (e.g., `compliance:fda`, `team:platform`, `tier:critical`) allow filtering and grouping across Products 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.

## 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 `--prod` value in pipeline configuration           |
| Product disabled accidentally           | SBOM uploads rejected with no clear error                 | Re-enable the Product from the Products page                   |
| No description set                      | Products are hard to distinguish in large organizations   | Add descriptions during creation or via the edit action        |