{
  "doc": {
    "id": "ui-coverage/configuration/profiles",
    "title": "profiles: apply config overrides by run tag",
    "description": "Use the profiles property to apply UI Coverage configuration overrides based on run tags.",
    "section": "ui-coverage",
    "source_path": "/llm/markdown/ui-coverage/configuration/profiles.md",
    "version": "29f95bf8bb06f320986f3749f5bf09a35a409eab",
    "updated_at": "2026-09-04T10:49:54.630Z",
    "headings": [
      {
        "id": "ui-coverage/configuration/profiles#override-config-by-run-tag-profiles",
        "text": "Override config by run tag - profiles",
        "level": 1
      },
      {
        "id": "ui-coverage/configuration/profiles#why-use-profiles",
        "text": "Why use profiles?",
        "level": 2
      },
      {
        "id": "ui-coverage/configuration/profiles#how-profiles-work",
        "text": "How profiles work",
        "level": 2
      },
      {
        "id": "ui-coverage/configuration/profiles#selecting-a-profile",
        "text": "Selecting a profile",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#how-a-profile-changes-your-configuration",
        "text": "How a profile changes your configuration",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#what-a-profile-can-and-cant-change",
        "text": "What a profile can and can't change",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#best-practices",
        "text": "Best practices",
        "level": 2
      },
      {
        "id": "ui-coverage/configuration/profiles#syntax",
        "text": "Syntax",
        "level": 2
      },
      {
        "id": "ui-coverage/configuration/profiles#options",
        "text": "Options",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#examples",
        "text": "Examples",
        "level": 2
      },
      {
        "id": "ui-coverage/configuration/profiles#basic-profile-structure",
        "text": "Basic profile structure",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#usage",
        "text": "Usage",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#multiple-profiles",
        "text": "Multiple profiles",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#usage",
        "text": "Usage",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#profile-with-nested-configuration",
        "text": "Profile with nested configuration",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#usage",
        "text": "Usage",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#profile-selection-with-multiple-matching-tags",
        "text": "Profile selection with multiple matching tags",
        "level": 3
      },
      {
        "id": "ui-coverage/configuration/profiles#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#usage",
        "text": "Usage",
        "level": 4
      },
      {
        "id": "ui-coverage/configuration/profiles#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "ui-coverage/configuration/profiles#why-use-profiles",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Why use profiles?",
      "heading_level": 2,
      "content_markdown": "## Why use profiles?\n\n*   **Tune pull request checks against regression runs**: Gate merges with a narrow configuration focused on your most critical flows, so the report a developer sees on a PR is small, fast to act on, and high in \"solvability\". Keep a wide configuration on the full regression suite to track everything else on a slower cadence.\n*   **Team-specific reporting**: When multiple teams share one project, each team can tag its runs and see a report scoped to the pages or elements it owns, filtering out everyone else's. Nobody has to read around results they don't care about.\n*   **Purpose-built audit runs**: A one-off audit, such as a localization pass, a design-system sweep, or a deep dive on an area you normally exclude, can use configuration you'd never want applied to every run.\n",
      "section": "ui-coverage",
      "anchors": [
        "why-use-profiles"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 181
    },
    {
      "id": "ui-coverage/configuration/profiles#how-profiles-work",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "How profiles work",
      "heading_level": 2,
      "content_markdown": "## How profiles work\n\n### Selecting a profile\n\nProfiles are selected by matching run tags to profile names. When you record a run with the [`--tag`](/llm/markdown/app/references/command-line.md#cypress-run-tag-lt-tag-gt) flag, Cypress Cloud walks the `profiles` array in order and applies the **first profile whose `name` exactly matches one of the run's tags**. Matching is an exact, case-sensitive string comparison: `aq-config-regression` matches only the tag `aq-config-regression`, not `AQ-Config-Regression` or `aq-config-regression-nightly`. When several tags match different profiles, the first match in the array wins (so list more specific profiles before broader ones), and the order the tags appear on the run makes no difference. If no tag matches, your base configuration is used unchanged.\n\nProfiles are resolved when a run is processed, not when your tests execute. Reprocessing a past run re-applies the profiles and configuration you have saved now, so you can adjust a profile and see its effect on an existing run without recording again.\n\n### How a profile changes your configuration\n\nWhen a profile applies, its `config` is laid over your base configuration one setting at a time. Only the settings you include in the profile change; everything else stays exactly as it is in your base configuration. A few things are worth knowing so the result matches what you expect:\n\n*   **A setting in a profile fully replaces the base version of that setting.** Lists are not combined. If your base configuration has three `elementFilters` rules and a profile defines its own `elementFilters`, the profile's rules are used on their own, so copy over any base rules you still want to apply.\n*   **Anything you leave out of a profile stays the same.** You only need to list what's different for that kind of run; the rest is inherited from your base configuration.\n*   **The `accessibility` and `uiCoverage` objects are merged one level deep.** Overriding a single setting inside one of them, such as `accessibility.significantAttributes`, leaves the sibling settings in that object (like `accessibility.elementFilters`) untouched, so you can adjust one product-specific setting without restating the rest.\n\n### What a profile can and can't change\n\nA profile's `config` accepts any App Quality configuration setting your base configuration supports: the same `viewFilters`, `elementFilters`, `views`, and product-specific settings you'd set at the root. Two limits are worth knowing:\n\n*   **You can't nest a `profiles` array inside a profile.** Profiles live only at the top level of your configuration; one level of overrides is the maximum.\n*   **There's no switch to skip a run or turn a product off.** A profile can only change configuration values. To suppress a report for a certain kind of run, point its profile at a deliberately narrow configuration (for example, `viewFilters` that exclude every view) so the run produces an empty or tightly scoped report instead.\n",
      "section": "ui-coverage",
      "anchors": [
        "how-profiles-work"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 609
    },
    {
      "id": "ui-coverage/configuration/profiles#selecting-a-profile",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Selecting a profile",
      "heading_level": 3,
      "content_markdown": "### Selecting a profile\n\nProfiles are selected by matching run tags to profile names. When you record a run with the [`--tag`](/llm/markdown/app/references/command-line.md#cypress-run-tag-lt-tag-gt) flag, Cypress Cloud walks the `profiles` array in order and applies the **first profile whose `name` exactly matches one of the run's tags**. Matching is an exact, case-sensitive string comparison: `aq-config-regression` matches only the tag `aq-config-regression`, not `AQ-Config-Regression` or `aq-config-regression-nightly`. When several tags match different profiles, the first match in the array wins (so list more specific profiles before broader ones), and the order the tags appear on the run makes no difference. If no tag matches, your base configuration is used unchanged.\n\nProfiles are resolved when a run is processed, not when your tests execute. Reprocessing a past run re-applies the profiles and configuration you have saved now, so you can adjust a profile and see its effect on an existing run without recording again.\n",
      "section": "ui-coverage",
      "anchors": [
        "selecting-a-profile"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 197
    },
    {
      "id": "ui-coverage/configuration/profiles#how-a-profile-changes-your-configuration",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "How a profile changes your configuration",
      "heading_level": 3,
      "content_markdown": "### How a profile changes your configuration\n\nWhen a profile applies, its `config` is laid over your base configuration one setting at a time. Only the settings you include in the profile change; everything else stays exactly as it is in your base configuration. A few things are worth knowing so the result matches what you expect:\n\n*   **A setting in a profile fully replaces the base version of that setting.** Lists are not combined. If your base configuration has three `elementFilters` rules and a profile defines its own `elementFilters`, the profile's rules are used on their own, so copy over any base rules you still want to apply.\n*   **Anything you leave out of a profile stays the same.** You only need to list what's different for that kind of run; the rest is inherited from your base configuration.\n*   **The `accessibility` and `uiCoverage` objects are merged one level deep.** Overriding a single setting inside one of them, such as `accessibility.significantAttributes`, leaves the sibling settings in that object (like `accessibility.elementFilters`) untouched, so you can adjust one product-specific setting without restating the rest.\n",
      "section": "ui-coverage",
      "anchors": [
        "how-a-profile-changes-your-configuration"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 244
    },
    {
      "id": "ui-coverage/configuration/profiles#what-a-profile-can-and-cant-change",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "What a profile can and can't change",
      "heading_level": 3,
      "content_markdown": "### What a profile can and can't change\n\nA profile's `config` accepts any App Quality configuration setting your base configuration supports: the same `viewFilters`, `elementFilters`, `views`, and product-specific settings you'd set at the root. Two limits are worth knowing:\n\n*   **You can't nest a `profiles` array inside a profile.** Profiles live only at the top level of your configuration; one level of overrides is the maximum.\n*   **There's no switch to skip a run or turn a product off.** A profile can only change configuration values. To suppress a report for a certain kind of run, point its profile at a deliberately narrow configuration (for example, `viewFilters` that exclude every view) so the run produces an empty or tightly scoped report instead.\n",
      "section": "ui-coverage",
      "anchors": [
        "what-a-profile-can-and-cant-change"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 163
    },
    {
      "id": "ui-coverage/configuration/profiles#best-practices",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Best practices",
      "heading_level": 2,
      "content_markdown": "## Best practices\n\nUse a naming convention like `aq-config-*` (for example, `aq-config-regression`, `aq-config-pr`) so it's obvious that a tag exists for configuration lookup rather than for filtering or grouping runs in Cypress Cloud.\n\nBeing explicit this way helps avoid accidentally changing or removing a tag that a profile depends on. Because names are matched exactly against run tags, keep them stable: renaming a profile or changing a tag silently falls back to the base configuration for those runs.\n",
      "section": "ui-coverage",
      "anchors": [
        "best-practices"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 104
    },
    {
      "id": "ui-coverage/configuration/profiles#syntax",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Syntax",
      "heading_level": 2,
      "content_markdown": "## Syntax\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": string,\n      \"config\": {\n        // Any App Quality configuration options\n      },\n      \"comment\": string\n    }\n  ]\n}\n```\n\n### Options\n\n| Option | Required | Description |\n| --- | --- | --- |\n| `name` | Required | Identifies the profile so a run can select it. Its only purpose is matching: the profile applies when one of the run's tags is an exact, case-sensitive match for this value. It isn't shown in reports or used anywhere else. |\n| `config` | Required | An object containing any App Quality configuration options, except a nested `profiles` array. These values override the root configuration. |\n| `comment` | Optional | A note about why this profile exists, for your team's benefit. Comments appear only in the configuration itself. They have no effect on behavior and are not displayed in reports. |\n",
      "section": "ui-coverage",
      "anchors": [
        "syntax"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 200
    },
    {
      "id": "ui-coverage/configuration/profiles#options",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Options",
      "heading_level": 3,
      "content_markdown": "### Options\n\n| Option | Required | Description |\n| --- | --- | --- |\n| `name` | Required | Identifies the profile so a run can select it. Its only purpose is matching: the profile applies when one of the run's tags is an exact, case-sensitive match for this value. It isn't shown in reports or used anywhere else. |\n| `config` | Required | An object containing any App Quality configuration options, except a nested `profiles` array. These values override the root configuration. |\n| `comment` | Optional | A note about why this profile exists, for your team's benefit. Comments appear only in the configuration itself. They have no effect on behavior and are not displayed in reports. |\n",
      "section": "ui-coverage",
      "anchors": [
        "options"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 164
    },
    {
      "id": "ui-coverage/configuration/profiles#examples",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Examples",
      "heading_level": 2,
      "content_markdown": "## Examples\n\n### Basic profile structure\n\nYour base configuration excludes the support-chat widget, since another team owns it and it just adds noise to most reports. But one suite exists specifically to test the support-chat flow, and it records under the `aq-config-support-chat` tag. For that run, and only that run, the widget should count toward coverage.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"elementFilters\": [\n    {\n      \"selector\": \"#support-chat-widget\",\n      \"include\": false,\n      \"comment\": \"Exclude the support-chat widget from most reports\"\n    }\n  ],\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-support-chat\",\n      \"config\": {\n        \"elementFilters\": [\n          {\n            \"selector\": \"#support-chat-widget\",\n            \"include\": true,\n            \"comment\": \"The support-chat suite tests this widget, so count it here\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\nRecord the support-chat suite with a matching tag:\n\n```\ncypress run --record --tag \"aq-config-support-chat\"\n```\n\nOn every other run the widget stays excluded. On the tagged run, the profile's `elementFilters` replaces the base list, so the `include: true` rule wins and the widget counts toward coverage. Because a profile's list replaces the base list rather than adding to it, list every rule the run needs, not only the one that changed.\n\n### Multiple profiles\n\nYou can define several profiles, each for a different kind of run. Here, two focused audit suites want the same routes broken down into separate [views](/llm/markdown/ui-coverage/core-concepts/views.md) so they can see coverage per value: a reporting audit splits `/reports/:type` by report type, and a localization audit splits `/:locale/account` by locale. You wouldn't want either split applied to every run, since it would fragment your normal reports into many low-traffic views, so each `views` rule is scoped to its own tag.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-reporting-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/reports/:type\",\n            \"groupBy\": [\"type\"],\n            \"comment\": \"One view per report type for the reporting audit\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-localization-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/:locale/account\",\n            \"groupBy\": [\"locale\"],\n            \"comment\": \"One view per locale for the localization audit\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\nUse different tags to activate different profiles:\n\n```\n# Reporting audit runs\ncypress run --record --tag \"aq-config-reporting-audit\"\n\n# Localization audit runs\ncypress run --record --tag \"aq-config-localization-audit\"\n```\n\n### Profile with nested configuration\n\nProfiles can override configuration at any level, including configuration specific to Cypress Accessibility or UI Coverage when your project has both products enabled. Because `uiCoverage` and `accessibility` merge one level deep, a profile can add or replace a single nested property while inheriting the rest.\n\nHere the base configuration groups every product card into one [element group](/llm/markdown/ui-coverage/configuration/elementgroups.md) so the repeated cards count once and don't dominate the score. A suite that specifically exercises each card variant, tagged `aq-config-card-variants`, needs the opposite: the same cards split into separate groups so featured and standard cards are tracked independently. The two groupings can't both be the base configuration, so the difference lives in a profile.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"uiCoverage\": {\n    \"attributeFilters\": [\n      {\n        \"attribute\": \"id\",\n        \"value\": \":r.*:\",\n        \"include\": false,\n        \"comment\": \"Ignore React auto-generated IDs so elements stay stable across renders\"\n      }\n    ],\n    \"elementGroups\": [\n      {\n        \"selector\": \"[data-cy='product-card']\",\n        \"name\": \"Product card\",\n        \"comment\": \"Count the repeated product cards as one group\"\n      }\n    ]\n  },\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-card-variants\",\n      \"config\": {\n        \"uiCoverage\": {\n          \"elementGroups\": [\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='featured']\",\n              \"name\": \"Featured product card\"\n            },\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='standard']\",\n              \"name\": \"Standard product card\"\n            }\n          ]\n        }\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\n```\ncypress run --record --tag \"aq-config-card-variants\"\n```\n\nInside `uiCoverage`, the profile replaces `elementGroups` with its own two groups while the sibling `attributeFilters` is inherited; only the keys the profile names are replaced. On every other run, the single \"Product card\" group still applies.\n\n### Profile selection with multiple matching tags\n\nTwo teams share one Cypress Cloud project, and each has a profile that scopes the report to the views they own. A shared nightly job is tagged for both teams. When more than one tag matches a profile name, Cypress Cloud uses the first matching profile in the `profiles` array, regardless of the order the tags appear on the run.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-team-checkout\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/checkout/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Checkout team: report only on checkout views\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-team-account\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/account/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Account team: report only on account views\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\n```\ncypress run --record --tag \"aq-config-team-account,aq-config-team-checkout\"\n```\n\nBoth tags match a profile, but Cypress Cloud applies `aq-config-team-checkout` because it appears first in the `profiles` array, even though `aq-config-team-account` is listed first among the tags. The checkout team's report is produced; tag order on the command line doesn't change the outcome.\n",
      "section": "ui-coverage",
      "anchors": [
        "examples"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 1063
    },
    {
      "id": "ui-coverage/configuration/profiles#basic-profile-structure",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Basic profile structure",
      "heading_level": 3,
      "content_markdown": "### Basic profile structure\n\nYour base configuration excludes the support-chat widget, since another team owns it and it just adds noise to most reports. But one suite exists specifically to test the support-chat flow, and it records under the `aq-config-support-chat` tag. For that run, and only that run, the widget should count toward coverage.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"elementFilters\": [\n    {\n      \"selector\": \"#support-chat-widget\",\n      \"include\": false,\n      \"comment\": \"Exclude the support-chat widget from most reports\"\n    }\n  ],\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-support-chat\",\n      \"config\": {\n        \"elementFilters\": [\n          {\n            \"selector\": \"#support-chat-widget\",\n            \"include\": true,\n            \"comment\": \"The support-chat suite tests this widget, so count it here\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\nRecord the support-chat suite with a matching tag:\n\n```\ncypress run --record --tag \"aq-config-support-chat\"\n```\n\nOn every other run the widget stays excluded. On the tagged run, the profile's `elementFilters` replaces the base list, so the `include: true` rule wins and the widget counts toward coverage. Because a profile's list replaces the base list rather than adding to it, list every rule the run needs, not only the one that changed.\n",
      "section": "ui-coverage",
      "anchors": [
        "basic-profile-structure"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 244
    },
    {
      "id": "ui-coverage/configuration/profiles#config",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"elementFilters\": [\n    {\n      \"selector\": \"#support-chat-widget\",\n      \"include\": false,\n      \"comment\": \"Exclude the support-chat widget from most reports\"\n    }\n  ],\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-support-chat\",\n      \"config\": {\n        \"elementFilters\": [\n          {\n            \"selector\": \"#support-chat-widget\",\n            \"include\": true,\n            \"comment\": \"The support-chat suite tests this widget, so count it here\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 75
    },
    {
      "id": "ui-coverage/configuration/profiles#usage",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Usage",
      "heading_level": 4,
      "content_markdown": "#### Usage\n\nRecord the support-chat suite with a matching tag:\n\n```\ncypress run --record --tag \"aq-config-support-chat\"\n```\n\nOn every other run the widget stays excluded. On the tagged run, the profile's `elementFilters` replaces the base list, so the `include: true` rule wins and the widget counts toward coverage. Because a profile's list replaces the base list rather than adding to it, list every rule the run needs, not only the one that changed.\n",
      "section": "ui-coverage",
      "anchors": [
        "usage"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 97
    },
    {
      "id": "ui-coverage/configuration/profiles#multiple-profiles",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Multiple profiles",
      "heading_level": 3,
      "content_markdown": "### Multiple profiles\n\nYou can define several profiles, each for a different kind of run. Here, two focused audit suites want the same routes broken down into separate [views](/llm/markdown/ui-coverage/core-concepts/views.md) so they can see coverage per value: a reporting audit splits `/reports/:type` by report type, and a localization audit splits `/:locale/account` by locale. You wouldn't want either split applied to every run, since it would fragment your normal reports into many low-traffic views, so each `views` rule is scoped to its own tag.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-reporting-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/reports/:type\",\n            \"groupBy\": [\"type\"],\n            \"comment\": \"One view per report type for the reporting audit\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-localization-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/:locale/account\",\n            \"groupBy\": [\"locale\"],\n            \"comment\": \"One view per locale for the localization audit\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\nUse different tags to activate different profiles:\n\n```\n# Reporting audit runs\ncypress run --record --tag \"aq-config-reporting-audit\"\n\n# Localization audit runs\ncypress run --record --tag \"aq-config-localization-audit\"\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "multiple-profiles"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 232
    },
    {
      "id": "ui-coverage/configuration/profiles#config",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-reporting-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/reports/:type\",\n            \"groupBy\": [\"type\"],\n            \"comment\": \"One view per report type for the reporting audit\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-localization-audit\",\n      \"config\": {\n        \"views\": [\n          {\n            \"pattern\": \"/:locale/account\",\n            \"groupBy\": [\"locale\"],\n            \"comment\": \"One view per locale for the localization audit\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 84
    },
    {
      "id": "ui-coverage/configuration/profiles#profile-with-nested-configuration",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Profile with nested configuration",
      "heading_level": 3,
      "content_markdown": "### Profile with nested configuration\n\nProfiles can override configuration at any level, including configuration specific to Cypress Accessibility or UI Coverage when your project has both products enabled. Because `uiCoverage` and `accessibility` merge one level deep, a profile can add or replace a single nested property while inheriting the rest.\n\nHere the base configuration groups every product card into one [element group](/llm/markdown/ui-coverage/configuration/elementgroups.md) so the repeated cards count once and don't dominate the score. A suite that specifically exercises each card variant, tagged `aq-config-card-variants`, needs the opposite: the same cards split into separate groups so featured and standard cards are tracked independently. The two groupings can't both be the base configuration, so the difference lives in a profile.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"uiCoverage\": {\n    \"attributeFilters\": [\n      {\n        \"attribute\": \"id\",\n        \"value\": \":r.*:\",\n        \"include\": false,\n        \"comment\": \"Ignore React auto-generated IDs so elements stay stable across renders\"\n      }\n    ],\n    \"elementGroups\": [\n      {\n        \"selector\": \"[data-cy='product-card']\",\n        \"name\": \"Product card\",\n        \"comment\": \"Count the repeated product cards as one group\"\n      }\n    ]\n  },\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-card-variants\",\n      \"config\": {\n        \"uiCoverage\": {\n          \"elementGroups\": [\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='featured']\",\n              \"name\": \"Featured product card\"\n            },\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='standard']\",\n              \"name\": \"Standard product card\"\n            }\n          ]\n        }\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\n```\ncypress run --record --tag \"aq-config-card-variants\"\n```\n\nInside `uiCoverage`, the profile replaces `elementGroups` with its own two groups while the sibling `attributeFilters` is inherited; only the keys the profile names are replaced. On every other run, the single \"Product card\" group still applies.\n",
      "section": "ui-coverage",
      "anchors": [
        "profile-with-nested-configuration"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 329
    },
    {
      "id": "ui-coverage/configuration/profiles#config",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"uiCoverage\": {\n    \"attributeFilters\": [\n      {\n        \"attribute\": \"id\",\n        \"value\": \":r.*:\",\n        \"include\": false,\n        \"comment\": \"Ignore React auto-generated IDs so elements stay stable across renders\"\n      }\n    ],\n    \"elementGroups\": [\n      {\n        \"selector\": \"[data-cy='product-card']\",\n        \"name\": \"Product card\",\n        \"comment\": \"Count the repeated product cards as one group\"\n      }\n    ]\n  },\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-card-variants\",\n      \"config\": {\n        \"uiCoverage\": {\n          \"elementGroups\": [\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='featured']\",\n              \"name\": \"Featured product card\"\n            },\n            {\n              \"selector\": \"[data-cy='product-card'][data-variant='standard']\",\n              \"name\": \"Standard product card\"\n            }\n          ]\n        }\n      }\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 113
    },
    {
      "id": "ui-coverage/configuration/profiles#usage",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Usage",
      "heading_level": 4,
      "content_markdown": "#### Usage\n\n```\ncypress run --record --tag \"aq-config-card-variants\"\n```\n\nInside `uiCoverage`, the profile replaces `elementGroups` with its own two groups while the sibling `attributeFilters` is inherited; only the keys the profile names are replaced. On every other run, the single \"Product card\" group still applies.\n",
      "section": "ui-coverage",
      "anchors": [
        "usage"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 60
    },
    {
      "id": "ui-coverage/configuration/profiles#profile-selection-with-multiple-matching-tags",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Profile selection with multiple matching tags",
      "heading_level": 3,
      "content_markdown": "### Profile selection with multiple matching tags\n\nTwo teams share one Cypress Cloud project, and each has a profile that scopes the report to the views they own. A shared nightly job is tagged for both teams. When more than one tag matches a profile name, Cypress Cloud uses the first matching profile in the `profiles` array, regardless of the order the tags appear on the run.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-team-checkout\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/checkout/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Checkout team: report only on checkout views\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-team-account\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/account/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Account team: report only on account views\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n\n#### Usage\n\n```\ncypress run --record --tag \"aq-config-team-account,aq-config-team-checkout\"\n```\n\nBoth tags match a profile, but Cypress Cloud applies `aq-config-team-checkout` because it appears first in the `profiles` array, even though `aq-config-team-account` is listed first among the tags. The checkout team's report is produced; tag order on the command line doesn't change the outcome.\n",
      "section": "ui-coverage",
      "anchors": [
        "profile-selection-with-multiple-matching-tags"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 255
    },
    {
      "id": "ui-coverage/configuration/profiles#config",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"profiles\": [\n    {\n      \"name\": \"aq-config-team-checkout\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/checkout/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Checkout team: report only on checkout views\"\n          }\n        ]\n      }\n    },\n    {\n      \"name\": \"aq-config-team-account\",\n      \"config\": {\n        \"viewFilters\": [\n          {\n            \"pattern\": \"/account/*\",\n            \"include\": true\n          },\n          {\n            \"pattern\": \"*\",\n            \"include\": false,\n            \"comment\": \"Account team: report only on account views\"\n          }\n        ]\n      }\n    }\n  ]\n}\n```\n",
      "section": "ui-coverage",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 96
    },
    {
      "id": "ui-coverage/configuration/profiles#usage",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "Usage",
      "heading_level": 4,
      "content_markdown": "#### Usage\n\n```\ncypress run --record --tag \"aq-config-team-account,aq-config-team-checkout\"\n```\n\nBoth tags match a profile, but Cypress Cloud applies `aq-config-team-checkout` because it appears first in the `profiles` array, even though `aq-config-team-account` is listed first among the tags. The checkout team's report is produced; tag order on the command line doesn't change the outcome.\n",
      "section": "ui-coverage",
      "anchors": [
        "usage"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 69
    },
    {
      "id": "ui-coverage/configuration/profiles#see-also",
      "doc_id": "ui-coverage/configuration/profiles",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [Cypress run `--tag`](/llm/markdown/app/references/command-line.md#cypress-run-tag-lt-tag-gt) is the flag that selects which profile a run uses.\n*   [Configuration overview](/llm/markdown/ui-coverage/configuration/overview.md) lists every option a profile's `config` can override and how to regenerate reports after changing configuration.\n*   [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) and [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md) are common properties to scope a profile's report.\n*   [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md#Profiles) answers common questions about profiles, including merge behavior and tag matching.\n",
      "section": "ui-coverage",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/ui-coverage/configuration/profiles.json",
      "token_estimate": 84
    }
  ]
}