> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Resources > Overview of Global and Application Resources, including their usage, dependencies, promotion, and configuration within the platform. ## Overview Resources are categorized into **Global Resources** and **Application Resources**. Each type of resource has unique characteristics that determine its usage, dependencies, and how it’s promoted between environments. Understanding these differences is crucial for efficient application development, management, and deployment. *** ## Global Resources Global Resources are elements designed to be **reused across multiple applications** or business contexts. These resources are often organized within **libraries**, enabling consistency and efficiency by providing a central repository of shared components. ### Key Characteristics of Global Resources * **Reusability**: Global Resources are created with the intention of reuse. They include common design elements, themes, fonts, and other assets that can be referenced by multiple applications. * **Dependency Rules**: Libraries, which store Global Resources, **cannot have dependencies** on other libraries or applications. This ensures that Global Resources remain standalone, maximizing their adaptability across various business cases. * **Application Independence**: These resources are not application-specific, making them versatile for broad use cases. Applications can reference libraries without requiring modifications to the core resources. ### Examples of Global Resources 1. **Design Assets** * **Themes**: Standardized themes provide a consistent look and feel across applications. * **System Assets**: Common media elements stored in the media library (e.g., images, icons) for theme customization. * **Fonts**: Font families that can be reused to maintain branding across different applications. 2. **Plugins** * **Languages**: Language packs or configurations that support multilingual capabilities across applications. * **Notification and Document Templates**: Managed at the global level, although they may be versioned for future releases. * **Out of office**: Configurations or settings that manage out-of-office statuses across the platform. 3. **General settings** * **Users**: User accounts and profiles that can be accessed across multiple applications. * **Roles**: Defined roles that determine user permissions and access levels. * **Groups**: User groupings that facilitate collective management and permissions. * **Audit Log**: Logs that track changes and activities within the platform for security and compliance purposes. 4. **Libraries**: Organized resource containers including **enumerations**, **substitution tags**, and **CMS components** for multi-application use. ### Promotion of Global Resources * **Promotion Workflow**: Global Resources within libraries are promoted separately from applications. They are typically **imported into the Designer UI** in target environments as part of their own libraries. * **Configuration Management**: When libraries are promoted, existing configurations, such as **generic parameters**, are replaced by application-level configurations in the target environment. *** ## Application Resources Application Resources are resources specific to a particular **business use case**. Unlike Global Resources, these resources are confined to the context of the application they belong to, allowing for tailored configurations and dependencies on one or more libraries. ### Key Characteristics of Application Resources * **Business Specificity**: Application Resources are tailored to a specific application, addressing unique business requirements. * **Dependencies on Libraries**: Applications can reference libraries to access Global Resources, allowing for customization and adaptability. * **Configurability**: Application-specific configurations are defined at the development stage, and values can be updated as needed in upper environments through environment variables or direct parameter overrides. ### Examples of Application Resources 1. **Processes**: Defined BPMN workflows specific to the application's business logic. 2. **CMS Components**: Custom CMS enumerations, substitution tags, and media items unique to the application. 3. **Task Management**: * **Views**: Configurable interfaces to display task-related data based on process definitions. * **Hooks**: Users with task management permissions can create hooks to trigger specific process instances, such as sending notifications when events occur. * **Stages**: Stages that allow task progression through different statuses. * **Allocation rules**: Define how tasks are assigned to users or teams. 4. **Integration Designer**: * **Systems**: A system is a collection of resources—endpoints, authentication, and variables—used to define and run integration workflows. * **Workflows**: A workflow defines a series of tasks and processes to automate system integrations. Within the Integration Designer, workflows can be configured using different components to ensure efficient data exchange and process orchestration. 5. **Configuration Parameters**: Application-specific rendering settings like `applicationUuid`, `locale`, `language`, and `process parameters`. 6. **Application Builds**: Builds represent finalized versions of the application, including all associated metadata and linked library versions. 7. **Application Settings**: Configure various aspects of a project like platform type, default theme, formatting, etc. ### Promotion of Application Resources * **Promotion Workflow**: Only **builds** (not commits) are eligible for promotion to upper environments. Builds are exported from the development environment and imported into target environments via the Designer UI. * **Design Asset Handling**: During import, any referenced design assets are created if absent but are not updated, ensuring consistency in upper environments. * **Configuration Parameters Overrides**: Upper environment values replace development defaults, and these can be managed through environment variables, enabling flexibility without direct development environment access. ## Related topics - [Application manager setup](/4.6.0/setup-guides/application-manager.md) - [Versioning](/4.6.0/docs/projects/managing-applications/versioning.md) - [FlowX.AI 4.7.0 Release Notes](/release-notes/v4.x/v4.7.x-lts/v4.7.0-february-2025/v4.7.0-february-2025.md) - [FlowX.AI 4.7.1 Release Notes](/release-notes/v4.x/v4.7.x-lts/v4.7.1-march-2025/v4.7.1-march-2025.md) - [Projects](/4.6.0/docs/projects/managing-applications/application.md)