Feature ideas

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.

We'd like to be able to Install a Port Teams Bot to our Microsoft 365 environment such that the bot can be authorised to communicate with members and channels in selected Teams Teams. This could then be used as the backend in Self Service Actions to deliver messages to Teams or Users. For example the recent Announcement feature could be connected to this proposed bot meaning the setup time to use that feature would be measured in minutes. Currently we've got to consider building our own backend service to handle the event from Port and figure out how to deliver into Teams. NOTE: Microsoft are end of life'ing the simpler WebHook method of posting to channels and pushing people towards building Bots and PowerActions... Not an ideal approach from a starting from zero context. The vendor DX has produced their own Teams Bot to facilitate messaging users in Teams. As the customer configuring that capability it was very simple and straight forward. I think Port could build a bridge here too!

The following resource kinds are not supported by the out-of-the-box Linear Ocean integration. Each gap blocks a specific use case in Port: User — Without this, issues cannot be contextualized for the logged-in user. "Plan My Day" and any person-centric dashboard are blocked. Project — Without this, feature-level progress tracking is not possible in Port. Cycle — Without this, sprint-level context is missing. Teams using weekly cycles (e.g. Platform team) have no visibility into current/upcoming sprints. Initiative — Without this, the roadmap/OKR layer is not visible in Port. Team membership gap (related): The team kind currently does not include team.members, even though team.members is available in the Linear GraphQL API. Without team membership data, it is not possible to contextualize issues for a logged-in user based on their team(s) — even if the User kind were added. Additional request: Out-of-the-box support for multiple Linear workspaces under a single integration instance.

Using AWS Private Link / VPC Peering, allow the ability to connected your LLM provider - where all AI invocations route through it (Port Assistant, AI Workflow nodes, MCP)

Ability to view org chart. Current relations view is alright, but an org chart is hierarchical & org hierarchy is better visualised slightly differently You can model organizational hierarchy by defining self-referencing blueprint relations (e.g., a team with a parentTeam relation) and visualize them via the catalog or custom dashboard widgets, but a specialized tree-structured org chart view is not possible

We need the ability to set a default landing page per organization so that when users log in, they are automatically directed to a specific page — in our case, the "Plan My Day" dashboard. Current behavior: Users always land on their last visited page New users land on a generic page with no guidance Admins have no control over what page users see first Why this matters: We've built a "Plan My Day" dashboard that consolidates everything a developer needs — tasks, incidents, deployments, and priorities — in one place. If users land elsewhere, they miss it. New users who land on a generic page don't know where to start. A defined landing page improves onboarding and drives adoption of the portal. Developers shouldn't have to navigate to the right page every day. The landing page should surface what matters immediately. As admins, we should be able to define what users see first — similar to how tools like Notion, Linear, and Jira allow a default home view. Currently, each user lands wherever they last left off, creating an inconsistent experience across the team. Requested feature: A per-organization setting in Organization Settings that allows admins to configure a default landing page URL. When a user logs in (or opens Port fresh), they should be directed to that page instead of their last visited page.

Port AI enforces a hard 50-iteration cap on tool calls across all AI surfaces, including AI nodes in workflows, AI agents, and any other AI-powered interactions. For orgs on BYOLLM, where Port has no cost exposure, this cap functions as an arbitrary constraint rather than a meaningful guardrail, blocking legitimate high-context use cases like PR review agents that need to explore a larger number of files to produce safe, accurate output. When the cap is hit, execution fails. Proposed solution: Expose the tool-call iteration limit as a configurable setting in org AI settings. Keep 50 as the default and hard cap for orgs on the Port-managed AI provider; allow orgs on BYOLLM to raise or remove the cap at their discretion.

The Relations Graph currently renders connections between entities and blueprints without showing relation labels (e.g. Contains, Deploys to, Authenticates via) alongside the directional arrow. Users who need to understand not just that two nodes are connected but how, the semantics and direction, have no way to read this from the graph without clicking into individual entities.

The current layout places blueprint groups that have no relations to the rest of the graph directly in the middle of connected subgraphs, making complex data models harder to read. Users are forced to manually drag disconnected components out of the way each session, with no persistence. Automatically detecting and rendering disconnected components as spatially isolated clusters would dramatically improve readability of large or multi-domain data models.

Enterprise customers need a configurable inactivity timeout to meet OWASP-aligned security requirements. Automatically log users out after x number of minutesof inactivity. Detect frontend activity such as mouse movement, clicks, scrolling, and keyboard input. Configure the timeout at the company level, initially through Support.