--- title: "Non-Configuration Elements" slug: "non-configuration-elements" updated: 2025-11-18T18:01:58Z published: 2025-11-18T18:01:58Z canonical: "docs.unqork.io/non-configuration-elements" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.unqork.io/llms.txt > Use this file to discover all available pages before exploring further. # Non-Configuration Elements Unlike dependencies, **non-configuration elements** can not be included in versioned applications. These elements exist outside versioning and are not connected to a specific application version: - **Data Collections**: The data stored in the environment is not captured in versioned applications; only the structure and logic are captured. - **Managed Assets**: Files in Managed Assets Administration, like PDFs, images, or CSS, are not captured in versioned applications. - **Environment-Level Configurations**: Application integrations, RBAC policies, and SSO settings are not captured in versioned applications. - **External Services and APIs**: In Application Versioning, only references are stored; external services and APIs are not part of the version. Learn more about non-configuration elements in detail by clicking on the links below: Data CollectionsManaged AssetsEnvironment SettingsExternal Services & APIs ## Data Collections Data Collections are not captured in versioned applications. #### Data Collections Are Not Versioned Data Collections serve as external reference assets that support application functionality, but they are not versioned. When an application is versioned, the associated Data Collections remain static and external to the version. #### Changes Can Impact Application Logic Any changes made to a Data Collection will reflect across all application versions that reference it, regardless of whether those versions were created. As a result, developers and administrators must exercise caution when modifying Data Collections, especially in environments where versioned applications are actively used. #### Document and Communicate To maintain stability, keep Data Collections consistent and well-documented throughout the application’s life cycle. Any changes, like renaming columns, altering data types, or removing values, should be carefully reviewed and communicated. If not, they can impact logic, drop-downs, and validations tied to those collections. #### Manual Versioning as a Consideration To avoid unintended impacts, teams often duplicate and use naming conventions to align with specific application versions. For example, `DC_Eligibility_v1` and `DC_Eligibility_v2` to indicate compatibility with specific application versions. #### Validate Data Collections Before Promotion During promotions, it’s important to confirm that the Data Collections used by the application are available in the target environment and match the expected structure and values. If a Data Collection is missing or changed, like renamed columns or modified data types, it can disrupt drop-downs, validations, or other logic that depends on it. Reviewing these details ensures that the promoted version behaves as intended and reduces the risk of unexpected issues across environments. #### Rollbacks Do Not Restore Data Collections Because Data Collections are not part of Application Versioning, rolling back to a previous application version does not revert the Data Collection automatically. ## Managed Assets Files, like PDFs and images in Managed Assets Administration, are not captured in versioned applications. #### Shared Assets Can Cause Inconsistencies If your application references assets that are shared or updated outside the version, those changes will reflect across all versions, potentially breaking layouts or logic. #### Use Version-Specific Assets To maintain consistency, upload version-specific assets and avoid referencing shared files unless necessary. ## Environment-Level Settings Environment-level settings are not captured in versioned applications. #### Environment Settings Exist Outside Application Versions Integrations, RBAC policies, and SSO configurations exist at the environment level and are not tied to any specific application version. #### Environment Settings Must Be Verified Before promoting or rolling back a versioned application, coordinate with your environment administrator to confirm that integrations, RBAC policies, and SSO settings are correctly configured in the target environment. These settings are not tied to application versions and must be managed separately to avoid unexpected behavior. #### Role Permissions User roles and access permissions are defined at the environment level and do not change with application versioning. ## External Services and APIs External services and APIs are not captured with Application Versioning. #### Only References Are Stored Application Versioning captures references to external services and APIs, but not the services themselves. #### Changes to External Services Affect All Versions If an external service is updated or deprecated, it will impact all application versions that rely on it. #### Version Your APIs Separately Use versioned endpoints or service wrappers to ensure compatibility across application versions, and document dependencies clearly. RBAC (Role-Based Access Control) is a method to control system access for authorized users. The role in RBAC refers to the levels of access employees have to a network. Single Sign-On is an authentication scheme that enables users to use one set of login credentials across multiple services. APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services.