# 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        |


---

# Agent Instructions: 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:

```
GET https://docs.interlynk.io/interlynk-core-concepts/products.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.