True/False. When True, blueprints can't notify a user group about new approval requests, the notify users with group option is hidden in the Portal, and no group notification emails are sent.
Where to add/change
customer.config Quali Server installation directory
Default value
False
Affected CloudShell Component
Quali Server
Version
2026.2.0.34 and above
Enabling the automatic removal of expired approval requests
True/False (True - This cache promotes faster retrieval of resource details when rendering diagrams. False - disables for specific problematic scenarios - very large diagrams)
Where to add/change
customer.config CloudShell Server installation directory
Starting with CloudShell 2024.1.0.2682, CloudShell supports overriding customer.config values using environment variables. This enables configuration management without modifying files directly, which is useful for containerized deployments and automation scenarios.
To override a configuration key, set an environment variable whose name is exactly the configuration key name — there is no prefix and no character substitution. For example, to override <add key="UseRabbitServer" value="false"/>, set an environment variable named UseRabbitServer.
Key
N/A (the environment variable is named after the configuration key it overrides)
Possible values
Any value that would be valid in the corresponding customer.config key
Where to add/change
System environment variables on the machine running the CloudShell component
Default value
N/A
Affected CloudShell Component
All (Quali Server, Portal, Execution Server)
Version
2024.1.0.2682 and above
note
Environment variable overrides take precedence over values defined in customer.config. This allows you to manage configuration centrally (e.g., via orchestration tools or container runtime) without modifying config files on disk.
An environment variable that is unset or set to an empty string is ignored, and the value from customer.config (or the key's built-in default) is used instead. You therefore cannot use an environment variable to override a key to an empty value.
This applies to the great majority of configuration keys, but not to every one of them — a small number are read straight from the configuration file and ignore the environment. If a key does not respond to an environment variable, set it in customer.config instead.
Allow unicode characters in script command context
When set to true, allows passing unicode characters to script environment variables. This is useful when usernames or other context values contain unicode characters. By default, unicode characters are suppressed when CloudShell builds the environment variables that pass the command context to a script.
The Execution Server reads this key, so set it on each Execution Server that runs the affected scripts — setting it on the Quali Server has no effect. Restart the Execution Server service after changing it.
Administrators can configure an AI Assistant menu item in the Portal by setting a URL template. This adds a menu item that opens an AI chat interface in a new browser tab, passing context about the current Portal page (and the current sandbox, when applicable) to the external AI chat service.
The URL template can include placeholders, wrapped in curly braces, that are replaced with the actual context values at runtime. For example, the template https://your-ai-chat-url.com?page={pageUrl}&user={user} opens the chat URL with the current page path and the logged-in user's name filled in.
Because the template is set as the value of an XML attribute in customer.config, any literal & that separates URL query parameters must be written as &. You can also use commas instead.
The following placeholders are supported:
Always available (provided on every Portal page):
Placeholder
Description
{user}
Username of the logged-in user.
{domain}
Name of the current domain (empty if none).
{version}
CloudShell version (without the build number).
{pageType}
Identifier of the current Portal page (empty if not available).
{pageUrl}
Path and query string of the current Portal page.
{pageContent}
The visible text of the Portal's main content area, with runs of whitespace collapsed to single spaces and truncated to the first 2000 characters.
{context}
All of the other placeholder values as a single JSON object. Use this to hand the whole context to a chat service that takes one free-text query — it is the placeholder used in the example that ships in customer.config.
Available only inside a sandbox or blueprint page (replaced with empty values on all other pages, such as the catalog or inventory):
Placeholder
Description
{sandboxId}
ID of the current sandbox/blueprint.
{sandboxName}
Name of the current sandbox/blueprint.
{status}
Reservation status of the sandbox.
{setupStage}
Current setup stage of the sandbox.
{resourceList}
Comma-separated list of resource names in the sandbox/blueprint.
{resourceCount}
Number of resources in the sandbox/blueprint.
note
Sandbox placeholders ({sandboxId}, {sandboxName}, {status}, {setupStage}, {resourceList}, {resourceCount}) are only populated when the user opens the AI Assistant from within a sandbox or blueprint diagram. On any other page they are replaced with empty values.
Each value is URL-encoded automatically when it is substituted, so do not encode the placeholders yourself.
A placeholder that is not in the list above — including a misspelled one — is replaced with an empty string rather than reported as an error. If a template produces a URL with missing values, check the placeholder spelling first.
Both {pageContent} and {context} send Portal content off-site
{pageContent} carries whatever text is currently on the user's screen, and {context} embeds {pageContent} along with every other value. Using either one sends that content — which can include resource names, addresses, and attribute values shown on the page — to the external chat service in the URL, where it may be logged or retained by that service. Point the template only at a service your organization is willing to share this data with, and prefer the narrower placeholders if you do not need the full page.
Keep Portal users signed in across application-pool recycles
When enabled, the Portal rebuilds a user's session from the sign-in cookie after an application-pool recycle instead of forcing a re-login. This applies to standard and SSO/SAML users, and lets background page refreshes recover silently. Set to False to restore the previous behavior of signing users out on recycle.