> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Application Management
> Learn how to create and manage RUM applications in Flashduty, including app creation, configuration, and permission management
## Overview
A RUM application is a container for frontend performance monitoring data, used to collect, store, and analyze real user experience data from frontend applications. An application represents a monitored frontend project, which can be a website, mobile app, or single-page application.
We recommend creating RUM applications based on business systems or applications, such as: official website, e-commerce store, admin dashboard, etc.
Each application has its own unique `applicationId` and `clientToken`, used to identify data sources and ensure data security. After the application is created, you need to integrate the SDK into your frontend code to start data collection and monitoring.
## Application Permissions
To meet the data security requirements of different business scenarios, RUM applications provide flexible access level settings:
| Access Level | Visibility | Applicable Scenarios |
| ------------ | -------------------------------------------------------------------- | ----------------------------- |
| **Public** | Visible to all users in the account, can view data and handle Issues | General business applications |
| **Private** | Only visible to creator, account administrator, and owner account | Sensitive business data |
In private applications, if other members need to view content, they can be temporarily authorized to access it by sharing the incident link.
## Create Application
You can quickly create an application through the RUM product guide page:
Select the frontend technology type corresponding to the application, currently supporting **JavaScript (JS), Android, iOS, HarmonyOS, Flutter, WeChat Mini Program, Electron, and React Native**.
Specify the management team for this application.
Team members have full operational permissions for this application, non-team members only have read-only access to the configuration of this application.
By default, automatic collection of user geo-location data is enabled. To disable automatic collection of client IP or geo-location data, turn off the geo-information collection switch.
See [Data Collection](/en/rum/others/data-collection).
By default, alert notifications are automatically enabled to facilitate timely handling of errors.
See [Issue Alerts](/en/rum/error-tracking/issue-alerts).
## SDK Configuration
You can modify parameters and preview the initialization code in real-time in **Application Configuration > SDK Configuration** to quickly integrate the SDK.
The console provides detailed integration guides for each platform:
* **JavaScript (Web)**: After configuring parameters like service name, preview the `flashcatRum.init()` initialization code in real-time
* **Android**: Shows complete integration steps including adding Gradle dependencies (`cloud.flashcat:dd-sdk-android-core` and `cloud.flashcat:dd-sdk-android-rum`), initializing the SDK in `Application.onCreate()` with RUM enabled, and optional WebView tracking integration
* **iOS**: Shows complete integration steps including adding Swift Package Manager dependency (`fc-sdk-ios`, from version 0.6.0), initializing the SDK in `AppDelegate.didFinishLaunchingWithOptions` with RUM enabled, and optional WebView tracking integration
* **Flutter**: The Flutter SDK wraps the Android/iOS native SDKs, so one integration monitors both platforms. See [Flutter SDK Integration](/en/rum/sdk/flutter/sdk-integration)
* **WeChat Mini Program**: Fill in `env`, `service`, `version`, and `sessionSampleRate` in the form, and the `flashcatRum.init()` snippet built on `@flashcatcloud/miniprogram-rum` is generated and previewed in real time (see "WeChat Mini Program SDK Configuration Assistant" below)
* **Electron**: Provides a step-by-step integration guide — install `@flashcatcloud/electron-sdk` in the main process and complete initialization inside `app.whenReady()` (this must finish before any window is created; with the wrong ordering the SDK reports no error but collects no data). To capture page views, user actions, network requests, and JS errors inside your windows, optionally integrate `@flashcatcloud/browser-rum` in the renderer process, whose data is handed to the main process over an IPC bridge for unified reporting. When bundling the main process with Vite / webpack / esbuild, you can also add the corresponding plugin to keep the SDK's runtime dependencies. See [Electron SDK Integration](/en/rum/sdk/electron/sdk-integration)
* **React Native**: Provides a four-step integration guide — install `@flashcatcloud/mobile-react-native` plus the view-tracking package matching your navigation library (`@flashcatcloud/mobile-react-navigation` or `@flashcatcloud/mobile-react-native-navigation`) and run `pod install`; wrap the Metro config with `withDatadogMetroConfig` so release bundles and their sourcemaps carry a Debug ID; initialize the SDK as early as possible at the app entry (`serviceName` is required, otherwise Android and iOS split into two services); start automatic view tracking once the navigation container is ready. See [React Native SDK Integration](/en/rum/sdk/react-native/sdk-integration)
Each platform's SDK configuration page automatically fills in the current application's `applicationId` and `clientToken`, so you can copy the code directly into your project.
Modifying SDK configuration in application management will not take effect in real-time on integrated clients. All configuration changes need to be updated in your frontend code and redeployed to take effect.
### Service Definition
A service is an independent, deployable code repository that maps to a set of pages.
If your application is built as a whole, your RUM application only needs one service name.
```javascript theme={null}
flashcatRum.init({
applicationId: 'YOUR_APP_ID',
clientToken: 'YOUR_CLIENT_TOKEN',
service: 'my-web-app' // Single service name
});
```
If your browser application is built from multiple independent repositories, set different service names for different modules.
```javascript theme={null}
// Main application
flashcatRum.init({
service: 'main-app'
});
// Sub-application A
flashcatRum.init({
service: 'module-a'
});
```
### WeChat Mini Program SDK Configuration Assistant
When the application type is **WeChat Mini Program**, **Application Configuration > SDK Configuration** displays a dedicated Mini Program integration wizard: fill in the form on the left and a ready-to-copy initialization snippet is generated on the right in real time.
#### Form Fields
| Field | Description | Validation | Default |
| ------------------- | ---------------------------------------------------- | ------------------------------------------------ | ------- |
| `env` | Environment variable, e.g. `prod`, `dev` | Letters, digits, underscore only; up to 24 chars | — |
| `service` | Service name; all events default to this tag | Letters, digits, underscore only; up to 24 chars | — |
| `version` | Version number, useful for filtering during analysis | Letters, digits, `.` only; up to 24 chars | `1.0.0` |
| `sessionSampleRate` | Session sample rate (percentage) | Integer in range `0–100` | `10` |
No save action is needed — the preview snippet updates as you type. `applicationId` and `clientToken` are filled in automatically by the system; you do not need to set them by hand.
#### Two-Step Integration
Install the SDK in your Mini Program project and run the npm build through WeChat DevTools:
```bash theme={null}
npm install @flashcatcloud/miniprogram-rum
```
Use the copy button at the top-right of the right-hand code block, then paste the generated snippet into your Mini Program's `app.js`:
```typescript theme={null}
import { flashcatRum } from '@flashcatcloud/miniprogram-rum';
flashcatRum.init({
applicationId: "",
clientToken: "",
service: "",
env: "",
version: "1.0.0",
sessionSampleRate: 10
});
```
For the full SDK capabilities, collection toggles, and event reporting model, see [WeChat Mini Program SDK Integration](/en/rum/sdk/wechat-miniprogram/sdk-integration).
## Link Integration
Link Integration lets you associate RUM events with external systems, such as distributed tracing platforms, log search, object storage that stores crash log packages, or internal troubleshooting systems. After you configure links, RUM generates jump links from the event type and event context and shows them as **Related Links** in event details.
Link Integration is available from the **Link Integration** tab on the application details page and applies to every application type. Members with the **RUM Application Update** permission can add, edit, enable, disable, or delete link configurations.
### Built-in Tracing
The built-in Tracing card is the default Link Integration entry. It links the `trace_id` on resource events to your backend tracing system.
In the **Link Integration** tab, find the **Tracing** card and enter the jump link for your tracing system. You can use the `${trace_id}` variable in the link. RUM replaces it with the actual Trace ID from the resource event when it displays the link.
For example: `https://your-tracing-system.com/trace/${trace_id}`
After you save the jump link, turn on the **Tracing** switch. The switch cannot be enabled until a jump link is configured.
Built-in Tracing only matches resource events, and it appears only when the event contains `trace_id`. The jump link must start with `http://` or `https://`.
### Add External Links
Besides built-in Tracing, you can add custom external links for different event types.
In the **Link Integration** tab, select **Add external link**, then enter the link name and the jump link.
Choose the event types where this link should appear. The supported types are **Crash, Error, View, Action, Resource, and Session**.
A crash is an error event: selecting **Error** matches both regular errors and crashes, while selecting **Crash** matches only crash events.
Insert variables in the **Jump link**, such as `${session_id}`, `${error_id}`, or `${trace_id}`. The page previews the final URL with sample values so you can verify that the template matches your external system's query format.
| Setting | Description | Rule |
| ---------------------- | --------------------------------------------------------- | --------------------------------------- |
| Link name | External system name shown in RUM event details | Required |
| Applicable event types | Controls which RUM events show the link | Select at least one event type |
| Jump link | External system URL that can include `${variable}` tokens | Must start with `http://` or `https://` |
| Per-link switch | Controls whether this external link is active | Disabled links are not shown |
### Available Variables
Link Integration extracts variables from the current event context and substitutes them into the URL template.
| Variable | Description | Common Event Scope |
| ------------------- | -------------------------------------------- | ---------------------------------------------------------- |
| `${session_id}` | Session ID | Session, View, Action, Error, Resource |
| `${view_id}` | View ID | View, Action, Error, Resource |
| `${action_id}` | Action ID | Action, Error, Resource |
| `${error_id}` | Error ID | Error, Crash |
| `${resource_id}` | Resource ID | Resource |
| `${trace_id}` | Trace ID | Resource, built-in Tracing |
| `${application_id}` | RUM application ID | All events |
| `${service}` | Service name | Events that collect `service` |
| `${version}` | Version | Events that collect `version` |
| `${env}` | Environment | Events that collect `env` |
| `${usr_id}` | User ID | Events that collect user information |
| `${usr_name}` | User name | Events that collect user information |
| `${usr_email}` | User email | Events that collect user information |
| `${start_time}` | Start time of the current event detail query | Explorer event details, Error Tracking issue error samples |
| `${end_time}` | End time of the current event detail query | Explorer event details, Error Tracking issue error samples |
Not every variable resolves on every event type. The editor validates availability against the event types you select: variables that cannot resolve under the current event types appear in the variable list as **dashed grey** chips, and hovering them shows which event types cannot resolve them.
| Variable | Session | View | Action | Error/Crash | Resource |
| --------------------------------------------------- | ------- | ---- | ------ | ----------- | -------- |
| `${session_id}` | ✓ | ✓ | ✓ | ✓ | ✓ |
| `${view_id}` | ✗ | ✓ | ✓ | ✓ | ✓ |
| `${action_id}` | ✗ | ✗ | ✓ | ✓ | ✓ |
| `${error_id}` | ✗ | ✗ | ✗ | ✓ | ✗ |
| `${resource_id}` | ✗ | ✗ | ✗ | ✗ | ✓ |
| `${trace_id}` | ✗ | ✗ | ✗ | ✗ | ✓ |
| `${usr_id}`, `${usr_name}`, `${usr_email}` | ✓ | ✓ | ✓ | ✓ | ✓ |
| `${service}`, `${version}`, `${env}` | ✓ | ✓ | ✓ | ✓ | ✓ |
| `${application_id}`, `${start_time}`, `${end_time}` | ✓ | ✓ | ✓ | ✓ | ✓ |
Availability is judged by whether the event type's table carries the field, not by whether a particular event happens to have a value: available only means the event type can resolve a value, never that every event does. Crashes are error events, so they share the error column.
If the template uses a variable that cannot resolve under the current event types, the editor shows an inline warning below the input: when the variable appears in a **query parameter**, the whole parameter is dropped when the link is generated; when it appears in the **path**, the literal `${variable}` text is kept. The sample preview (sample data) omits the sample values of unavailable variables, so the preview matches what production actually resolves.
Legacy configurations that select the **All** event type only guarantee `${session_id}` among the ID variables (the "all" scope is the intersection of every event table's columns). Prefer concrete event types so the editor can validate availability accurately.
Put optional variables in query parameters, for example `https://logs.example.com/search?session=${session_id}&error=${error_id}`. If a query parameter only contains a missing variable, RUM omits that parameter when generating the link. Missing variables in the URL path stay as the original `${variable}` text.
### View Related Links
When an event matches an enabled link configuration, you can open the external system from these locations:
* **RUM Explorer event details**: the **Related Links** dropdown appears in the top-right corner for event details such as Session, View, Action, Error, and Resource
* **Error event details**: matching related links appear as embedded cards in the details area, with copy and open actions
* **Issue error samples**: matching related links appear below the error sample, so you can jump from an Issue directly to logs, tracing, or another troubleshooting system
## Privacy Settings
Privacy settings allow you to control the scope of user privacy data collected by the RUM SDK, meeting data compliance requirements for different regions.
| Setting | Description | Associated Fields |
| ---------------------------- | ------------------------------------------------------------------------------------------ | -------------------------------------------- |
| **Geo-location Information** | Controls whether to collect user country, province, city, and other geographic information | `@geo_country`, `@geo_province`, `@geo_city` |
| **IP Address** | Controls whether to collect user IPv4 and IPv6 addresses | `@geo_ip_v4`, `@geo_ip_v6` |
After disabling geo-location or IP address collection, the related filter and analysis dimensions will no longer be available. Please adjust carefully based on your business requirements and compliance needs.
## Remote Configuration
The **Remote Configuration** tab lets you adjust collection and privacy parameters online, without code changes or a new release. When enabled, the configuration on this page overrides SDK initialization settings. When disabled, clients fall back to their SDK initialization settings and data collection continues uninterrupted.
* Remote Configuration is currently available for **Browser**, **iOS** and **WeChat Mini Program** applications. Other platform types will be enabled as their SDKs ship support.
* On SaaS the feature is rolled out account by account. If the **Remote Configuration** tab is not visible on the application detail page, contact support to enable it. On private deployments it is available by default.
### Configuration values
| Field | Values | Description |
| ------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Session sample rate** | Integer 0–100 (%) | Percentage of sessions collected. Leave it empty to skip delivering this field; clients keep the value set at SDK initialization |
| **Session replay sample rate** | Integer 0–100 (%) | Percentage of sessions recorded by Session Replay. If empty, the SDK setting applies |
| **Trace sample rate** | Integer 0–100 (%) | A second session-level sampling pass within already-collected sessions, deciding which sessions inject trace headers into eligible requests; the outcome is consistent within one session. Overall trace coverage is roughly *session sample rate × trace sample rate*. If empty, the SDK setting applies |
| **Replay privacy level** | `mask` / `mask-user-input` / `allow` | Default masking of page content in Session Replay: `mask` obscures text and hides input values; `mask-user-input` keeps page text and hides only what users typed; `allow` records the page as it is. Loosening the level starts collecting content that was not collected before, and replays already uploaded cannot be retroactively masked. The console asks you to confirm again before publishing |
| **Custom configuration keys** | Key–value pairs typed as string / number / boolean / JSON | Delivered to clients together with the remote configuration and read by your application code; the platform does not interpret them. Up to 5 keys; each key name is at most 64 bytes (counted in UTF-8, not characters), each value at most 4 KB and nesting at most 3 levels (objects and arrays each count one level), and all custom entries together at most 16 KB |
iOS and WeChat Mini Program applications also show the **Remote Configuration** tab, but their SDKs read only the **session sample rate** and **custom configuration keys** (neither platform has Session Replay; the other values are neither delivered nor effective). Every SDK has to opt in with `remoteConfigurationEnabled: true` at initialization (off by default; an application that has not opted in never requests the configuration). On iOS this requires SDK 0.6.0 or later, see [iOS SDK Advanced Configuration](/en/rum/sdk/ios/advanced-config#remote-configuration).
Custom entries are delivered to clients and may be readable by end users. Never put secrets, access tokens, or personally sensitive information in them.
### Conditional rules
Conditional rules are a protocol-reserved capability that the current console version does not yet let you edit: there is no rule editor on the page, and when you save a configuration the rules already stored on the server are passed through untouched — saving never clears them. Rule editing will open up in a later version.
For reference, the protocol semantics: besides the default values, a configuration can deliver different values to different clients based on conditions —
* Match conditions support the `env`, `app_version`, and `sdk` dimensions, ANDed with exact comparison; a dimension the SDK does not report can never match. Each match value is at most 256 bytes.
* Rules are evaluated top-down and the **first fully matching rule wins**; its overrides are merged on top of the defaults, and fields the rule does not set keep the default values.
* Each application supports at most 20 rules.
### Publishing and activation
* Before publishing, the page shows a per-field diff against the live configuration and lets you inspect the raw JSON. You can optionally fill in a **change note** (at most 255 characters, e.g. "lower the sample rate during the sale event"), which is stored on the version and shown in the change history. Publishing creates a new version.
* Activation is fixed to **next new session**: sessions already running are unaffected, and new sessions gradually pick up the configuration — clients that support remote configuration usually finish switching within about 4 hours after a publish.
* **Immediate activation** (the client ends the running session as soon as the new configuration arrives and starts a fresh one under it) is a protocol-reserved capability that the current console version does not offer; it will open up in a later version. For urgent situations — stopping an over-collection flood or ramping collection up right away — call the SDK's `stopSession()` to end the current session so the configuration takes effect with the next one as soon as possible.
* The protocol also reserves a **refresh on foreground** switch (`refresh_on_foreground`): when on, the client re-fetches the configuration every time it returns to the foreground instead of waiting for a poll. It is off by default — every client requesting at the same foreground moment concentrates load on the configuration endpoint, the same shape as a release herd — and is meant only for applications that genuinely need a change to land within minutes. The switch cannot be set in the console yet and will open up in a later version.
### Version history and adoption
* Change history keeps the most recent 50 versions; older versions are cleaned up automatically and cannot be rolled back to. Each entry shows who made the change and the change note (if one was left). You can revert any retained version to make it the current configuration; a revert also produces a new version.
* A new version produced by a revert carries a content-equivalence label: if its configuration content is identical to an earlier version in the history, the history list marks it as equivalent to the earliest version with that content — a version-number jump does not mean the configuration content changed.
* The rollout panel shows **adoption** and rollout progress across recently arrived sampled sessions, with status labels *waiting for new sessions* (just published, no session has started under the current version yet), *in effect* (some sessions have switched), *recent sessions switched* (every session that arrived in the window is on the current version), *no configuration received* (none of the recent sessions reported a configuration version — usually the SDK has remote configuration disabled or is too old), *no data* (no new sessions in the window), and *no adoption detected* (published for over about 8 hours and still not on the current version); slices that did not report a configuration version are labeled *not reported* (SDK too old or config never fetched). Clicking **View details** opens the event explorer on this batch of sampled sessions. When fewer than 20 sampled sessions fall in the window, the panel shows the actual session counts only and does not estimate shares (shares are extrapolated from the sample rate, which is meaningless with too few samples).
## Delete Application
If you no longer need an application, you can find the delete button at the bottom of the "Basic Info" tab in the application details.
After deleting an application:
* No new events will be received
* The application's Client Token will be immediately revoked
* Previously collected RUM event data can still be manually exported, or you can contact the support team to restore the deleted application
This operation requires the **RUM Application Delete** permission.
## Next Steps
Learn how to integrate RUM SDK
Learn about advanced configuration options for the SDK
View and analyze RUM data
Learn how to integrate the RUM SDK into a WeChat Mini Program