--- title: "Application Lifecycle" slug: "application-lifecycle" tags: ["applications"] updated: 2026-09-14T15:13:55Z published: 2026-09-14T15:13:55Z canonical: "docs.unqork.io/application-lifecycle" --- > ## 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. # Application Lifecycle Unqork applications move through a series of environment levels before reaching end-users. Understanding this lifecycle helps Creators avoid Production mistakes and recover quickly when issues arise. ## Environment Levels Unqork organizations operate across multiple environment levels. Each level serves a distinct purpose, and resources move between them through a process called promotion. The standard progression is: **Staging → Quality Assurance (QA) → User Acceptance Testing (UAT) → Production**. | Environment | Purpose | Data | | --- | --- | --- | | **Staging** | Active development and configuration. | Test data only | | **QA** | Testing and quality verification. | Test data only | | **UAT** | End-user acceptance testing before Production. | Test data only | | **Pre-Production** (optional) | Final validation using the Production codebase. | Test data only | | **Production** | Live application accessible to end-users. | Live client data | For detailed environment descriptions, see [Environment Levels](/unqorkai/docs/environment-levels). ## Promotion Pipeline Promotion is how resources move from one environment to the next. A Creator with the appropriate permissions uses the **Promote** action to move a module, service, style, or other resource to a higher environment. ### How Promotion Works 1. **Creators** configure and test a resource in Staging. 2. The Creator promotes to QA, where **QA engineers** verify functionality and quality. 3. After QA passes, the Creator promotes to UAT, where **business stakeholders or product owners** accept the build. 4. After UAT sign-off, a **release manager** promotes to Production. Each promotion is a deliberate action. Resources do not move between environments automatically. The platform does not enforce this sequence. Creators with promote permissions can promote to any available target environment, including from Staging directly to Production. Following the full pipeline is a best practice that ensures each stage of testing is completed before changes reach end-users. ### Promotion Limitations Promotion moves the resource but not its dependencies. If a module depends on a service, style, or another module, those dependencies must be promoted separately before promoting the module. Promoting a module without its dependencies can cause issues in the target environment. Before promoting to Production: - Verify all services the module calls are promoted to Production. - Verify all styles the module uses are promoted to Production. - Verify all modules the module depends on are promoted to Production. - Confirm environment configuration in the target environment matches expectations (authentication settings, session management, integrations). > [!WARNING] > Environment configuration does not transfer when resources are promoted. Each environment has its own independent configuration, managed in [Environment Administration](/unqorkai/docs/environment-administration). ## Working in Production Production is the only environment where live client data is stored and where end-users access the application. Following software development best practices, development should never take place in Production. ### Production Creator Access Creators with the appropriate permissions can open modules directly in Production. However, Production blocks draft-based development, which is the standard workflow in pre-production environments. Any changes saved in Production go directly to the live published version with no draft buffer and no automatic rollback. > [!CAUTION] > All development should take place in Staging and move to Production through the promotion pipeline; never directly in Production. The platform provides no warnings or confirmation dialogs when saving in Production, and every change goes live immediately. If a Creator saves a breaking change in Production, end-users encounter it with no automatic rollback. See [Accidental Edit in Production](/unqorkai/docs/application-lifecycle#accidental-edit-in-production) if this happens. ### Recommended Approach All development should begin in Staging and move to Production through the promotion pipeline. Following the pipeline ensures changes are tested before they reach end-users and preserves a known-good version in lower environments for restoration if needed. ### What the Platform Blocks in Production The platform enforces specific restrictions server-side. The following actions are not available in Production: - Creating, deleting, or publishing branches - Combining branches or completing a merge - Enabling versioning through Application Settings - Writing to Application Dependencies - Smart Component Draft These restrictions also apply to **Pre-Production**, which runs the Production codebase. For the full list, common tasks (including changing the default style), and recovery steps, see [Working in Production](/unqorkai/docs/working-in-production). ## Common Mistakes ### Editing Directly in Production **What happens**: A Creator opens a module directly in Production, makes changes, and saves. The changes go live immediately, with no testing, no review, and no automatic rollback. If the change breaks the module, end-users encounter the broken version in the production application until the issue is resolved. **How to avoid it**: Always verify the current environment before making changes. Confirm the URL. Standard Unqork-hosted environments include the environment level in the URL (for example, `-prod.unqork.io` for Production). If in Production, close the module and open it in Staging instead. Making changes in Staging ensures the update moves through the full promotion pipeline (QA, UAT, and then Production), the same as any other change. ### Forgetting to Promote Dependencies **What happens**: A Creator promotes a module to Production, but the service it calls is still on an older version in Production. The module references functionality that does not exist in the Production service, causing issues for end-users. **How to avoid it**: Before promoting any resource, audit its dependencies and promote them in sequence. Promote services and styles before the modules that use them. ### Assuming Configuration Transfers **What happens**: A Creator configures an integration or authentication setting in Staging and promotes the module through the pipeline to Production. The integration fails in Production because the configuration (API keys, allowed origins, session settings) was never set up in the Production environment. **How to avoid it**: Treat each environment's configuration as independent. After promotion, verify that environment-level settings in the target environment are correctly configured for the promoted resource. ### Promoting Incomplete Work **What happens**: A Creator promotes a module mid-development, intending to finish later. The incomplete module reaches Production and causes issues or exposes an unfinished interface to end-users. **How to avoid it**: Only promote modules that are fully tested and ready. Use QA and UAT environments to prevent incomplete work from reaching Production. ## Recovering from Production Issues ### Accidental Edit in Production If a Creator saves a change directly to a Production module: 1. **Identify the last known-good version** in a lower environment (Staging or UAT). 2. **Promote the known-good version** from the lower environment back to Production. Promoting overwrites the accidental change with the correct version. 3. **Verify the restored version** by checking the module in Production before end-users encounter issues. > [!WARNING] > Do not attempt to fix the module by making additional edits in Production. Making additional edits compounds the issue. Restore from a lower environment instead. ### Broken Module After Promotion If a module breaks after promotion to Production: 1. **Promote the previous working version** from the lower environment to Production. 2. **Investigate the issue** in Staging or QA, not in Production. 3. **Fix and test** in the lower environment before promoting again. ### Dependency Missing in Production If a module fails because a dependency is missing or outdated in Production: 1. **Identify the missing or outdated dependency** (service, style, or module). 2. **Promote the correct version** of the dependency to Production. 3. **Verify the module** after the dependency is in place. ## Best Practices - **Never develop in Production.** All changes begin in Staging. - **Always check the current environment before saving.** Confirm the URL before making any change. - **Promote dependencies first.** Promote services and styles before the modules that depend on them. - **Test at every level.** QA and UAT exist to catch issues before they reach end-users. - **Keep lower environments in sync.** Staging should always reflect what is in Production so it can serve as a reliable restore point. - **Never assume configuration transfers between environments.** Verify environment settings after every promotion. --- **Changelog** | Date | Change | | --- | --- | | 2026-08-29 | Added Production restrictions list and Working in Production link; expanded See Also (EN-8072). | | 2026-08-28 | See Also link casing and format fixes (EN-8063). | | 2026-08-25 | POV fixes; "UnqorkAI platform navigation" → "platform navigation"; See Also descriptions and /public/ paths added. | End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. The Production environment is the final stage of the development process. Use this environment to promote tested and functioning application so your end-user can interact with it. The Staging environment is the first level of application building in Unqork. Use it to build, test, and style your applications. Use your QA (quality assurance) environment to test applications to ensure reliability, security, and functionality before releasing them to the end-user. Use the UAT (user acceptance testing) environment to realistically test and navigate your applications as end-users would use them. Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. A definition An app versioning Merge combines changes from one branch or draft, into another branch, draft, or published version of an application. In Unqork an application is a program used to perform specific tasks. An application can be one of two types: workflow or module. A URL (uniform resource locator) is a unique identifier used to locate a resource on the internet. Also known as a web address. 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. A key-value pair is a fundamental data structure where a unique "key" is associated with a specific "value," used for organizing and retrieving data efficiently, like in dictionaries or databases.