Feature ideas

We want to be able to monitor whether a flag can be archived/deleted, and for that we need information on a flag's dependent flags (as in, is this flag a prerequisite to other flags). We want to be able to ingest a flag's dependent flags (and not prerequisites, which we already get through the Flag resource). Launchdarkly has a List dependent feature flags( https://launchdarkly.com/docs/api/feature-flags-beta/get-dependent-flags ) endpoint which answer our needs, together with everything we can pull from the other entities. It does not, however, have a Flag Lifecycle Stage endpoint which would be enough, and thus we do need to ingest the dependent feature flags for each flag.

Some data models include blueprints such as CI/CD jobs or deployments. These blueprints usually get filled with high number of entities, but the entities in these blueprints become stale and lose relevancy very quickly. With this feature, users will be able to configure custom retention for specific blueprints, giving them the option to automatically delete old entities once the number of entities for the blueprint passes X entities, or if an entity was updated more than 1 week/month/year ago

Port auto-generates team identifiers from display names using a snake_case transformation. However, the /teams API endpoint currently uses the team name/title as its path parameter and does not return the team identifier in its response. At the same time, the $team meta property on the Entity API requires the team identifier, not the name. There is no straightforward API method to retrieve the corresponding Port-team-generated identifier, forcing reverse-engineering to generate the wanted identifier.

Bar charts should support a timeline on the X-axis. Today, bar charts are mainly used for grouping properties, but it would be very valuable to also use them to present data over time. Currently, the only way to visualize this is with a line chart, which isn’t always ideal or intuitive, especially when there are gaps in the data, making the chart harder to interpret. Screenshots show the expected bar charts behavior vs the line chart behavior that is supported today.

We want to add support refreshing the repository entity on push events, likely by triggering a repository refresh via the GitHub REST API when a push is received.

I would like more control over what permissions admins can have within the IDP. For example, some admins can only edit automations, and webhooks, some admins can only edit the data model, or no admins can generate a new org token. This enables following of least privilege principle. The "superadmin" role could do anything. Usecase: Our team is building a pipeline to version control data model changes as JSON, it would be nice if no one can update the data model through UI in our production environment anymore and they can only do it through the pipeline.

We currently do not have a scalable, built-in way to monitor the health of integrations, automations, and self-service actions, to be proactively notified when failures occur. At the moment, detecting failures in automations or self-service actions requires creating separate webhook automations for each SSA. As adoption grows, this approach becomes difficult to maintain, does not scale well, and introduces additional operational overhead. We are looking for a native solution that enables centralized and reliable monitoring and notifications for these components, without requiring us to implement and maintain custom monitoring infrastructure on top of Port’s API.

Currently, the message sender only supports slack. Some organizations use Microsoft teams, which means they cannot create notifications for their teams.

At the moment you cannot run additional filters on calculation property. This makes creating widgets or charts impossible for those properties.

Today, when updating new objects / arrays of entities the new value overrides the old one. With this feature it will be possible to append values to these properties. Example of Tags property with type of array: Current state: "Tags" : ["tag1"] Ingesting a new tag using the API: "tag2" New state: "Tags": ["tag1", "tag2"]