Blog
/
/
Curate personalized experiences with folders
Product News
Product News

Curate personalized experiences with folders

Feb 12, 2024
Paz Hershberg
Paz Hershberg
Example H2
Example H3

‍Why We Built The Folders Feature

At Port, we believe in creating an internal developer portal that lets platform engineers design product-like experiences for developers and managers. Since no two organizations operate in the same way, we give engineering organizations the flexibility to make the portal their own. 

Our flexible data model enables you to customize the portal to fit your specific environment and the unique way your organization operates. Our RBAC framework allows you to define access and permissions ensuring a secure and relevant experience for each user, and our customizable dashboards and homepages are designed to fit the unique workflows, processes, and culture of your organization.These elements are just examples that illustrate how Port can be modeled to meet your stack, processes and culture.

Today, we're introducing a new capability to support our vision: Folders.
Folders allow you to customize the Port sidebar, grouping elements by use case, persona, team and more. By organizing your portal with folders, Port becomes a space that feels specifically designed for any workflow. We've added Folders to our roadmap, as a direct response to your feedback. We'll continue to work on Port based on what you tell us!

What Are Folders in Port?  

Folders in Port offer a practical way to manage your portal's content taking the point of view of a specific portal user. Inside a folder, platform engineers can include dashboards, catalogs, or additional sub-folders, up to three levels deep. This flexibility allows for a structured and clear organization of the portal's resources.

You also have the ability to set specific permissions for pages inside the folders. This can be done for both teams and individual users. By doing this, you create a user interface that is highly personalized. Once the sidebar is  decluttered, the portal is easier to navigate.

‍Organize Your Portal Using Folders

Take a 'portal as a product' approach when organizing your portal. By mapping out the teams, their specific processes, and their jobs-to-be-done, you can take a strategic approach to the portal development (as you would with any other customer-facing product.) Then, decide the high-level structure of the portal. You can choose from several options:

  1. Organize by Use Case: You might choose to structure the portal based on use cases, such as FinOps, Security, Incident Management, K8s etc. Security folders can contain, for instance, dashboards that provide high level statistics on the security posture of your organization, unified alert boards that show alerts from all your appsec tools, and catalog pages that show vulnerabilities or open security PRs. This structure ensures that the portal addresses specific operational requirements.
  2. Organize by Persona: The portal can also be organized according to personas such as developers, architects, security engineers, or SREs.
    The following pages can be found in an SRE folder: a unified alert board that shows alerts from your monitoring tools, an incident page that contains details about all open incidents with quick links to investigation, and a K8s catalog that shows how stable your K8s infrastructure is in terms of memory and CPU usage. You can also include a production readiness scorecard dashboard that reports on reliability.
    Through this approach, the portal is customized to the needs and workflows of each persona.
  3. Organize by Teams: The portal can also be organized by specific teams, particularly in large organizations that have distinct team structures and functions. A typical dev team folder will include a team dashboard with production metrics related to the services this team is responsible for. In addition, you can include the following catalog pages, filtered to show only items relevant to the team: services, packages, documentation, PRs...
    This approach allows the team to stay organized and quickly access the information they need.
Curate Personalized Experiences with Folders

After deciding on the structure, the next step is to determine access levels. Decide who needs access to what information. This step is crucial for maintaining security and relevance of the portal's content.

We recommend including in each folder at least one high-level dashboard that includes key visualizations for critical information and catalog pages that are filtered to display information relevant to that specific team or use case. 

Conclusion 

With folders, each team can leverage the portal to its full potential. Folders make the portal easier to navigate, increasing the user experience. By organizing the tools and information in the portal, teams can mirror how they work, creating a central point for their activities. The result is a more focused engineering organization that concentrates on the task at hand, instead of constantly searching for information.

Interested to dive more? Try it for yourself or check our live demo! 

{{cta}}

Book a demo right now to check out Port's developer portal yourself

Book a demo
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook
{{cyberark}}

Learning from CyberArk - building an internal developer platform in-house

Read more
{{dropdown}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start