diff --git a/docs/apis/migration-azure.md b/docs/apis/migration-azure.md index 3dddc87b8..f0cd4a72b 100644 --- a/docs/apis/migration-azure.md +++ b/docs/apis/migration-azure.md @@ -98,6 +98,11 @@ You can also provide your own Azure Blob Storage Containers. Provide the URI wit ## Azure Queues +> [!IMPORTANT] +> Use [GetMigrationJobProgress API](migration-job-progress-api-reference.md) to retrieve migration job status. +> +> Provisioning Azure Queues for migration job status tracking is no longer required. Deprecation is planned for the second half of 2026. Until then, Azure Queues will remain available for status retrieval. + SharePoint-provided Azure Queues have no extra cost to the customer. Provision the queue with `ProvisionMigrationQueue` method, without the need to manually set up in Azure admin console. Migration API provisions Azure Queues in the same datacenter of the SharePoint instance. diff --git a/docs/declarative-customization/list-form-conditional-show-hide.md b/docs/declarative-customization/list-form-conditional-show-hide.md index 2df4a772d..1d4afe455 100644 --- a/docs/declarative-customization/list-form-conditional-show-hide.md +++ b/docs/declarative-customization/list-form-conditional-show-hide.md @@ -1,7 +1,7 @@ --- title: Show or hide columns in a list form description: Customize which columns to show or hide using a conditional formula in the list form by constructing a simple formula that are equations performing conditional checks on values in a SharePoint list or library. -ms.date: 04/03/2025 +ms.date: 07/28/2025 ms.localizationpriority: high --- @@ -58,7 +58,7 @@ For example, the following formula checks if the value for the *Category* column Returning _true_ shows the column on the form while returning _false_ hides the column. -The column is represented by specifying the **internal name** of the field surrounded by square brackets and preceded by a dollar sign: `[$InternalName]`. For example, to get the value of a field with an internal name of "ProductName", use `[$ProductName]`. +The column is represented by specifying the **internal name** of the field preceded by a dollar sign and surrounded by square brackets: `[$InternalName]`. For example, to get the value of a field with an internal name of "ProductName", use `[$ProductName]`. #### Unsupported column types in conditional formulas diff --git a/docs/sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md b/docs/sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md index e86590567..dbe7c5240 100644 --- a/docs/sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md +++ b/docs/sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md @@ -1,7 +1,7 @@ --- title: Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks description: Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks. -ms.date: 03/15/2024 +ms.date: 08/06/2025 ms.localizationpriority: high ms.service: sharepoint --- @@ -1031,7 +1031,7 @@ In the body of the request you need to specify the information about the resourc ``` > [!NOTE] -> In order to register a subscription, you will need permissions specific for the target of the subscription. You can find the list of permissions required for every supported target entity by reading the document [Create subscription - Permissions](https://learn.microsoft.com/en-us/graph/api/subscription-post-subscriptions?view=graph-rest-1.0&tabs=http#permissions). +> In order to register a subscription, you will need permissions specific for the target of the subscription. You can find the list of permissions required for every supported target entity by reading the document [Create subscription - Permissions](/graph/api/subscription-post-subscriptions?view=graph-rest-1.0&tabs=http#permissions&preserve-view=true). The JSON body of the request specifies the *changeType*, which can be any of the following values: @@ -1043,7 +1043,7 @@ For SharePoint Online lists, the value *updated* is the only supported for the * Then, it specifies the *notificationUrl* that is the URL of the endpoint that will receive the change notifications. It must be an endpoint published over HTTPS. The *resource* property defines the target resource to monitor for notifications. -In the above sample you can see a resource of type SharePoint Online list, where you need to specify the Microsoft Graph *{site-id}* and *{list-id}*. The *expirationDateTime* defines how long the subscription will last, and needs to adhere to the supported expiration limites defined in the table [Maximum length of subscription per resource type](https://learn.microsoft.com/en-us/graph/api/resources/subscription?view=graph-rest-1.0#maximum-length-of-subscription-per-resource-type). For a SharePoint Online list the expiration time can be up to 30 days. +In the above sample you can see a resource of type SharePoint Online list, where you need to specify the Microsoft Graph *{site-id}* and *{list-id}*. The *expirationDateTime* defines how long the subscription will last, and needs to adhere to the supported expiration limites defined in the table [Maximum length of subscription per resource type](/graph/api/resources/subscription?view=graph-rest-1.0#maximum-length-of-subscription-per-resource-type&preserve-view=true). For a SharePoint Online list the expiration time can be up to 30 days. The *clientState* is a required string that allows your notification endpoint to validate the requests coming from Microsoft Graph. It can be a string no longer than 128 characters. @@ -1200,5 +1200,5 @@ You can find additional information about this topic reading the following docum * [Overview of SharePoint webhooks](../apis/webhooks/overview-sharepoint-webhooks.md) * [Get started with SharePoint webhooks](../apis/webhooks/get-started-webhooks.md) * [SharePoint webhooks sample reference implementation](../apis/webhooks/webhooks-reference-implementation.md) -* [SharePoint list webhooks](../apis/webhooks/lists/overview-sharepoint-list-webhooks) -* [Use the Microsoft Graph API to get change notifications](/graph/api/resources/webhooks) \ No newline at end of file +* [SharePoint list webhooks](../apis/webhooks/lists/overview-sharepoint-list-webhooks.md) +* [Use the Microsoft Graph API to get change notifications](/graph/api/resources/change-notifications-api-overview) diff --git a/docs/sp-add-ins/add-ins-and-azure-acs-retirements-faq.md b/docs/sp-add-ins/add-ins-and-azure-acs-retirements-faq.md index 376b97027..3668cd5e5 100644 --- a/docs/sp-add-ins/add-ins-and-azure-acs-retirements-faq.md +++ b/docs/sp-add-ins/add-ins-and-azure-acs-retirements-faq.md @@ -56,7 +56,7 @@ Yes, you can still read and update user profiles without Azure ACS. When you con ## Will remote event receivers also be retired? -Yes, remote event receivers are part of this retirement. Remote event receivers have a dependency on Azure ACS, and will stop working when Azure ACS is turned off. Although remote event receivers can still be programmatically added once Azure ACS has fully retired in April 2026, the events won't fire anymore. The recommended path forward is to use [SharePoint Online Webhooks](../apis/webhooks/overview-sharepoint-webhooks.md). More information on how to replace remote event receivers with webhooks can be found in the [Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks](../sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md) article. The article shows how to use the SharePoint REST API to add the webhooks, but you may prefer to use Microsoft Graph [change notifications](/graph/webhooks) to add a [subscription for a SharePoint List](/graph/api/resources/subscription). +Yes, remote event receivers are part of this retirement. Remote event receivers have a dependency on Azure ACS, and will stop working when Azure ACS is turned off. Although remote event receivers can still be programmatically added once Azure ACS has fully retired in April 2026, the events won't fire anymore. The recommended path forward is to use [SharePoint Online Webhooks](../apis/webhooks/overview-sharepoint-webhooks.md). More information on how to replace remote event receivers with webhooks can be found in the [Transform SharePoint Add-in model Remote Event Receivers to SharePoint Online Webhooks](../sp-add-ins-modernize/from-remote-event-receivers-to-webhooks.md) article. The article shows how to use the SharePoint REST API to add the webhooks, but you may prefer to use Microsoft Graph [change notifications](/graph/change-notifications-overview) to add a [subscription for a SharePoint List](/graph/api/resources/subscription). As webhooks are asynchronous by definition, synchronous events that allow an app to block or cancel a SharePoint action are no longer possible. If event blocking is being used to prevent accidental data updates/deletes by unauthorized users, then possible workarounds are securing the protected files/folders so they cannot be updated/deleted anymore, or by moving this type of data to a hidden library. In general, moving from synchronous to asynchronous events will require updating your application logic.