Skip to main content

Check out Port for yourself 

Entity page

Each entity has a dedicated page that contains 4 tabs (by default):

Overview​

The overview tab is a dashboard, used to display widgets related to the entity.

By default, each entity will have a Details widget, which displays the entity's properties and their values, and other metadata.

Manage properties​

In the top right corner of the details widget, you can find the button that opens the "manage properties" modal, which allows you to:

  • Show/hide empty values - properties with empty values will be hidden if the toggle is off.
  • Show/hide specific properties in the widget.

Additional widgets can be added by clicking on the + Widget button in the top right corner of the dashboard.

By default, all related entities in the same direction will automatically appear in this table. This is true for both forward-related and backward-related entities. Indirectly-related entities will not appear but can be added manually, check out the indirect relations section on how to add indirectly related entities.

For example:

Workflow Run has a forward-relation to Deployment Workflow, which has a forward-relation to Service, which has a backward-relation to Deployment.
Since we changed direction midway, this relation is indirect:

When looking at the entity page of a certain Workflow Run, the related entities Deployment Workflow and Service automatically appear, but Deployment does not, since its relation is in the other direction.

  1. Click the + button above the table to add a custom tab.


  2. Fill in the form:

    • Set the tab's Name and optional Description.

    • Choose the Related blueprint you want to display.

    • Pick a Relation path:

      • All paths – includes all available paths from the current blueprint to the target blueprint.
      • Specific path – choose the specific relation chain.

    • (Optional) Add Additional filters to restrict the result set.

Relation path options

The relation path dropdown displays straightforward, acyclic paths. For complex scenarios involving circular relationships, advanced path configurations, multiple self-relations, or maxHops, use JSON mode.

Using "All paths" is less performant than selecting a specific path, as it requires the system to evaluate multiple relationship paths.

Additional filters​



Selecting Filters opens a dialog where you can build conditions using form controls (property, operator, value).
You can switch to a JSON editor using the Edit JSON button to define the dataset directly.

The filters visual editor doesn't support nested queries so in the case of nested queries, use the JSON editor to define the dataset.

The dataset follows this structure based on the search and query syntax:

{
  "combinator": "and",
  "rules": [
    {
      "property": "$title",
      "operator": "contains",
      "value": "awesome-package"
    }
  ]
}

Use the JSON editor when you need to copy/paste filter sets, keep them in source control, or express conditions that are faster to author as JSON. You can toggle back to the form at any time.

Define the tab in JSON mode

You can also toggle Json Mode in the "Add tab" dialog to author the entire tab as JSON. An example:

{
  "dataset": {
    "combinator": "and",
    "rules": [
      {
        "property": "$title",
        "operator": "contains",
        "value": "awesome-package"
      }
    ]
  },
  "title": "custom path package",
  "targetBlueprint": "Package",
  "relationPath": {
    "path": ["service_in_env", "package"],
    "fromBlueprint": "service_in_env_deployments"
  }
}

This JSON corresponds to a tab named custom path package that targets the Package blueprint, follows a specific path from service_in_env_deployments via service_in_env to package, and filters results to titles containing the letter awesome-package.

Show/hide columns​

By default, the related entities table will display the following columns for each entity:
Title, Last update time, and Creation time.
Other properties will be hidden by default.

You can always customize the table to hide/show columns.

Indirect relations​

In some scenarios, you may want to display entities that are not directly related but connected through a common blueprint. This is useful when you have multiple services that share relationships with a common entity.

For example, consider this relationship structure:



From the diagram, we can see that:

  • Deployment Workflow has a relation to Microservice
  • Deployment has relations to Microservice (including relation_1 and relation_2)
  • Deployment Workflow and Deployment are not directly related, but connected through Microservice

When you're on the entity page of a Deployment Workflow, the related entity Microservice automatically appears, but Deployment does not, since its relation is in the other direction. However, you can create a custom tab to show Deployment entities by leveraging the indirect relationship through Microservice.

Add a tab for an indirectly related blueprint

  1. Click the + button above the Related Entities table.

  2. Set the tab name and description.

  3. Choose Deployment as the Related blueprint.

  4. For the Relation or property, select the specific relation from Deployment Workflow to Microservice that you want to traverse.

This approach allows you to display indirectly related entities while maintaining control over the specific relationship path used for the connection.

Multiple relations scenario

If Deployment Workflow has multiple relations to Microservice (e.g., deployment_target and monitoring_target), you can choose which specific relation path to use for more refined and filtered results.

Additionally, when you have an existing relation between blueprints, Port automatically creates a mirror property relation that allows you to traverse the relationship in both directions. This mirror relation will appear as an option in the relation dropdown, enabling you to explore connections from either side of the relationship.

Self-relation​

A self-relation allows a blueprint to establish a relationship with itself. This is useful when you want entities of the same blueprint to be related to other entities within that same blueprint.

For example, consider a Team blueprint where:

  • Organizations contain teams.
  • Teams can belong to other organizational entities (like groups).

All entities share the same blueprint but have hierarchical relationships.

When defining a self-relation, you can specify how many "hops" to traverse in the relationship chain.
Hops represent the number of jumps you want to make upstream or downstream through the self-relation.

Create a self-relation

Before performing the following steps, make sure the desired blueprint has a relation to itself.

Add self-relation (click to exapnd)
  1. Go to the Builder page of your portal.
  2. Choose the relevant blueprint.
  3. Click the + New relation button.
  4. Give the property a title, choose the same blueprint in the Related to field.
  5. Choose the entity limit and whether its required.
  6. Click Save.

Set up self-relations tab

To add a self-relation tab to the related entities:

  1. Click the + button in the Related Entities table.

  2. Choose your blueprint as the Related blueprint.

  3. Select the self-relation path from the available paths.

  4. If you want to traverse more than one hop, switch to Json mode.

    In JSON mode you can:

    • Specify multiple self-relation identifiers (for fixed hops).

       "relationPath": {
       "path": [
         "self_relation",
         "self_relation"
         ]
       }

    • Use maxHops (for variable hops).

       "relationPath": {
         {
           "relation": "<SELF_RELATION_IDENTIFIER>",
           "maxHops": <number between 1 and 15>
         }
       }

    • Combine fixed hops with maxHops for mixed control.

      "relationPath": {
        "path": [
          "self_relation",
          {
            "relation": "<SELF_RELATION_IDENTIFIER>",
            "maxHops": <number between 1 and 15>
          }
        ]
      }
      maxHops limitation

      The maxHops parameter can only be applied once per path, and it accepts values from 1 to 15.

  5. Click on Save to save the tab.

Self-relation identifier

Note that self_relation in these examples represents the identifier of the self-relation you created in your blueprint. Replace it with your actual self-relation identifier.

Examples

Let's take a look at some examples using the concept of Teams.



Basic self-relation with multiple self-relations:

If you want exactly 2 hops, specify the relation twice:

{
  "dataset": {
    "combinator": "and",
    "rules": []
  },
  "title": "Team Hierarchy",
  "targetBlueprint": "Team",
  "relationPath": {
    "path": [
      "self_relation",
      "self_relation"
    ],
    "fromBlueprint": "Team"
  }
}

In this case, the added tab under the Unit entity should show the Group entity.

Self-relation with maxHops for variable hops:

If you want a variable number of hops (between 1 and 15), use maxHops:

{
  "dataset": {
    "combinator": "and",
    "rules": []
  },
  "title": "Team Hierarchy",
  "targetBlueprint": "Team",
  "relationPath": {
    "path": [
      {
        "relation": "team_self_relation",
        "maxHops": 4
      }
    ],
    "fromBlueprint": "Team"
  }
}

In this case, the added tab under the Unit entity should show the Basic Team, Group and Office entities.

Mixed approach example:

You can also mix fixed hops with variable hops. For example, if you specify self_relation twice followed by a maxHops object, the system will start traversing from the 2 hops already made and continue with the additional hops specified in maxHops.

{
  "title": "Team Hierarchy",
  "targetBlueprint": "Team",
  "dataset": {
    "combinator": "and",
    "rules": []
  },
  "relationPath": {
    "path": [
      "self_relation",    // 1st hop: Unit -> Basic Team
      "self_relation",    // 2nd hop: Basic Team -> Group  
      {
        "relation": "team_self_relation",
        "maxHops": 3      // Continues from Group, adding up to 3 more hops (Group -> Office -> etc.)
      }
    ],
    "fromBlueprint": "Team"
  }
}

In this example, the system will traverse 2 fixed hops (Unit → Basic Team → Group) and then continue with up to 3 additional hops using the team_self_relation, starting from where the fixed hops left off. This could represent a complete organizational hierarchy from Unit all the way up to higher-level organizational structures.

In this case, the added tab under the Unitentity should show the Group and Office entities.

Simple relation path example:

You can also use regular relations (not self-relations) in your paths:

{
  "dataset": {
    "combinator": "and",
    "rules": []
  },
  "title": "Developer",
  "targetBlueprint": "developer",
  "relationPath": {
    "path": [
      "member_of"
    ]
  }
}
The fromBlueprint property

The fromBlueprint property is only needed when the path starts from the current page's blueprint and ends with the entities listed in the tab. For more information about relation paths see the Relation operators documentation.

Runs​

If the entity's blueprint has any actions configured, the Runs tab will display their history log, results, log streams, and more.

Audit log​

This tab displays all actions (including CRUD) that caused any change to the entity's configuration.
For each change, useful metadata will be shown such as the initiator, diff before and after the change, relevant blueprint, and more.

Additional tabs​

Visual properties​

Some of the available property types are visual by nature. When defining one of these properties in a blueprint, an additional tab will be automatically created in each entity page related to this blueprint, displaying the property's content in the relevant visual format.

The following property types are supported:

Scorecards​

If the entity's blueprint has any scorecards configured, a Scorecards tab will be automatically created in the entity page.

The tab will display the entity's compliance status with each of its scorecards.

Dashboard tabs​

You can add additional, customizable dashboard tabs to an entity page by clicking the + button.
Each dashboard tab name can be customized and edited.

Limitations​

  • You can add up to 5 dashboard tabs per entity page.
  • Dashboard tab names must be unique and are limited to 30 characters.

Dashboard filters​

Dashboard filters allow you to apply selected meta property filters across all supported widgets within a dashboard at once. This makes it easier to explore data consistently, without having to filter each widget individually.

Supported widgets​

Dashboard filters currently apply to the following widgets:

Supported meta properties​

Dashboard filters can be applied to the following properties:

  • Owning teams:
    • Filter entities based on selected team(s).
    • Use the My Teams option to dynamically filter entities relevant to the current user.
    • Applies only to blueprints that include an Owning Team property.
  • Title: Filter entities by their title using different string operators.
  • Identifier: Filter entities by their identifier using different string operators.

Permissions​

Admin role: As an admin (or a member with edit permissions for the dashboard), you can add, edit, or remove filters from the dashboard page. Then, save the view to apply it for other users.

Member role: As a member, you can view and edit the operator and value of the current filters within the page (unless the page is locked).