Skip to content

Package Fields, Details, and Labels

What this page helps with

Packages group related artifacts and give a compact view of version, ownership, and labeling. This page explains which fields are useful in daily work and how to interpret them.

Main table fields

The package list typically focuses on:

  • package name
  • number of contained iFlows
  • version
  • creation date
  • created by
  • label

This is enough for many first checks:

  • is the package present at all
  • does it contain the expected number of integration flows
  • is the visible version plausible
  • has it already been labeled for filtering and governance

iFlow count

The iFlow column is important because it gives a quick overview of how much is inside the package.

In practice, it helps answer:

  • is the package small or broad
  • are all expected flows included
  • does the package look incomplete or unexpectedly large

Expanded details

When a package row is opened, additional details help users validate what they are seeing.

Typical details include:

  • identifiers
  • version-related values
  • creation details
  • vendor or source context
  • update-related hints
  • download strategy

These details are useful when a package looks unusual or needs closer comparison.

Labels and tags

Labels help turn a technical package list into something easier to operate.

Use labels when you want to:

  • group related packages
  • mark critical or productive packages
  • make later filtering faster

Good labels reduce search effort and help teams work with a shared vocabulary.

Relationship to artifacts

Packages are the grouping layer, while deeper flow-by-flow analysis happens in the Artifacts area.

That means:

  • use Packages for orientation and grouping
  • use Artifacts when individual runtime or design details matter

Metadata

Some packages expose additional metadata.

Use metadata only when the visible table and detail fields are not enough. For most daily product work, labels, version, and contained flows are the more relevant fields.

Common mistakes

  • treating packages as the only source of truth for runtime status
  • leaving labels empty although teams rely on package filtering
  • expecting package details to replace artifact-level analysis