Feature ideas

Current behavior: A Service blueprint is related to multiple AWS blueprints (S3 Bucket, Lambda, SNS Topic, etc.), each coming from a separate mapping. On the Service entity page, the Related Entities section shows one tab per AWS blueprint, so developers must click through multiple tabs to see all AWS resources for a single service. Requested behavior: Allow configuring a single Related Entities tab on an entity page that can aggregate entities from multiple related blueprints. Example: a tab called “AWS Resources” on the Service page that shows all related S3 Buckets, Lambdas, SNS Topics, etc., in one table, without forcing the customer to remodel everything into a single mega AWS blueprint. Why this is needed/Impact: Fetch have paused their AWS integrations because of these limitations in how Related Entities can aggregate multiple blueprints. This is not an immediate blocker but they plan to have it once they release Port to be widely used across company. They want a single place where developers can see all AWS resources for a service, especially as they eventually scale to: > 4 environments × multiple AWS accounts > 100k entities per account for some kinds

Today widgets such as the iframe widget and the Open/AsyncAPI widget are able to query resources based on a URL provided by the user. When such a URL is provided, the query for data in the URL is performed by the user's browser. While this approach is simple, it makes it impossible to query internal resources from the user's organizational network, unless the user logs in to his organization's VPN, and that VPN allows access to that resource. This feature aims to solve this issue by changing the way the querying works, in the new solution, when an iframe or Open/AsyncAPI spec is requested, instead of the user's browser making the request, Port itself will make the request to the organizational network. Since Port is a static service and not a user's browser, it has a closed list of static IPs it can make the request from, making it possible to whitelist those IPs and allow those requests to go through the organizational network to those specific resources. This will make it possible to account for all possible use cases: Querying a fully public URL Querying a private URL that is usually accessible using a VPN, by utilizing API whitelisting Querying a private URL that is not accessible using a VPN, by utilizing API whitelisting and allowing Port's closed set of IPs from the list to access the internal resource without authentication

The requirement is to be able to add the Action History widget to a specific entity page, instead of (or in addition to) showing it only in the Runs tab.

Current Behavior Any property or score (including rules) added to a blueprint automatically appears under all card widgets within that blueprint’s entity page views. Issue I have blueprints with entity page views containing multiple configured cards that group properties for different purposes. When a new score or property is added to an entity, all of those cards are instantly prefilled with the data. This results in unnecessary clutter and confusion across the cards. Suggestion Hide all properties by default, as was done under tables ( https://roadmap.getport.io/ideas/p/property-exclusion-in-tables ). Alternatively, allow the user to choose whether a new property or score should appear under widgets.

Currently, you can ingest markdown documents into Port by creating markdown properties. Each document will be displayed in Port as a tab on the specific entity page. We would like to add the ability to create a "documentation tree" for each entity, allowing you to create a full wiki inside your developer portal. Similar to the singular markdown documents, the documents in the "documentation tree" will be searchable via the global search .

Currently Terraform has only partial page management, with the ability to edit basic pages such as dashboard and blueprint-table; but it has no support yet for specific entity pages.

Port recently introduced the ability to lock catalog pages so that member role users cannot edit columns, filters, etc. We'd like to extend this functionality to entity pages as well, preventing users from modifying which properties they can view. Currently, users can access the "Manage Properties" button on entity pages to display any property from a blueprint, even those intentionally hidden by administrators. This is problematic when blueprints contain properties used for backend calculations or integrations that shouldn't be visible to end users. Adding page locking to entity pages would provide consistent administrative control over data visibility

Ask questions, discuss, and make decisions within context. Allow developers to discuss and comment on different entities directly in Port.

In the current implementation, when using the YAML format without encryption, we can expand the manifest and fill it with the required data. However, if encryption is enabled, this option becomes unavailable. While the format still functions, the user is forced to prepare the text externally (e.g., in a notepad) and then paste it into the field. We would like to have the ability to input multi-line sensitive data directly through the UI Port.

Currently it is only possible to reference (AFAIK) entity view tabs using index. Dashboard evolve and new data is introduced, this may cause tab reordering. It would be good if you could build links like https://app.us.getport.io/serviceEntity?identifier=foobar&activeTab=runbooks rather than https://app.us.getport.io/serviceEntity?identifier=foobar&activeTab=2