Description of the limitation and why it is relevant to address
Worker/Integration Configuration: Scope and Exclusion Options
When creating a worker or integration, you can choose to assign a specific scope—selecting only the apps this worker will connect to—or set it as global, making the worker available to all applications within the environment.
Current Limitation:
Currently, when the Global option is selected, the worker is automatically connected to all applications, with no ability to exclude certain apps. This lack of an exclusion feature can lead to confusion and operational issues in several scenarios:
-
Unpublished or In-Development Apps:
Global workers are active for applications that are still in development or not yet published. If an in-development app connects to a global worker, it can cause disruptions or errors—such as crashing a worker that is also supporting live apps, or producing corrupted calculations. -
Version-Specific Requirements:
Some applications require a specific software version, such as SCIA V24. If a global worker runs a different version (e.g., SCIA V25) and a specific worker is set up for SCIA V24, calculations may still be routed to the global worker. For example, if two SCIA calculations are performed, the first might use the specific SCIA V24 worker, while the second defaults to the global SCIA V25 worker, which is not the intended behavior.
Submitter Proposed Design (Optional)
To address these issues, the following enhancements are suggested for the Global worker/integration availability options:
-
Option to Exclude Groups of Apps (Published/Unpublished):
This would allow the creation of global workers dedicated to unpublished apps, supporting development activities without impacting live environments. -
Option to Exclude Specific Apps from a List:
Administrators could select individual applications to exclude from the global worker’s scope, providing greater control and flexibility.
Current Workarounds
Currently, these challenges can be managed by avoiding the use of global workers entirely and assigning workers only to specific apps. However, this approach is impractical in environments with many applications, as it increases administrative overhead.
Having a set of global workers dedicated to unpublished apps offers a more streamlined solution. This enables developers to use integrations efficiently and safely, without the complexity of configuring individual connections for each app—especially when considering company software compliance rules and related requirements.