Merge branch 'main' of https://github.com/microsoftgraph/microsoft-graph-docs

Author: OWinfreyATL

.github/prompts/author-api-docs.prompt.md

@@ -30,7 +30,18 @@ Once the author responds, follow the appropriate workflow below.
 
 ## Common Setup and Processes
 
-The following sections describe setup steps and processes that are common to both documentation scenarios. Reference these sections as needed during your workflow.
+The following sections describe setup steps and processes that are common to all documentation scenarios. Reference these sections as needed during your workflow.
+
+### Source Priority for Conflict Resolution
+
+When information conflicts between sources, use this priority order:
+
+1. **Documentation Plan** (highest authority — defines scope and intent of the changes)
+2. **API.md** (authoritative for API behavior and descriptions)
+3. **Doc stubs** (structural template — use for metadata, types, and autogenerated content)
+4. **Existing documentation** (reference for patterns and consistency)
+
+If a conflict is significant, flag it to the author in the final summary but follow the priority order above to proceed without blocking.
 
 ### Common Setup: Verify Working Branch
 
@@ -63,13 +74,13 @@ How to determine values to replace TODO placeholders in the following front matt
 Before beginning any documentation process, instruct the author to add all required files to the `temp-docstubs` folder in this workspace:
 
 **For Scenario 1 (Fresh APIs / beta changes):**
-- Autogenerated doc stubs (*.md files from Graph Studio)
+- Autogenerated doc stubs (*.md files)
 - API.md file describing the capabilities being added/changed
 - Autogenerated changelog file (changelog_*.json)
 
 **For Scenario 2 (Promotion from beta to v1.0):**
 - Documentation Plan documenting what is being promoted
-- **Optional:**Autogenerated doc stubs (*.md files from Graph Studio for v1.0)
+- **Optional:** Autogenerated doc stubs (*.md files for v1.0)
 - Autogenerated changelog file (changelog_*.json)
 
 **Important notes about temp-docstubs:**
@@ -113,7 +124,7 @@ After authoring documentation, update the appropriate changelog file in the `cha
 - **IMPORTANT:** A changelog record is NOT just the ChangeList array. A complete changelog record consists of:
   - `ChangeList` array (containing individual change items)
   - `Id` (unique GUID for this set of changes)
-  - `Cloud` (e.g., "Prod")
+  - `Cloud` (always "Prod"; older records may say "prd" but use "Prod" for new entries)
   - `Version` (e.g., "beta" or "v1.0")
   - `CreatedDateTime` (ISO 8601/RFC 3339 DateTime with fractional seconds and Z suffix)
   - `WorkloadArea` (e.g., "Security")
@@ -396,9 +407,19 @@ Fully qualify any type (including enum types) that is defined in a subnamespace
 
 **Beta disclaimer:**
 - All beta documentation must include the beta disclaimer immediately after the namespace declaration
-- Use the standard boilerplate text for beta disclaimers
+- Use the following include statement for beta disclaimers:
+  ```
+  [!INCLUDE [beta-disclaimer](../../includes/beta-disclaimer.md)]
+  ```
 - Remove beta disclaimer when promoting to v1.0
 
+**National cloud include statement:**
+- API method files in beta include an autogenerated national cloud support statement immediately before the `## Permissions` header. Example include statement for all clouds support:
+  ```
+  [!INCLUDE [national-cloud-support](../../includes/all-clouds.md)]
+  ```
+- Remove this include statement when promoting to v1.0
+
 ---
 
 ## Scenario 1: Author fresh APIs / fresh API changes to beta
@@ -408,7 +429,7 @@ Fully qualify any type (including enum types) that is defined in a subnamespace
 **See [Common Setup: temp-docstubs Folder](#common-setup-temp-docstubs-folder)** for instructions on setting up the temp-docstubs folder.
 
 For this scenario, the author should add these files to `temp-docstubs`:
-- Autogenerated doc stubs (*.md files from Graph Studio)
+- Autogenerated doc stubs (*.md files)
 - API.md file describing the capabilities being added/changed
 - Autogenerated changelog file (changelog_*.json)
 
@@ -520,7 +541,7 @@ After gathering all inputs, analyze the Documentation Plan to understand the ful
 
 For this scenario, the author should add these files to `temp-docstubs`:
 - Documentation Plan documenting what is being promoted
-- **Optional:**Autogenerated doc stubs (*.md files from Graph Studio for v1.0)
+- **Optional:** Autogenerated doc stubs (*.md files for v1.0)
 - Autogenerated changelog file (changelog_*.json)
 
 #### Input 1: Documentation Plan
@@ -1000,7 +1021,7 @@ Based on the documentation plan, the work will fall into two categories:
 - **Target locations:**
   - API method files go in `${workspaceFolder}/api-reference/beta/api/` or `${workspaceFolder}/api-reference/v1.0/api/`
   - Resource files go in `${workspaceFolder}/api-reference/beta/resources/` or `${workspaceFolder}/api-reference/v1.0/resources/`
-  - Permissions files go in `${workspaceFolder}/api-reference/beta/includes/permissions/` or `${workspaceFolder}/api-reference/v1.0/includespermissions/`
+  - Permissions files go in `${workspaceFolder}/api-reference/beta/includes/permissions/` or `${workspaceFolder}/api-reference/v1.0/includes/permissions/`
 
 ### 2. Updates to existing reference files
 - **Source:** Existing files in the microsoft-graph-docs repository
@@ -1151,7 +1172,7 @@ When authoring or updating documentation, ensure compliance with these standards
 - CRUD operations: List, Create, Get, Update, Delete
 - Actions/functions: Use name without binding parameter
 - For update operations, verify the return type: If the response is a `204` response code, the return type column should say "None"; it should not list a resource type
--Root resources might not have any properties or methods; the sections should still be present with "None." as the content
+- Root resources might not have any properties or methods; the sections should still be present with "None." as the content
 - Document any navigation properties in the Relationships section
 
 **Properties:**
@@ -1249,7 +1270,11 @@ Before working on any file, apply these rules to both resource and API files:
 4. **Methods table:**
    - **For Entity Type resources:**
      - Only Entity Type resources might have a Methods table, but not always
-     - {to be filled later}
+     - Consult the Documentation Plan and API.md to determine which operations (List, Create, Get, Update, Delete, actions, functions) are supported for this resource
+     - Add only the supported methods to the Methods table using the format from the autogenerated doc stub
+     - Use succinct method names (avoid repeating the resource name); for CRUD operations use: List, Create, Get, Update, Delete
+     - For actions and functions, use a friendly operation name, not the title of the API operation file. For example, instead of "ediscoveryHoldPolicy: retryPolicy", use "Retry hold policy". Avoid duplicating the resource name in the method name
+     - If no methods are supported for this resource, use "None." as the content of the Methods section
    - **For Complex Type resources:**
      - These have the text "None." instead of a Methods table
 
@@ -1352,10 +1377,12 @@ Before working on any file, apply these rules to both resource and API files:
      - **Note:** Type references in tables should follow [Reference Standards: Namespace Qualification](#reference-standards-namespace-qualification)
 
 8. **Response section:**
-   - Leave it mostly unchanged
+   - Preserve the autogenerated response structure, status codes, and return types; do not rewrite or reformat these elements
+   - Only modify the Response section to:
+     - Add error-related information or special response-related notes documented in the API.md or Documentation Plan
+     - Fix inaccuracies if the return type or status code doesn't match the API.md
    - **Note:** Return types should follow [Reference Standards: Namespace Qualification](#reference-standards-namespace-qualification)
-   - Call out any special error-related information or response-related information
-     - Example: An API that returns multiple object types might return an `@odata.type` property for each object to help differentiate each object type in the collection
+   - Example: An API that returns multiple object types might return an `@odata.type` property for each object to help differentiate each object type in the collection
 
 9. **Examples section:**
    - Follow HTTP-only example formatting (see [Common Process: Handling Code Snippets in Examples](#common-process-handling-code-snippets-in-examples))
@@ -1617,29 +1644,6 @@ Create a dedicated topic for the enumeration. This option is rarely applicable.
    - Update introductory text (for Options 2 & 3) to list the new members that require the header
    - Update inline descriptions to include the new members in the header note
 
-   - Identify what needs to be changed based on the API changes summary
-   - Review API.md file(s) for additional context
-   - Check for consistency with related files
-
-2. **Make targeted changes:**
-   - Update only what's necessary according to the changes summary
-   - Preserve existing formatting and structure
-   - Maintain compliance with standards
-   - Use information from API.md file(s) to inform updates
-
-3. **Validate the changes:**
-   - Check the **Problems** window for markdown lint errors and correct them
-   - Verify all links point to existing files
-   - Ensure examples use pseudo-values not data types
-   - Confirm all required sections are present and in correct order
-   - If there are multiple blank lines in a row, replace them with a single blank line
-
-4. **Review with user:**
-   - Summarize the changes made (both new files and updates)
-   - List all files that were copied or modified
-   - Confirm the updates meet their requirements
-   - Address any additional feedback
-
 ## Execution approach
 
 1. **Parse the Documentation Plan:**
@@ -1955,7 +1959,7 @@ Before completing Scenario 4 tasks, verify:
 - [ ] No markdown lint errors
 - [ ] Changelog, What's new, and TOC mapping updated only if appropriate
 - [ ] Validation completed (see [Common Process: Validation](#common-process-validation))
-- [ ] Summary of changes provided to author
+- [ ] Documentation summary provided to author
 
 ---
 

api-reference/beta/api/cloudpcexternalpartner-configureagent.md

@@ -0,0 +1,104 @@
+---
+title: "cloudPcExternalPartner: configureAgent"
+description: "Configure the agent setting of the cloudPcExternalPartner."
+author: "XunZhangSZ"
+ms.date: 01/21/2026
+ms.localizationpriority: medium
+ms.subservice: "cloud-pc"
+doc_type: apiPageType
+---
+
+# cloudPcExternalPartner: configureAgent
+
+Namespace: microsoft.graph
+
+[!INCLUDE [beta-disclaimer](../../includes/beta-disclaimer.md)]
+
+Configure the [cloudPcExternalPartnerAgentSetting](../resources/cloudpcexternalpartneragentsetting.md) of the [cloudPcExternalPartner](../resources/cloudpcexternalpartner.md) object. This setting is used for RMM partner agent installation. RMM partners must contact the Microsoft team to complete onboarding and add the agent URL prefix to the allow list before using this API. If `autoDeploymentEnabled` is enabled, the new provisioned Cloud PC is triggered agent deployment automatically. Currently supports only Windows 365 Business Cloud PC.
+
+[!INCLUDE [national-cloud-support](../../includes/global-only.md)]
+
+## Permissions
+
+Choose the permission or permissions marked as least privileged for this API. Use a higher privileged permission or permissions [only if your app requires it](/graph/permissions-overview#best-practices-for-using-microsoft-graph-permissions). For details about delegated and application permissions, see [Permission types](/graph/permissions-overview#permission-types). To learn more about these permissions, see the [permissions reference](/graph/permissions-reference).
+
+<!-- {
+  "blockType": "permissions",
+  "name": "cloudpcexternalpartner-configureagent-permissions"
+}
+-->
+[!INCLUDE [permissions-table](../includes/permissions/cloudpcexternalpartner-configureagent-permissions.md)]
+
+## HTTP request
+
+<!-- {
+  "blockType": "ignored"
+}
+-->
+``` http
+POST /deviceManagement/virtualEndpoint/externalPartners/{cloudPcExternalPartnerId}/configureAgent
+```
+
+## Request headers
+
+|Name|Description|
+|:---|:---|
+|Authorization|Bearer {token}. Required. Learn more about [authentication and authorization](/graph/auth/auth-concepts).|
+|Content-Type|application/json. Required.|
+
+## Request body
+
+In the request body, supply a JSON representation of the parameters.
+
+The following table lists the parameters that are required when you call this action.
+
+|Parameter|Type|Description|
+|:---|:---|:---|
+|agentSetting|[cloudPcExternalPartnerAgentSetting](../resources/cloudpcexternalpartneragentsetting.md)|The agent settings associated with the external partner.|
+
+
+## Response
+
+If successful, this action returns a `204 No Content` response code.
+
+## Examples
+
+### Request
+
+The following example shows a request.
+<!-- {
+  "blockType": "request",
+  "name": "cloudpcexternalpartnerthis.configureagent"
+}
+-->
+``` http
+POST https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/externalPartners/b3548526-e615-3785-3118-be70b3968ec5/configureAgent
+Content-Type: application/json
+
+{
+  "agentSetting": {
+      "agentUrl": "https://rmmExample.microsoft.com/agent/rmmExampleAgent.msi",
+      "agentSha256": "EC6AF1EA0367D16DDE6639A89A080A524CEBC4D4BEDFE00ED0CAC4B865A918D8",
+      "installParameters": [
+          "/quiet",
+          "/norestart",
+          "TOKENID=e69c1577-d465-4e57-af33-0ddea43feeb1"
+      ],
+      "autoDeploymentEnabled": true
+  }
+}
+```
+
+### Response
+
+The following example shows the response.
+>**Note:** The response object shown here might be shortened for readability.
+<!-- {
+  "blockType": "response",
+  "truncated": true
+}
+-->
+``` http
+HTTP/1.1 204 No Content
+```
+

api-reference/beta/api/cloudpcexternalpartner-deployagent.md

@@ -0,0 +1,106 @@
+---
+title: "cloudPcExternalPartner: deployAgent"
+description: "Trigger agent deployment for a set of Windows 365 Cloud PCs that provisioned."
+author: "XunZhangSZ"
+ms.date: 01/21/2026
+ms.localizationpriority: medium
+ms.subservice: "cloud-pc"
+doc_type: apiPageType
+---
+
+# cloudPcExternalPartner: deployAgent
+
+Namespace: microsoft.graph
+
+[!INCLUDE [beta-disclaimer](../../includes/beta-disclaimer.md)]
+
+Trigger agent deployment for a set of Windows 365 Cloud PCs that are provisioned, and return an activity ID. This API is supported when the connection is enabled and the agent setting is configured. Currently, only support Windows 365 business Cloud PC.
+
+[!INCLUDE [national-cloud-support](../../includes/global-only.md)]
+
+## Permissions
+
+Choose the permission or permissions marked as least privileged for this API. Use a higher privileged permission or permissions [only if your app requires it](/graph/permissions-overview#best-practices-for-using-microsoft-graph-permissions). For details about delegated and application permissions, see [Permission types](/graph/permissions-overview#permission-types). To learn more about these permissions, see the [permissions reference](/graph/permissions-reference).
+
+<!-- {
+  "blockType": "permissions",
+  "name": "cloudpcexternalpartner-deployagent-permissions"
+}
+-->
+[!INCLUDE [permissions-table](../includes/permissions/cloudpcexternalpartner-deployagent-permissions.md)]
+
+## HTTP request
+
+<!-- {
+  "blockType": "ignored"
+}
+-->
+``` http
+POST /deviceManagement/virtualEndpoint/externalPartners/{cloudPcExternalPartnerId}/deployAgent
+```
+
+## Request headers
+
+|Name|Description|
+|:---|:---|
+|Authorization|Bearer {token}. Required. Learn more about [authentication and authorization](/graph/auth/auth-concepts).|
+|Content-Type|application/json. Required.|
+
+## Request body
+
+In the request body, supply a JSON representation of the parameters.
+
+The following table lists the parameters that are required when you call this action.
+
+|Parameter|Type|Description|
+|:---|:---|:---|
+|cloudPcIds|String collection|The selected Cloud PC ID list to be deployed. The min count is 1 and the max count is 50.|
+
+
+
+## Response
+
+If successful, this action returns a `200 OK` response code and a String in the response body.
+
+## Examples
+
+### Request
+
+The following example shows a request.
+<!-- {
+  "blockType": "request",
+  "name": "cloudpcexternalpartnerthis.deployagent"
+}
+-->
+``` http
+POST https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/externalPartners/b3548526-e615-3785-3118-be70b3968ec5/deployAgent
+Content-Type: application/json
+
+{
+  "cloudPcIds": [
+    "30d0e128-de93-41dc-89ec-33d84bb662a0", 
+    "7c82a3e3-9459-44e4-94d9-b92f93bf78dd"
+  ]
+}
+```
+
+
+### Response
+
+The following example shows the response.
+>**Note:** The response object shown here might be shortened for readability.
+<!-- {
+  "blockType": "response",
+  "truncated": true,
+  "@odata.type": "Edm.String"
+}
+-->
+``` http
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "value": "9adc7d86-6411-407e-b936-abfa0470dccf"
+}
+```
+