add organization and product type articles

docs/content/asset_modelling/engagements_tests/OS__engagements.md

@@ -66,7 +66,7 @@ Alternatively, Engagements within a particular Product can be accessed from the
 
 Engagements sit below Products and above Tests in the object hierarchy. As such, access to a Product automatically grants access to all Engagements within that Product. Engagements do not have independent access control lists.
 
-## Engagement Lifecycle 
+## Working with Engagements
 
 ### Create Engagements 
 

docs/content/asset_modelling/engagements_tests/OS__products.md

@@ -91,7 +91,7 @@ Product views contain a variety of tables and charts to interpret a Product’s
 - **Notifications**
     - Toggles notifications on and off depending on specific events (e.g., an Engagement has been added or closed) 
 
-## Product Lifecycle 
+## Working with Products
 
 ### Create Products 
 

docs/content/asset_modelling/engagements_tests/OS__tests.md

@@ -104,7 +104,7 @@ The following settings are available within each Test view:
 - **View History**
     - Opens a history of edits made to the Test for tracking, reporting, and auditing purposes.
 
-## Test Lifecycle
+## Working with Tests
 
 ### Create Tests 
 

docs/content/asset_modelling/engagements_tests/OS_producttype.md

@@ -0,0 +1,135 @@
+---
+title: "Product Types"
+description: "Understanding Product Types in DefectDojo OS"
+audience: opensource
+weight: 1
+---
+**PRODUCT TYPES** → Products → Engagements → Tests → Findings
+
+## Overview 
+
+**Product Types** sit at the very top of DefectDojo’s product hierarchy. Product Types are distinct from the descending objects in the hierarchy—Products, Engagements, Tests, and Findings—because they are not technical scan targets, but rather serve primarily as organizational abstractions that compartmentalize your security efforts according to: 
+- Business domain
+- Development team
+- Security team
+- Software applications
+- Overarching product family
+- Customer or subsidiary
+- Reporting structure
+- etc. 
+
+The theme of the above examples exemplifies the essential utility of Product Types: they should generally represent stable, long-lived boundaries within your security program.
+
+## Product Type Data and Structure 
+
+As Product Types are not scanned directly, the only mandatory field required to create them is a name. Beyond that, they act as containers for Products and their descending Engagements, Tests, and Findings. 
+
+When creating a Product Type, consider how their structure will inform your reporting. Do you primarily need Product Types to represent the teams working on the projects (Products) that Product Types will contain? Or would Product Types better represent overarching projects that contain different iterations of the projects (Products) within it?
+
+If you have a single Product Type that contains all of the relevant information for a given business domain or development team, having that represented as a Product Type will facilitate smoother reporting, rather than having to pull together a report from various Products and Product Types. 
+
+If a particular software project has many distinct deployments or versions, it may be worth creating a single Product Type which covers the scope of the entire project and having each version exist as individual Products. In some workflows, Product Types may also be used to separate software lifecycle stages: one Product Type for “In Development,” one Product Type for “In Production,” etc.
+​
+Product Types can be used to determine access to subsidiaries, acquired companies, or other regulated business units for RBAC purposes. In complex businesses, where there are a lot of unique projects with different access rules, Product Types are particularly relevant.
+
+Ultimately, the decision of how to use Product Types and Products depends on how you best wish to reflect your unique organizational structure and the needs of your security team. 
+
+Below are some example structures to inform how you designate your objects as either Product Types or Products. 
+
+- **Product Type**: Payments Division
+    - Product: Payments API - Production
+    - Product: Payments API - Staging
+    - Product: Billing Worker
+
+- **Product Type**: Software Product A
+    - Product: Web Portal
+    - Product: Mobile Backend
+
+Additionally, the following is an illustrative guide as to whether a something is better represented by a Product Type or an Product: 
+
+| Product Types | Assets |
+|--------------|--------|
+| Business units | Individual applications |
+| Departments | Deployments/environments |
+| Security ownership domains | Infrastructure components |
+| Product families | Specific microservices |
+| Portfolio-level reporting | Scan targets |
+| Customers | Specific software versions |
+
+As noted, your structure may differ depending on your unique security needs.
+
+## Accessing Product Types 
+
+Product Types are accessible via the sidebar. The submenu also provides the option to create new Product Types.
+
+![image](images/PT_ss2.png)
+
+### Product Type View 
+
+A Product Type’s view contains a variety of tables and charts to interpret its status at a glance. This includes: 
+- **Description**
+- **Key/Critical Checkbox**
+    - Checking Critical or Key is used solely for filtering purposes 
+- **List of Products within the Product Type**
+- **Authorized Users** (DefectDojo Users)
+
+## Working with Product Types 
+
+### Create Product Types 
+
+There are two ways to create Product Types: 
+
+- From the **Add Product Type** option in the side menu
+- From the **Add Product Type** button at the top of the All Product Type list 
+
+### Edit Product Types 
+
+Product Types can be edited by clicking **Edit** from within the dropdown menu at the top right of the Description table in the Product Type’s view. The same menu can also be accessed by clicking the ⋮ kebab menu to the left of the Product Type in the All Product Type list.
+
+All ensuing fields that can be edited are also available when the Product Type is being created.
+
+### Delete Product Types 
+
+Deleting a Product Type can be performed by selecting **Delete Product Type** from the Product Type’s settings. 
+
+Because Product Types sit at the top of the hierarchy, deleting them removes all downstream security history, relationships, and child objects, such as: 
+- Any Products, Engagements, and Tests contained within the Product Type
+- All associated security history, including Findings and integrations
+- Any linked Jira Epics
+- All notes and file uploads associated with the Products, Engagements, and Tests within that Product Type
+
+Deleting a Product Type can’t be undone. If you would like to “decommission” a Product Type without deleting underlying data (for example, preserving legacy software testing records for audit purposes), you can change the Product Type’s name or add a Tag to indicate that it is in a deprecated state.
+
+## Product Types vs. Metadata
+
+Product Types are intended to represent structural ownership or reporting boundaries, rather than lightweight classifications. Attributes such as deployment status, internal labels, or temporary workflow states may be better represented through tags or metadata rather than separate Product Types.
+
+## Product Type Boundaries 
+
+Product Types establish both reporting and access boundaries within DefectDojo. Because integrations, RBAC permissions, ownership, metrics, and deduplication models frequently inherit Product Types’ structure, designing clear boundaries early helps avoid hierarchy sprawl and reporting fragmentation later.
+
+### Findings and Automation 
+
+Although integrations are typically configured on lower-level objects such as Product Types, Engagements, or Findings, Product Types still define the ownership, reporting, and access boundaries within which those integrations operate.
+
+Permissions cascade downward, meaning that access to a Product Type automatically grants access to all objects within that Product Type (e.g., Product Types, Engagements, Tests, and Findings). 
+
+The DefectDojo RBAC model can be used to gate human user access, but can also restrict API tokens’ access to particular Product Types.
+
+For more information on user roles, see our [Permissions](/admin/user_management/os__authorized_users/) article.
+
+### Ownership 
+
+As top-level objects, Product Types also imply ownership over the child objects within them. SLA tracking, remediation workflows, ticket routing, and general governance all flow more smoothly when Product Types have been set up to accurately reflect the individuals accountable for them.
+
+### Metrics/Reporting 
+
+Metrics dashboards, tiles and views can be filtered per Product Type, making them a critical component in how your security data is calculated, visualized, and ultimately exported. 
+
+For reporting purposes, it is generally easier to combine multiple Product Types into a single document than it is to subdivide a single Product Type into separate documents. Therefore, we recommend setting up Product Types at as granular a level as makes sense for your team’s reports. For example, there is no need to represent a large business division as a Product Type if you’re primarily going to be reporting to individual departments within that division.
+
+Effectively structuring your Product Types to reflect your reporting needs is critical to accurately assessing your security posture. For more information on Metrics, click [here](/metrics_reports/dashboards/introduction_dashboard/).
+
+### Deduplication 
+
+Deduplication in DefectDojo occurs at the Product level, and is not affected by the parent Product Type.

docs/content/asset_modelling/engagements_tests/PRO__assets.md

@@ -93,7 +93,7 @@ Asset views contain a variety of tables and charts to interpret an Asset’s sta
 - **All Engagements**
     - A list of Engagements contained within the Asset. 
 
-## Asset Lifecycle 
+## Working with Assets 
 
 ### Create Assets 
 

docs/content/asset_modelling/engagements_tests/PRO__engagements.md

@@ -66,7 +66,7 @@ Alternatively, Engagements within an Asset can be accessed in the window at the
 
 Engagements sit below Assets and above Tests in the object hierarchy. As such, access to an Asset automatically grants access to all Engagements within that Asset. Engagements do not have independent access control lists.
 
-## Engagement Lifecycle 
+## Working with Engagements
 
 ### Create Engagements 
 

docs/content/asset_modelling/engagements_tests/PRO__organizations.md

@@ -0,0 +1,139 @@
+---
+title: "Organizations"
+description: "Understanding Organizations in DefectDojo Pro"
+audience: pro
+weight: 1
+---
+**ORGANIZATIONS** → Assets → Engagements → Tests → Findings
+
+## Overview
+
+**Organizations** sit at the very top of DefectDojo’s product hierarchy. Organizations are distinct from the descending objects in the hierarchy—Assets, Engagements, Tests, and Findings—because they are not technical scan targets, but rather serve primarily as organizational abstractions that compartmentalize your security efforts according to: 
+- Business domain
+- Development team
+- Security team
+- Software applications
+- Overarching product family
+- Customer or subsidiary
+- Reporting structure
+- etc. 
+
+The theme of the above examples exemplifies the essential utility of Organizations: they should generally represent stable, long-lived boundaries within your security program.
+
+## Organization Data and Structure
+
+As Organizations are not scanned directly, the only mandatory field required to create them is a name. Beyond that, they act as containers for Assets and their descending Engagements, Tests, and Findings. 
+
+When creating an Organization, consider how their structure will inform your reporting. Do you primarily need Organizations to represent the teams working on the projects (Assets) that Organizations will contain? Or would Organizations better represent overarching projects that contain different iterations of the projects (Assets) within it?
+
+If you have a single Organization that contains all of the relevant information for a given business domain or development team, having that represented as an Organization will facilitate smoother reporting, rather than having to pull together a report from various Assets and Organizations. 
+
+If a particular software project has many distinct deployments or versions, it may be worth creating a single Organization which covers the scope of the entire project and having each version exist as individual Assets. In some workflows, Organizations may also be used to separate software lifecycle stages: one Organization for “In Development,” one Organization for “In Production,” etc.
+​
+Organizations can be used to determine access to subsidiaries, acquired companies, or other regulated business units for RBAC purposes. In complex businesses, where there are a lot of unique projects with different access rules, Organizations are particularly relevant.
+
+Ultimately, the decision of how to use Organizations and Assets depends on how you best wish to reflect your unique organizational structure and the needs of your security team. 
+
+Below are some example structures to inform how you designate your objects as either Organizations or Assets. 
+
+- **Organization**: Payments Division
+    - Asset: Payments API - Production
+    - Asset: Payments API - Staging
+    - Asset: Billing Worker
+
+- **Organization**: Software Product A
+    - Asset: Web Portal
+    - Asset: Mobile Backend
+
+Additionally, the following is an illustrative guide as to whether a something is better represented by an Organization or an Asset: 
+
+| Organizations | Assets |
+|--------------|--------|
+| Business units | Individual applications |
+| Departments | Deployments/environments |
+| Security ownership domains | Infrastructure components |
+| Product families | Specific microservices |
+| Portfolio-level reporting | Scan targets |
+| Customers | Specific software versions |
+
+As noted, your structure may differ depending on your unique security needs. 
+
+## Accessing Organizations
+
+Organizations are accessible via the sidebar. The submenu provides access to All Organizations as well as the option to create a new Organization.
+
+![image](images/org_ss1.png)
+
+## Organization View
+
+An Organization’s view contains a variety of tables and charts to interpret its status at a glance. This includes: 
+
+- **Description**
+- **Commerce** 
+    - Whether the Organization has been determined to be Critical or Key
+        - Checking Critical or Key is used solely for filtering purposes 
+- **Assigned Members** (DefectDojo Users)
+- **Assigned User Groups** 
+    - User groups that have been assigned to the Organization for permission control. More information about user groups can be found [here](/admin/user_management/create_user_group/). 
+- **List of Assets within the Organization**
+
+## Working with Organizations 
+
+### Create Organizations 
+
+There are two ways to create Organizations: 
+
+- From the **New Organization** option in the side menu
+- From the **New Organization** button at the top of the All Organizations list 
+
+### Edit Organizations 
+
+Organizations can be edited by clicking **Edit Organization** from within the gear menu at the top right of the Organization’s view. The same menu can also be accessed by clicking the ⋮ kebab menu to the left of the Organization in the All Organization view. 
+
+All ensuing fields that can be edited are also available when the Organization is being created.
+
+### Delete Organizations 
+
+Deleting an Organization can be performed by selecting **Delete Organization** from the Organization’s settings. 
+
+Because Organizations sit at the top of the hierarchy, deleting them removes all downstream security history, relationships, and child objects, such as: 
+- Any Assets, Engagements, and Tests contained within the Organization
+- All associated security history, including Findings and integrations
+- Any linked Jira Epics
+- All notes and file uploads associated with the Assets, Engagements, and Tests within that Organization
+
+Deleting an Organization can’t be undone. If you would like to “decommission” an organization without deleting underlying data (for example, preserving legacy software testing records for audit purposes), you can change the Organization’s name or add a Tag to indicate that it is in a deprecated state.
+
+## Organiations vs. Metadata 
+
+Organizations are intended to represent structural ownership or reporting boundaries, rather than lightweight classifications. Attributes such as deployment status, internal labels, or temporary workflow states may be better represented through tags or metadata rather than separate Organizations.
+
+## Organization Boundaries 
+
+Organizations establish both reporting and access boundaries within DefectDojo. Because integrations, RBAC permissions, ownership, metrics, and deduplication models frequently inherit Organizations’ structure, designing clear boundaries early helps avoid hierarchy sprawl and reporting fragmentation later.
+
+### Findings and Automation 
+
+Although integrations are typically configured on lower-level objects such as Assets, Engagements, or Findings, Organizations still define the ownership, reporting, and access boundaries within which those integrations operate.
+
+Permissions cascade downward, meaning that access to an Organization automatically grants access to all objects within that Organization (e.g., Assets, Engagements, Tests, and Findings). 
+
+The DefectDojo RBAC model can be used to gate human user access, but can also restrict API tokens’ access to particular Organizations.
+
+For more information on user roles, see our [Introduction To Permission Types](/admin/user_management/set_user_permissions/#introduction-to-permission-types) article.
+
+### Ownership
+
+As top-level objects, Organizations also imply ownership over the child objects within them. SLA tracking, remediation workflows, ticket routing, and general governance all flow more smoothly when Organizations have been set up to accurately reflect the individuals accountable for them.
+
+### Metrics/Reporting 
+
+Metrics dashboards, tiles and views can be filtered per Organization, making them a critical component in how your security data is calculated, visualized, and ultimately exported. 
+
+For reporting purposes, it is generally easier to combine multiple Organizations into a single document than it is to subdivide a single Organization into separate documents. Therefore, we recommend setting up Organizations at as granular a level as makes sense for your team’s reports. For example, there is no need to represent a large business division as an Organization if you’re primarily going to be reporting to individual departments within that division.
+
+Effectively structuring your Organizations to reflect your reporting needs is critical to accurately assessing your security posture. For more information on Metrics, click [here](/metrics_reports/pro_metrics/pro__overview/).
+
+### Deduplication
+
+Deduplication in DefectDojo occurs at the Asset level, and is not affected by the parent Organization.

docs/content/asset_modelling/engagements_tests/PRO__tests.md

@@ -104,7 +104,7 @@ Tests can be accessed from various sections of the DefectDojo UI.
 
 ![image](images/tests_ss16.png)
 
-## Test Lifecycle 
+## Working with Tests 
 
 ### Create Tests
 

docs/content/metrics_reports/pro_metrics/PRO__overview.md

@@ -6,11 +6,11 @@ weight: 2
 ---
 
 The DefectDojo Pro UI has various Metrics dashboards to help visualize your current security posture. Each dashboard allows stakeholders at different levels of the organization to make informed decisions without needing to interpret raw data or navigate individual Findings. These dashboards include:
-* [Executive Insights](#executive-insights)
-* [Priority Insights](#priority-insights)
-* [Program Insights](#program-insights)
-* [Remediation Insights](#remediation-insights)
-* [Tool Insights](#tool-insights)
+* [Executive Insights](/metrics_reports/pro_metrics/pro__executive_insights/#main-content)
+* [Priority Insights](/metrics_reports/pro_metrics/pro__priority_insights/#main-content)
+* [Program Insights](/metrics_reports/pro_metrics/pro__program_insights/#main-content)
+* [Remediation Insights](/metrics_reports/pro_metrics/pro__remediation_insights/#main-content)
+* [Tool Insights](/metrics_reports/pro_metrics/pro__tool_insights/#main-content)
 
 ![Metrics overview](images/metrics_image1.png)