Feature ideas

Port currently has no built-in mechanism to back up or restore deleted catalog entities. When entities are deleted whether by user error or integration reconciliation manually curated metadata (such as team ownership, custom properties, and relations) is lost. Reconstructing this data requires writing custom scripts to parse the audit log, which is slow, manual, and constrained by the 90-day retention window. Requested Solution Soft Delete / Trash Bin: Allow deleted entities to be held in a recoverable state before permanent deletion. Direct Restore: Provide an automated mechanism to restore deleted entities and their historical properties/relations directly from audit logs or backups. Native Entity Backups: Allow users to schedule or trigger backups and restores of catalog data directly from within Port. Impact Eliminates the need for custom recovery scripts and significantly reduces recovery time during an incident.

Provide audit log functionality for pages so that we can track which users create/edit/delete things like dashboards.

Currently Port does not have the ability to export action runs via the UI, only the API. It would be beneficial if an export button was added to the Runs History page similar to normal catalog pages.

Support streaming audit logs to a customer-managed data warehouse bucket, enabling customers to monitor Port activity in near real time.

Often I want to see when and by what a specific field was changed on an entity. The problem is we have some entities with hundreds or thousands of edits in the log. Tracking down the specific edit that changed that field last can be difficult. It would be really nice to see a breakdown of each of the edits to the entity that involved that specific field.

In addition to the general action runs audit log, a specific audit log for each action will be added to the "audit log" page Each action log will display as columns the general details of each run (ID, status, start, end) and also the specific inputs of the action inputted by the user who executed it.

Some customers would like the option to automatically report Port's information to an external SIEM system for security concern. https://www.ibm.com/topics/siem#:~:text=Security%20information%20and%20event%20management,chance%20to%20disrupt%20business%20operations . First and most important are the changes of Port's audit log

Make it possible to see login attempts (both successful and unsuccessful) in an organization's audit log

We now have multiple locations where we are using the API to update specific blueprints. Having all changes to blueprints made through the API under "Rest API" is too vague for us to know where specifically the change came from. It would be nice if we could include a name of the source in our blueprint change payload and then be able to see this reflect in the audit logs. For example: I change blueprint Service with a python script called "service_ changer.py " using a POST in the script - I can also pass into the body of the POST "updatedByAlias":"service_ changer.py " And then later, I can filter the audit log by "updatedByAlias":"service_ changer.py " to see all changes made through that specific script.

Problem When a self-service action creates another entity, the audit log shows the entity as being created by Port automation. While the action run itself contains the triggering user’s information, that context is not surfaced in the audit log. This makes it difficult to: Trace ownership and accountability Understand who initiated changes when reviewing audit logs investigate issues without jumping between audit logs and action runs Current behavior Audit log entry: Type “Port automation” Triggering user is only visible in the self-service action run details Expected behavior Audit logs should display the user who triggered the self-service action as the creator of any entities created by that action (or at least include them as additional context, e.g. “Created by Port automation (triggered by @username)”).