In the Sandbox module, you can assign dynamic values to parameters for different environments (e.g., development, testing, production), ensuring consistent configurations across multiple stages of the deployment process. These parameters can be created either directly from a Sandbox instance or through ConfigStore.
Key Use Case
For example, if an API URL varies between environments (e.g., a local URL for staging and a live URL for production), you can store it as a parameter in ConfigStore. By defining environment-specific values, the URL automatically adjusts for each environment, eliminating manual updates and streamlining configuration management.
Understanding Parameter Scope
The scope of a parameter defines its accessibility, indicating whether it can be used across all environments or is restricted to specific environments.
ConfigStore provides two types of scopes:
Global:Parameters are accessible throughout an entire workspace, with the same values applied in all environments.
Environment: Parameter values are unique to each environment, allowing different configurations for development, testing, and production stages.
Assigning Values Based on Scope
Global Scope: If the Sandbox feature is disabled, only the Global scope is available, meaning parameter values are applied consistently across all environments.
Environment Scope: Available only when the Sandbox feature is enabled, allowing you to define environment-specific parameter values.
By default, the parameter value is assigned to the current environment and is uneditable.
For other environments, you must manually assign values. If no value is assigned for an instance, the default value will be used.
Parameter values defined in ConfigStore will change at the environment level, not at the instance level. Within an environment, the same parameter value will apply to all instances.
Handling New Environments
When a new environment is added after a parameter has been created, the parameter values will initially be empty. The default value will be used to prevent failures. However, if the parameter is utilized in modules like Circuit or Function without an assigned value, it may affect the flow or execution.
Example Scenario
Consider a parameter with the following values:
When the parameter is executed in the staging environment, the staging value will be used. If executed in the production environment, it will use the default value.
You can either define specific values for each environment or rely on the default value. This ensures that there are no issues with empty parameter values, maintaining smooth operation across different environments.
Related Articles
Projects (Testing environment) - An Overview
Early Access This feature is not enabled for all users. If you'd like to try it out, please email our support team for early access. Running a business can become complex as it grows. Bringing in new changes and enhancements is likely in any business ...
Parameters in CodeX Script
In the CodeX script, you can perform CRUD (Create, Read, Update, Delete) operations on the Parameters in Qntrl through the SDK. Instead of defining a URL or other values directly in your CodeX script, you can define them in ConfigStore and reference ...
Working with Projects
Step 1: Create a Project An admin or user with Manage Settings permission can create Projects. To create a project (test environment): Navigate to and select Projects under Advanced. Click New Project at the top-right corner. Enter the following ...
Parameters
Parameters provide the ability to customize JSON input by adding a collection of key-value pairs as input to a task. These values can either be static or dynamically selected from the JSON input or the context object using specific paths. Context ...
Other actions in Projects
Free up a sandbox You can unassociate a project from the sandbox when you want to free up a sandbox. To unassociate a sandbox: Navigate to and select Projects under Advanced. Click the Sandbox button at the top band. All sandboxes will be listed ...