Update to 2026-11 version

docs/add-functionality/add-functionality.md

@@ -45,8 +45,8 @@ Once you have embedded a dashboard, you can use helper methods in the Embedding
 
 If you plan to use Embedding SDK on a web page on a different domain from your Strategy environment, please also meet the following requirements. More information in
 
-1. [Enable Cross-Origin Resource Sharing (CORS)](../config.md)
-1. [Allow SameSite cookies](../config.md#allow-samesite-cookies)
+1. [Enable Cross-Origin Resource Sharing (CORS)](../configure-library-server/enable-cors.md)
+1. [Allow SameSite cookies](../configure-library-server/enable-cors.md#allow-samesite-cookies)
 
 If you plan to use Embedding SDK on the same domain as your Strategy, the above changes are not required.
 

docs/configure-library-server/client-telemetry.md

@@ -0,0 +1,62 @@
+---
+title: Track embedded usage with client telemetry
+description: Enable client telemetry on the Library server so that usage of your embedded dashboards and widgets is recorded in Platform Analytics, separate from standard Library usage.
+---
+
+<Available since="Strategy ONE November 2026"/>
+
+Client telemetry records what end users do inside embedded pages — dashboards, documents, reports, and visualizations — and sends the records to Platform Analytics. This allows you to measure adoption and engagement of your embedded analytics separately from standard Library usage. Both embedding surfaces are supported: the iframe-based Embedding SDK (`microstrategy.embeddingContexts`) and the Native Embedding SDK (`microstrategy.embeddingComponent`).
+
+Telemetry is disabled for embedded sessions until it is enabled on the Library server. No property or code change is required in your embedding application: the SDKs read the server configuration automatically.
+
+## How it works
+
+When an end user interacts with an embedded page, the Embedding SDK builds a telemetry record and hands it to the Platform Analytics telemetry pipeline. Each record identifies:
+
+- The embedding surface, through the `embed_mode_id` dimension: `1` for the iframe-based Embedding SDK and `2` for the Native Embedding SDK. Standard Library sessions are not tagged as embedded, so embedded usage can be filtered and compared in Platform Analytics.
+- The embedding context, through `embed_context_uri`: the URL of your embedding page, without the query string. For iframe embedding, the Embedding SDK passes the host page's URL to the embedded page automatically.
+- The target of the interaction: the project, the dashboard, and, for interactions on a specific visualization, the visualization name and id.
+
+The device and environment (browser, operating system, Library version) are recorded once per session.
+
+Record delivery is resilient: telemetry failures never block or break the embedding, and a record that fails to send immediately is buffered locally and retried.
+
+## Prerequisites
+
+1. Platform Analytics is deployed in your environment, and client telemetry is enabled for the project that contains the embedded content. Records are only sent for projects with client telemetry enabled in the Platform Analytics telemetry settings.
+1. Enable telemetry for embedded sessions on the Library server. Navigate to `MicroStrategyLibrary/WEB-INF/classes/config/configOverride.properties` and add the following line, or replace it if already present:
+
+   `features.telemetry.embedEnabled=true`
+
+1. Restart your Library web application hosted on the application server.
+
+Optionally, you can control how records are delivered with `features.telemetry.immediateSend` in the same properties file. When it is `true` (the default), each record is sent to Platform Analytics as soon as it completes; when it is `false`, records are buffered in the browser's IndexedDB and flushed when the user returns.
+
+## What is recorded
+
+### In iframe-embedded pages
+
+The following user interactions are recorded in pages embedded with the Embedding SDK:
+
+- Dashboard manipulations, such as filtering, sorting, drilling, and page switching, including the name and id of the visualization the user acted on.
+- Link clicks: URL links, links to reports or documents, contextual links to the same or another dashboard, and links to a dashboard in another project.
+- Toolbar and sharing actions: exporting to PDF, CSV, Excel, Google Sheets, or plain text, subscribing, applying a bookmark, answering prompts, copying a share link, posting a comment, viewing the data behind a visualization, and resetting the dashboard.
+
+### In natively embedded dashboards and visualizations
+
+For dashboards and visualizations embedded with the Native Embedding SDK:
+
+- Manipulations: sorting (including clearing a sort), drilling, keep-only and exclude, selectors, panel selectors, and showing totals, with the visualization name and id. When several dashboards are embedded on one page, each dashboard instance carries its own stable action id, so their records can be told apart.
+- Link clicks, with the same link types as iframe embedding.
+
+Some interactions are intentionally not recorded in native embedding: page load and render events, and filtering applied through the SDK's `applyFilter` or `applyManipulations` APIs by the embedding application itself. Only direct end-user interactions are counted, so programmatic changes from the host application are not double-counted as usage.
+
+## View the data in Platform Analytics
+
+The records are written to the Platform Analytics client telemetry data. In the Client Telemetry reports, you can:
+
+- Filter usage by the `embed_mode_id` dimension to separate iframe-embedded usage, natively embedded usage, and standard Library usage.
+- Break usage down by the embedding page (`embed_context_uri`), by dashboard, or by visualization.
+- Review the interaction types, such as filter, sort, drill, export, and link clicks, with the recorded request duration of each manipulation.
+
+Since the host page URL is recorded without its query string, personal data that may be carried in query parameters is not collected.

docs/configure-library-server/configure-library-server.md

@@ -0,0 +1,18 @@
+---
+title: Configure Library Server for embedding
+description: The Library server supports additional configuration for embedding, including enabling Cross-Origin Resource Sharing (CORS), hiding irrelevant allowed origins in the Content-Security-Policy response header, and sending client telemetry for embedded sessions to Platform Analytics.
+---
+
+To embed Strategy content into your web application, the Library server can be configured to support cross-domain embedding, protect the domains configured in your security settings, and report usage of embedded content to Platform Analytics.
+
+- [Enable Cross-Origin Resource Sharing (CORS)](./enable-cors.md)
+
+  If you use the Embedding SDK on a different domain from your Strategy environment, enable CORS on the Library server and allow SameSite cookies, so that the embedded pages can communicate with the Library server across domains.
+
+- [Hide irrelevant allowed origins in the CSP response header](./hide-irrelevant-allowed-origins.md)
+
+  When multiple allowed origins are configured on the Library server, enable the `features.hideIrrelevantAllowOrigins` feature flag so that the `Content-Security-Policy` response header only exposes the allowed origins relevant to the current requester, and use wildcard allowed origins to cover subdomains.
+
+- [Track embedded usage with client telemetry](./client-telemetry.md)
+
+  Enable the `features.telemetry.embedEnabled` feature flag so that usage of your embedded dashboards and widgets is recorded in Platform Analytics, separate from standard Library usage.

docs/configure-library-server/enable-cors.md

@@ -0,0 +1,99 @@
+---
+title: Enable Cross-Origin Resource Sharing (CORS)
+description: If you plan to use Embedding SDK on a different domain from your Strategy environment, please enable Cross-Origin Resource Sharing (CORS) and allow SameSite cookies.
+---
+
+If you plan to use Embedding SDK on a different domain from your Strategy environment, please also meet the following requirements.
+
+## Enable Cross-Origin Resource Sharing (CORS)
+
+Cross-Origin Resource Sharing (CORS) provides a way for a web application running in one origin (domain, protocol, and port) to access selected resources from a server in a different origin. A cross-origin HTTP request uses additional HTTP headers to tell the browser to let the web application share resources. For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts. This means that when a web application requests HTTP resources from a different origin, the response from the other origin must include the right CORS headers.
+
+:::note
+
+Chrome Web Browser version 80 and above introduces new changes which may impact embedding. For more information, see [KB484005: Chrome v80 Cookie Behavior and the Impact on Strategy Deployments](https://community.strategy.com/article/Chrome-v80-Cookie-Behavior-and-the-impact-on-MicroStrategy-Deployments).
+
+:::
+
+To enable CORS for the REST Server:
+
+1. Open the Library Admin page. Your URL should be similar to the following:
+
+   `https://<host_name>:<port>/MicroStrategyLibrary/admin`
+
+1. Navigate to **Library Server -> Security Settings**.
+1. Choose the appropriate setting for **Allow Library embedding in other sites** to reconfigure CORS.
+
+   ![Library Admin CORS Setting](../images/LibraryAdmin_CORSsetting.png)
+
+Using the Library Admin page is the easiest way to enable CORS for the REST Server, but you can also configure CORS manually.
+
+1. Navigate to `MicroStrategyLibrary/WEB-INF/classes/config/configOverride.properties`.
+1. Edit the `configOverride.properties` file in a text editor.
+1. Add the following lines, or replace them if already present:
+
+   `auth.cors.origins=http://example.com:port`
+
+   `security.allowedOrigins=http://example.com:port`
+
+1. Restart your Library web application hosted on the application server.
+
+Alternatively, you can also configure this in Workstation by [editing the properties of the environment](https://www2.microstrategy.com/producthelp/Current/Workstation/WebHelp/Lang_1033/Content/library_admin_settings.htm#View).
+
+## Allow SameSite cookies
+
+Google Chrome (version 80+) and Microsoft Edge (version 86+) introduced new changes that may impact embedding.
+
+For Embedding SDK to function as expected in a 3rd-party context, it is required to explicitly label session cookies with `SameSite=None; Secure`.
+
+### For MicroStrategy 2021 Update 6 or after
+
+Starting in MicroStrategy 2021 Update 6, you can manage SameSite Cookies for Library in Workstation, by following the steps in [this document](https://www2.microstrategy.com/producthelp/Current/Workstation/WebHelp/Lang_1033/Content/config_samesite_cookies.htm).
+
+![SameSite Cookie](../images/SameSiteCookie.png)
+
+### For MicroStrategy 2021 Update 5 or before
+
+If you are using MicroStrategy 2021 Update 5 or before, make the following changes on your server instance.
+
+1. If `context.xml` doesn't already exist in the following folder location, create it: `[Tomcat Folder]\webapps\MicroStrategyLibrary\META-INF\context.xml`. Add the following to `context.xml`:
+
+   ```xml
+   <Context>
+      <CookieProcessor sameSiteCookies="None"/>
+   </Context>
+   ```
+
+1. In `[Tomcat Folder]\webapps\MicroStrategyLibrary\WEB-INF\web.xml`, change `sameSite` param-value blow to `NONE` to permit embedding.
+
+   ```xml
+   <!-- ... -->
+   <filter>
+   <filter-name>cookieProcessorFilter</filter-name>
+   <filter-class>com.microstrategy.web.filter.CookieProcessorFilter</filter-class>
+   <init-param>
+   <param-name>sameSite</param-name>
+   <param-value>NONE</param-value>
+   </init-param>
+   </filter>
+   <!-- ... -->
+   ```
+
+1. Ensure your Tomcat is configured to support HTTPS.
+1. Restart Tomcat.
+
+For more information, see [Chrome v80 Cookie Behavior and the Impact on Strategy Deployments](https://community.microstrategy.com/s/article/Chrome-v80-Cookie-Behavior-and-the-impact-on-Strategy-Deployments?language=en_US).
+
+## The Partitioned Cookie Change
+
+Before MicroStrategy ONE June 2024, when the Library server and the client website are in different domains, the Embedding SDK requires third-party cookies to be allowed to work correctly. In the past, Chrome's default setting was only "Block third-party cookies in Incognito mode", so the customer can use Embedding SDK without changing the Chrome settings.
+
+![The default Chrome preference](../images/chrome-preference.png)
+
+However, third-party cookies are on their way out. Google is expected to stop the use of third-party cookies by [2025 Q2](https://developers.google.com/privacy-sandbox/3pcd). At that time, Chrome will block third-party cookies by default, and the customer can't use Embedding SDK unless he changes the Chrome preference to enable the 3rd party cookies manually.
+
+To avoid the changes of third-party cookies default setting breaking the Embedding SDK workflow, we adopt [CHIPS](https://developer.chrome.com/docs/privacy-sandbox/chips/)(Cookies Having Independent Partitioned State) solution to put the Library server's cookie into partitioned storage. The user needs to enable the partitioned cookie in the Library settings to use this solution:
+
+![The partitioned cookie setting](../images/partitioned-cookie.png)
+
+After this change, the customer can use most of the Embedding SDK functionalities even if 3rd party cookies are blocked in the Chrome preference. But for the SAML/OIDC login, the old workflow changes, and the user need to do more to make it work. The details can be seen in [SAML or OIDC authentication after MicroStrategy ONE June 2024](../support-for-different-authentication-environments/authentication-saml.md#for-microstrategy-one-june-2024-or-after).