Feature ideas

As admin users, we have full visibility on everything that's available in Port. We can already control what users see and interact with, but we cannot easily confirm if the changes we have made are correctly tailored to them. It would be very helpful to be able to preview the changes.

The SSO flows are a bit awkward since they have to be initiated by the IdP at the moment. Adding SCIM support would allow us to configure third-party Identity Providers such as Okta, Auth0, or Azure AD to provision users and groups in our Port accounts, allowing users to authenticate through Port rather than initiating login through the Identity Provider.

Sync groups and roles using the SCIM integration to ease groups management and overall portal permissions.

Currently admins can only restrict whether members can read a page, but not grant users access to update/create/delete pages. Granting members the ability to update pages will allow them to build custom views. https://docs.getport.io/customize-pages-dashboards-and-plugins/page/page-permissions/

Today you can add additional filters via JSON to any table, chart, etc using some of the intrinsic functions like: "getUserTeams()". With the ability to customize the user data-model (like a profile), it would be beneficial to access other user data properties to filter on that we added custom. Perhaps a new function like: getUserProperty("myCustomProp") to use in rules: { "property": "github_user_id" "operator": "=", "value": "getUserProperty('my_github_user_id')", }

Today, when adding a new user to Port, using an SSO provider / the User blueprint with a data source - they must be invited and can sign in to the portal once you add them. It would be helpful if you could have these users as inactive and not invited, so that we will be able to present users & teams as part of the company hierarchy, but before allowing them to enter the portal. This decouples a company engineer with a portal user, as they are not always the same. It's worth noting that "inactive" in this context doesn't mean a user that used to exist and is now deleted. One consideration might be to have the following states: Active (to represent users who are active and have access to the tool) Inactive (to represent users who are not active and don't have access to the tool) Not invited (to represent users who are active, but have not been invited to use the tool yet)

Currently, if team inheritance is enabled, setting $team through the UI or API is not allowed. It would be nice to enable 'Team inheritance' only if the $team value is not set explicitly during mapping.

It would be helpful to associate GitHub Team Members to the GitHub Teams themselves in Port, pulling in GitHub Users/Members as part of the Port Users. This mechanism could help drive the creation of GitHub Teams as Port Teams that indicate entity ownership and inheritance from the repo as well.

Currently in self service actions, emails are not sent to the array of approvers which is generated via dynamic permissions. The behavior for dynamic permission's approvers needs to match that of static permission's approvers where emails are sent.

Having users and teams represented as blueprints is surely a way forward to enable modeling an organizational structure of an enterprise in Port. Nonetheless, the current statuses (Invited and Active) are not enough. Namely, many users just need to be referenced in relationships, using a relation from some other blueprint to User, that are otherwise not actively using Port. Furthermore, for historical reasons, some users may be kept even though they had left the company long time ago. So, it would be good to introduce more statuses (like, Passive) that wouldn't be charged from licensing purposes. Such users would not be bidirectionally synced with the current internal list of users and teams. Invited users could be linked, but it is cumbersome to send invitations to users who wouldn't really require or able to log into Port. At the time of this writing, the ability to model users and teams as blueprints is in beta release. Relationships are a more powerful way to handle users than properties of type User. The latter allows non-existent users to be entered (via JSON editing mode), which is not the case with relationships. This is why it is important to be able to store inactive users, too. There are many use cases where knowing statuses of users is important. For example, counting the number of referenced users as mentors of a service doesn't provide a complete picture. If some of those users are not active, then the effective number of mentors is lower. Currently, there is no way to truly join data from different entity types, so handling users as entities is only the first step toward implementing more complex business rules in scorecards.