The Controls page provides settings that affect your entire account, such as whether Experiences display on mobile, domains can be enabled via API, or how you manage data consent.
These are guardrails that prevent your team from accidentally breaking your product UI, privacy regulations, or creating security holes. This guide explains each control, when you'd need to change it, and what happens when you do.
Availability & Usage
🔐 Available on Startup, Growth, Enterprise
🧑💼 "Admins" can adjust (if Roles are enabled)
⚙️ Access in the Dashboard
Data Controls
Product Demos: Default consent
Controls whether anonymous Demo viewers are automatically opted into having their interactions connected to their identity in your product.
When ON: Anonymous users are automatically opted in. Chameleon can connect their anonymous Demo interactions to their profile once they're identified in your product.
When OFF: Anonymous users are opted out.
When to turn OFF:
You operate under strict privacy regulations (GDPR, CCPA)
Your Demos target cold prospects who haven't consented to tracking
You need explicit consent before connecting anonymous and identified user data
Keep ON if: Your Demos are embedded in your product where users have already accepted your privacy policy, or you're targeting existing users who are temporarily unidentified.
Display Controls
These determine where and how your Chameleon Experiences can display. By default, Chameleon blocks mobile displays and assumes left-to-right layouts. Only enable these if you've intentionally built for those contexts; turning them on without preparation can result in broken, unusable Experiences.
Display Experiences on mobile
Controls whether Chameleon Experiences show on mobile browsers (screen width < 720px). Chameleon Experiences are responsive and will adjust as elements on your page move based on the browser size.
When OFF (default): All Experiences are turned off for browser width < 720px to prevent broken layouts.
ℹ Reducing the width of a browser on a desktop will not classify it as a mobile browser. Mobile devices are identified based on whether the browser used is a mobile browser, such as the case for all handheld mobile devices (phones, tablets, etc).
When ON: Experiences display on mobile browsers. You can use the "Device type" segmentation filter to target users based on whether they're accessing your page using a desktop or mobile device. When this is off, the "Device type" filter is available for targeting desktop users only.
Once toggled on, all your Experiences will be displayed on both desktop and mobile devices, unless you add specific "Device type" filters in your Segments. Update your segments before toggling this on.
When to turn ON:
You've designed mobile-ready Experiences
Your product has mobile web users who need guidance
You've tested Experiences at mobile screen sizes
After enabling: Use Device type targeting on every Experience to control whether it shows on mobile, desktop, or both.
At this stage, Chameleon does not support native mobile applications. However, you can still send usage data from your mobile apps to Chameleon, to allow you to target web users based on their mobile activity.
Display Experiences in RTL
Reverses the direction of Experiences for right-to-left languages (Arabic, Hebrew, Farsi).
When OFF (default): Experiences display from left to right.
When ON: Positioning settings flips: left becomes right, right becomes left. Content appears RTL.
When to turn ON:
Your product supports RTL languages
You have users with browser language set to RTL
Usage Controls
These limit what your team can do with Chameleon's more technical features. The defaults allow custom code and HTML because these features unlock powerful integrations and customizations. You can disable them if your team lacks the technical oversight to review custom code safely, or you want to restrict executable code in your product.
Enable domains via API
Allows you to programmatically enable and verify subdomains through the Chameleon API instead of manually approving each one.
When OFF (default): Every new subdomain needs to be toggled on in your Environments before Experiences will display. This is a security measure to prevent unauthorized domains from being added.
When ON: You can use the API to automatically enable subdomains as they're created.
When to turn ON:
You have customer-specific subdomains (e.g., app.customer1.com, app.customer2.com, app.customer3.com)
You're adding subdomains programmatically and need Experiences to work immediately
Manual approval for each subdomain doesn't scale for your use case
Keep OFF if: You have a single domain or a small number of static subdomains. Manual approval is safer and only takes a few clicks.
Allow HTML in Steps
Permit text content within Experiences to be parsed or read as HTML. This allows scripts to be executed in content fields (e.g., within the body of a Tour Step).
When OFF: Content fields accept only plain text and standard formatting.
When ON: Content is parsed as HTML, executing any scripts included in the body of Experiences.
When to turn ON:
You need custom styling beyond the Builder design options
You're embedding interactive elements not available through standard features
Your engineering team has reviewed and approved the specific HTML you're implementing
Best practice: Enabling this allows untested scripts to run inside your product, creating potential vulnerabilities. Only enable temporarily for specific, vetted use cases.
Disable Run Code option
Removes the ability to run code as an option from a Tour/Microsurvey button or Launcher item.
When OFF (default): You can add code scripts to button Actions and Launcher items.
When ON: The "Run Custom Code" option is disabled in the Builder.
When to turn ON:
Your team lacks technical review capacity for custom scripts
You're operating under compliance requirements that restrict executable code
You want tighter control over what builders can implement
Use cases you'll lose:
Opening chat widgets (Intercom, Zendesk)
Simulating multi-step element clicks
Updating user properties in other systems
Custom focus/cursor behaviors