Feature ideas

GitHub Ocean always fetches full file content for the file kind, even when a mapping only needs metadata like path or existence. This causes HTTP 413 errors on large files, since the full content is pulled and batched regardless of what's actually mapped. Add an option to fetch file metadata without content, so kinds don't fail on large files when content was never needed. For example, detecting package manager files like package-lock.json or yarn.lock only needs the file to exist, not its content.

Today, there is a red badge icon that displays the number of notifications (max displayed is "9+") waiting on the user. In many cases, the notifications are indicating actions that haven't yet been approved or are stuck in progress. It can be a lot to find and clear these individually (and sometimes, you are an assigned approver, but don't want to approve or deny the action in that case, and so you actually cannot clear the notif at all until someone else marks it approved or denied). We request a "Clear All" button for the red notifications.

When developing custom UI plugins it would be helpful to be able to bind custom URL Query Parameters. Current State: Custom plugin urls are simple page endpoints and the plugin cannot add or retrieve query params Desired State: The plugin should provide access to an API for reading and writing query params from the URL. These could be used to set sub navigation, store state, or save filters or other low-risk data.

Users currently have no way to retry a workflow from a specific node. when an execution fails or times out, the only option is to rerun the entire workflow from the beginning. This forces unnecessary re-execution of steps that already completed successfully, which is especially painful in long-running or multi-step workflows. users should be able to trigger a rerun starting from any specific node in a past execution, regardless of why the execution stopped (timeout, error, manual cancellation, etc.).

Considering the size of our Org & the number of integrations we have with each data source, It would be really nice if we could have a cron like experience to schedule the integration/ingestion triggers.

Users added to a private page’s permissions currently need the page link to access it. The page does not automatically appear for them. The private pages should become visible to users/teams once access is granted.

We are attempting to build out a skill registry based on skills stored in one or more repos. (Specifically, we are looking to import skills via an Azure DevOps integration, following this model ). As a part of this, one of the current gaps is related to ingesting all related assets/references/scripts for a skill - the only solution seems to be some sort of follow-on process to parse the contents of those child folders for a given skill (like this documented upload process ). Note: This was split off from the " Enable appending to objects / arrays on ingestion " feature request, as that work only included the ability to allow for multi-source ingestion for arrays of numbers or strings (per Maya's comment there, the plan would be to support objects array too in the next phase of this feature). I believe that it would also be important in my use case to be able to properly maintain the array (e.g., if the references folder has 5 files, I would want all five items to be represented by an object in that array - but if if I remove two and add three, then I would want those six items to be represented in the array...without the two that were removed).

Current SCIM support in Port only handles user lifecycle (create, update, delete) and profile fields. It does not support SCIM group CRUD or “push groups” from the IdP. The SCIM token is scoped only for user operations (no get:groups), so Entra/Okta group provisioning fails with 403 “Insufficient scope (get:groups)”. Group/team memberships are only synced : When a SCIM user is created/updated, and When the user logs in to Port. This means customers cannot fully pre‑provision team memberships or enforce group‑based roles/automations before first login. Features requested here : SCIM group support : Support SCIM group CRUD (including secure get:groups) from IdPs like Entra ID and Okta. Pre‑provisioned team memberships : When a user is provisioned/updated via SCIM, Port should apply their IdP groups to Port teams without requiring login. Group‑based RBAC and automations : Allow Port roles and workflows to be driven directly from IdP groups as soon as SCIM provisioning runs. Config controls : Let admins choose which IdP groups SCIM manages and whether SCIM may create teams or only map to existing ones.

Teams building API-driven pipelines can read entity markdown from Port, but images uploaded through the markdown editor are stored on Port's private asset CDN and can only be downloaded with browser CloudFront signed cookies API tokens return 403. The workaround is to host images externally and insert URLs manually, but that forces a separate upload flow outside Port's markdown editor. Provide a way for automation to fetch images referenced in markdown content or example, an API endpoint that returns time-limited download URLs for Port-hosted assets, or org-level configuration to upload markdown images to customer-owned storage (S3/CDN).

Self-hosted Ocean teams need dedicated, rotatable credentials per integration, including for actions processing. Service Accounts support data sync today, but actions processing does not run when the Ocean pod uses Service Account runtime credentials. Ocean currently requires machine-level tokens for that path. First-class Service Account support for actions processing would let teams run integration actions without shared org credentials