Feature ideas

The Bedrock provider currently always routes requests to AWS's native Bedrock endpoints, with no way to point at a different host. Some organizations run an internal proxy or gateway in front of Bedrock's invoke API for network control, auditing, or centralized access management, and need requests to go through that proxy instead of directly to AWS. The underlying AI SDK (@ai-sdk/amazon-bedrock v4+, already in use by Port) natively supports a baseURL override alongside its existing credential options, so adding an optional baseUrl config field to Port's Bedrock provider would unblock proxy-fronted Bedrock deployments without changing the default AWS-direct behavior.

Please add support for Amazon Bedrock API keys as a native authentication method alongside the existing assume-role and static IAM access key options. AWS now supports service-scoped Bedrock API keys (both long-term and 30-day short-term). Allowing users to store a Bedrock API key as a Port secret and authenticate directly via the AWS_BEARER_TOKEN_BEDROCK mechanism would remove the need for cross-account roles or broad IAM keys. This significantly reduces the security blast radius and simplifies credential rotation.

We would like the ability to add in workflows to notify users with via email or using Ports internal notification system to send custom notifications such as failures or completions as well as links relating to it.

We want to have a subset of custom roles allocated to different developer teams to allow varying privileges around the Port application. currently it is Admin and Member and Moderator The Flow is that a Role can be created with fully customisable and granular permission sets managed by the customer.

Problem Port Workflow input nodes support Slack notifications natively ("target": "slack"), including in-Slack review/respond via the Port Slack app. The Terraform port_workflow resource still validates node.input.notifications.target as only email or webhook (documented on the registry; same gap in Pulumi). Customers who manage workflows in Terraform cannot declare the same Slack responder path they configure in the UI. Requested change Add slack to the allowed values for node.input.notifications.target on port_workflow (and keep schema/docs in sync). When target = "slack", no extra fields should be required beyond what the API/docs expect for Slack input-node notifications. Why it matters Parity between UI/API and IaC. Without it, teams fall back to email (and optional separate Slack posts) and lose the native in-Slack approve/respond UX for Terraform-managed workflows.

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

Hello, We would like a team approval notification, similar to the approval email, for every workflow or self-service action. Can you please prioritize its development in your team’s upcoming sprints? Thanks, Swathi.

The usage dashboard only shows daily login counts and each user's last login timestamp, so a user who authenticates and immediately leaves looks the same as one who works in the portal all day. Daily Active Users (DAU) and Weekly Active Users (WAU) can't be derived from what's exposed today. Without them, platform teams can't measure real adoption, spot inactive users or teams, or show the impact of a rollout. The ask is to provide DAU/WAU definition and data for the platform

Cannot share a link to sub tabs, like scorecards / or related entities, and today a shared link always opens on the default tab.

Add global filtering capabilities to the usage dashboard. Ability to filter by specific action types. Option to exclude internal team members from reports. Increase dashboard flexibility to allow deeper analysis, for example: Drilling down into usage metrics for specific newly developed building components. Measuring adoption and engagement per feature or initiative. Tracking the impact of newly launched capabilities over time. This would enable more accurate reporting, better adoption tracking, and clearer ROI visibility for both customers and internal stakeholders.