# Introduction ### Overview AppControl is the governance layer for Mendix. It provides continuous security, quality, and compliance across the full lifecycle of your applications — from development through deployment and production operations. Rather than adding governance as an afterthought, AppControl embeds control directly into your Mendix landscape. It continuously evaluates policies, audit events, releases, and operational signals to ensure you are not only moving fast — but staying in control. AppControl operates across four integrated lifecycle domains: ### Develop Continuously scan and evaluate your applications against defined security, quality, and development standards. Detect structural risks, policy violations, and dependency issues early in the lifecycle. ### Deploy Enforce controlled releases with approvals, policy validation, and full traceability. Capture audit events for deployments, configuration changes, and revision updates to ensure accountable change management. ### Monitor Maintain operational oversight with alerts, vulnerability insights, system signals, and audit visibility. Detect deviations before they become incidents and maintain evidence for compliance. ### Control Define governance controls, select required coverage levels, and continuously evaluate whether change management, access, configuration, and other processes are functioning as intended. Controls are evidence-driven and automatically assessed across selected environments. *** ### Built for Enterprise Governance AppControl is designed for organizations where Mendix supports business-critical processes. It enables: * Continuous compliance instead of periodic audits * Traceable and controlled releases * Structured evidence for frameworks such as ISO 27001 and SOC 2 * Clear visibility across apps, teams, and environments Governance becomes measurable, enforceable, and scalable. *** ### Tailored to Your Role Whether you are responsible for platform governance, security, quality assurance, or operations, AppControl provides the visibility and control needed to manage Mendix at scale. Explore the Getting Started guides to configure policies, controls, and lifecycle governance aligned with your organization’s requirements. {% content-ref url="/pages/Q0QZCWAUzAmKv72Nx7w9" %} [Getting Started](/overview/getting-started) {% endcontent-ref %} ## Quick links {% content-ref url="/pages/0eqpBXg7rhjv8tM5yBb9" %} [Features](/overview/features) {% endcontent-ref %} {% content-ref url="/pages/4j4ctGqI7EIzIaZ2ymAJ" %} [Product architecture](/overview/product-architecture) {% endcontent-ref %} ## Getting Started (for AppControl system administrators) Are you responsible for managing the configuration of AppControl? We've put together some helpful guides for you to get setup with our product quickly and easily. {% content-ref url="/pages/8sjtzMYC9tnGoajVUgU7" %} [Initial set up](/overview/initial-set-up) {% endcontent-ref %} {% content-ref url="/pages/uuT07swjISfA277rONZG" %} [Give permissions](/overview/initial-set-up/give-permissions) {% endcontent-ref %} {% content-ref url="/pages/Fa7rlShzxjSRCCHdRW7z" %} [Add users](/overview/initial-set-up/add-users) {% endcontent-ref %} # Features AppControl is packed with features to help simplify the management of Mendix apps. ## Alerts The alerts dashboard gives you a single unified dashboard to report on the status of your apps, bringing together hosting platform status, policy compliance, task status, and release status in one place. {% content-ref url="/pages/5MczwjZDtClMaAPiQjHX" %} [Alerts](/dashboards/alerts) {% endcontent-ref %} ## Policies Policies give you control over how Mendix is used by your developers: enforcing minimum Mendix versions, approved Marketplace components, checking for common security mistakes, and much more! {% content-ref url="/pages/5dWIRyg24QEe5urY2EQa" %} [Broken mention](broken://pages/5dWIRyg24QEe5urY2EQa) {% endcontent-ref %} ## Releases Pipelines enable you to standardize how your Mendix apps are built and deployed, making sure that policies are enforced, tests are passed, and that new releases are approved and tracked. {% content-ref url="/pages/RNBsj5asjVlqgGINRqby" %} [Releases](/dashboards/releases) {% endcontent-ref %} ## Tasks Tasks give you insight and control over manual tasks needed to operate your Mendix apps such as certificate and functional account renewals, compliance activities, handover to operations checklists, and whatever else you need to make Mendix fit your organization. {% content-ref url="/pages/6p2oQ41MlmVSF8S4NZR0" %} [Tasks](/dashboards/tasks) {% endcontent-ref %} ## Repository The app repository automates the tedious task of keeping app documentation and information up to date. It is your central place for documenting apps, tracking used software components, viewing integrations, and comparing app settings. {% content-ref url="/pages/qypZKxVmpCxgtW6bN7o6" %} [Insights](/dashboards/insights) {% endcontent-ref %} # Product architecture AppControl is an add-on solution for organizations that use Mendix. AppControl enables organizations to manage large landscapes of Mendix applications based on centralized policies and standards. Although the Mendix Platform provides many different features and services, organizations using Mendix at scale often have additional requirements that can't be met by the basic Mendix Platform offering. Additionally, for organizations that don't use the Mendix Cloud for hosting, most of the standard Mendix Platform features are simply not available. AppControl is delivered as a Mendix application package (.MDA file). This package can be deployed to any Mendix server (public cloud or private cloud). The illustration below shows the basic components of AppControl and how they communicate with each other: MxOM Product Architecture * **AppControl.** This is a Mendix application that you deploy to a licensed Mendix server. Blue Storm does not provide a Mendix license. You must install a AppControl product license that you purchase from Blue Storm. This server does all app monitoring and processing of app data. * **AppControl Insights Repository.** This is a web service provided by Blue Storm and is included as part of your AppControl subscription. This contains information about Mendix Marketplace components, Mendix runtimes, vulnerabilities, and log solutions. This service is called regularly by AppControl to update its list of known components and what their current status is. * **Hosting Platforms.** This is where you host your Mendix applications. Most Mendix customers use the Mendix Cloud, but this could also be your own private cloud hosted in Azure or AWS, or local hosting on Windows or Linux servers. AppControl polls hosting platforms for the list of hosted apps, environments, and their current status. AppControl supports commonly used hosting platforms, and it is possible for Blue Storm to develop connectors for custom clouds. * **App Repositories.** There is where you store your app project files. Most Mendix customers use Team Server, but this could also be your own private GIT or SVN server. AppControl scans your repositories for a list of revisions for each of your apps. Additionally, AppControl downloads and scans various project files to check if they are compliant with your policies. # AppControl Repository The AppControl Repository is a centralized database maintained by Blue Storm that contains information on vulnerabilities, component versions, and log solutions. It is updated both manually and automatically to ensure accuracy and completeness. **Data Sources and Updates** The repository is automatically updated with new information from the following sources every 24 hours: * **Google OSV Index** – A widely used database for open-source component vulnerabilities (Java and Javascript Libraries). * **Siemens Security Advisory List** – Provides security advisories relevant to Mendix components (Modules and Mendix Runtimes) * **Mendix Marketplace** – Contains information about available Mendix components, their versions, and known vulnerabilities. * **Maven Repository** – A widely used repository for Java dependencies, included in many components used in Mendix apps. * **NPM Registry** – A widely used repository for Javascript libraries, included in many components used in Mendix apps. **Component Detection and Identification** AppControl detects the components used in applications through: * **Component Metadata Analysis:** Extracting metadata from application files to identify used components (E.g. manifest files). * **File Fingerprinting:** Generating SHA1 and SHA256 hashes of files and comparing them to known components in the repository. To improve component detection, AppControl shares anonymous fingerprinting information with Blue Storm. If an unidentified component is detected, Blue Storm support is notified to manually analyze and classify the component. **Repository Synchronization** Each customer instance of AppControl synchronizes with the central repository once per day to ensure it has the latest information for policy checks and compliance monitoring. # Policy Checks AppControl enforces compliance by automatically checking policies whenever a new revision of an application is deployed. Policies consist of individual policy rules, which are categorized into two types: * **Single-Run Rules:** These rules are checked once per revision and typically apply to aspects such as app models, microflows, pages, and other structural elements. * **Recurring Rules:** These rules are continuously monitored beyond the initial deployment. They include checks for component vulnerabilities, support status of used components, and other external dependencies. Recurring policy checks are performed at two key moments: 1. When a new revision of an application is deployed. 2. Every 24 hours to ensure that all applications remain compliant with the latest updates. The data required for policy evaluations, including vulnerability information and support status of components, is sourced from the AppControl repository. This repository is updated once per day, ensuring that policy checks always use the most current information available. Policy checks are designed by Blue Storm and are based on **Mendix Best Practices, Community Best Practices, and customer feedback**. After being developed and thoroughly tested, new policy checks are included in future AppControl product releases to continuously enhance compliance monitoring and enforcement. # Initial set up The initial set up of MxOM consists of the following 5 easy steps: {% content-ref url="/pages/jS9cbTegSuh9DoXvBy3H" %} [Install package](/overview/initial-set-up/install-package) {% endcontent-ref %} {% content-ref url="/pages/A2Rb5fUZUJZKbXqGbZyv" %} [Configure system](/overview/initial-set-up/configure-system) {% endcontent-ref %} {% content-ref url="/pages/EXXX6mAdMcvfM7nxc1pN" %} [Add apps](/overview/initial-set-up/add-apps) {% endcontent-ref %} {% content-ref url="/pages/Fa7rlShzxjSRCCHdRW7z" %} [Add users](/overview/initial-set-up/add-users) {% endcontent-ref %} {% content-ref url="/pages/uuT07swjISfA277rONZG" %} [Give permissions](/overview/initial-set-up/give-permissions) {% endcontent-ref %} # AppControl User Everything that AppControl does is executed by a single Mendix Platform user. Before you can get started with AppControl you need to create this user (the 'AppControl' user). The AppControl user needs to be added to each app and environment in the Mendix Platform that you want to manage with AppControl. This user needs to have sufficient rights to be able to use all features in AppControl. The table below shows the rights needed to perform each feature. For each feature both the platform access (the rights configured via the Mendix Platform) and the PAT (Personal Access Token) rights are shown. To grant AppControl correct access to your Mendix apps you must perform the following steps: 1. Create a Mendix Platform user (). 2. Add this user to the team for each app you want to manage and give it the role 'Business Engineer' (). 3. For each environment that you want AppControl to manage, give the user the encessary environment rights (see the table below) (). 4. Create an API key for the user. () 5. Create a PAT (Personal Access Token) with the necessary rights (see table below for rights). () 6. Go to the personal data page () for the AppControl user and copy the 'OpenID' attribute. You will need this when adding a [hosting platform](/administration/system/system-configuration/hosting-platform) to AppControl.
The user you have created will be used later on during the installation of AppControl to add the apps you want to manage (See '[Add apps](/overview/initial-set-up/add-apps)' for more details). | Feature | Environment Rights | PAT Rights | | -------------------------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | View App | API Rights |

Project API

  • mx:app:metadata:read
  • mx:app:team:write
| | View / Process Models | |

Model Repository

  • mx:modelrepository:repo:write
  • mx:modelrepository:write

Model Server

  • mx:modelrepository:write
| | View Components | |

Marketplace

  • mx:marketplace-content:read
| | Manage Environment Configuration, Excute Pipelines |

Transport Rights

Access to Backups

|

Deployment Mendix Cloud

  • mx:deployment:write

Deployment Private Cloud

  • mx:deployment:write

Build Private Cloud

  • mx:privatecloud-build:write
| | Analyze User & App Logs | Access to Monitoring |

| | Receive Hosting Platform Alerts | |

Webhook Portal

  • mx:webhook:read
  • mx:webhook:write
| # Install package AppControl is delivered as a Mendix application package (.MDA file). To use AppControl you will need to download the package and deploy it to a licensed Mendix Cloud node or a Mendix server running in your private cloud.
Step 1: Prerequisites Before installing AppControl make sure you have the following: * A licensed Mendix Cloud (minimum size 'S', preferably size 'M') or private cloud node where you can deploy the AppControl package. * If you have firewalls between the node where you will deploy AppControl and the Internet, make sure the following ports are open: * * * * * * A registered account in the Blue Storm Customer Portal. This will be provided to you by Blue Storm.
Step 2: Download package Login to the Blue Storm customer portal ([https://support.bluestorm.io/](https://support.bluestorm.io)), browse to 'Releases', and download the latest release. AppControl is delivered as a Mendix MDA package file.
Step 3: Deploy package Depending on your hosting platform, upload the AppControl MDA package to your Mendix server. Afterwards, perform the steps below: 1. Configure the following constants: * **Core.EncryptionKey** : Use a random 32 character key, and never change it. * **Core.MxOM\_APIUser** : API user name provided by Blue Storm. * **Core.MxOM\_APIPassword** : API password provided by Blue Storm. * **Core.AuthenticationService** : The authentication service to be used for logging into MxOM. Possible values are: * **LOCAL** : Local user accounts only. * **MENDIX\_SSO** : Use Mendix SSO for authentication. * **SAML** : Use SAML for authentication. * **Logging.LogHistoryDays** : 60 2. Configure the following custom runtime settings: * **com.mendix.core.ProcessedTasksCleanupAge** : 86400000 * **com.mendix.webui.StateSizeWarningThreshold** : 10000 3. Enable all scheduled events. 4. Start the server and login using 'AppControlAdmin'. 5. If you configured AppControl to use SSO for authenticating users, configure SSO from the Administration > Accounts page. 6. Create a new administrator user and give this user the ‘PlatformAdministrator’ role. Login as the new user.
# Configure system After deploying AppControl you will need to configure the following items. It is import that these configuration steps are completed before you start adding apps or users. Contact Blue Storm support to request a license ID and activation code if you haven't already received one. When you have this, follow the instructions below to install your license: {% content-ref url="/pages/3j7BupEr2bi9WtZfPJqt" %} [Product License](/administration/system/product-license) {% endcontent-ref %} After installing your license you need to configure your notification settings. This ensures that AppControl is able to send out e-mails to system administrators as well as other users of the system. Follow the instructions below to configure your notification settings: {% content-ref url="/pages/LHX4tpuNLSuAyWccR0Vs" %} [Notifications](/administration/system/notifications) {% endcontent-ref %} # Add hosting platforms A hosting platform is a specific operating environment for Mendix apps. The common hosting platforms used by Mendix customers include: * Mendix Cloud * Mendix Cloud Dedicated * Mendix for Kubernetes (Connected / Standalone) * Mendix for Azure * Mendix Private Platform * SAP BTC In addition to these standard cloud platforms customers are also free to setup their own private hosting platform using Kubernetes, OpenShift, or other Docker-based technologies. Often customers will use standard cloud hosting services from AWS or Azure for this purpose. Within AppControl it is necessary to add at least 1 hosting platform to your system configuration. This informs the system that it should scan the configured hosting platform for Mendix apps and environments hosted on that platform. Once apps and environments are detected they can be managed by AppControl. Use the [System Configuration](/administration/system/system-configuration) page to add a hosting platform. The sections below show which AppControl features are supported by each hosting platform type.
Mendix Cloud | Feature Area | Feature | Supported | | ------------ | ----------------------------------------------------------------- | :-------: | | Core | App Auto-discovery | ✅ | | | Environment Auto-discovery | ✅ | | Alerts | Hosting Alerts | ✅ | | | Policy Alerts | ✅ | | | Release Alerts | ✅ | | | Task Alerts | ✅ | | | Log Alerts | ✅ | | Policies | Check Policies | ✅ | | Releases | Approval, Notification, Check Policy, Assign Task, Call API Tasks | ✅ | | | Build, Deploy Tasks | ✅ | | | Start / Stop Task | ✅ | | | Backup Task | ✅ | | Tasks | Create / Assign Tasks | ✅ | | Insights | Component Insights | ✅ | | | User Insights | ✅ | | | Log Insights | ✅ | | | Reports | ✅ |
Mendix Cloud Dedicated | Feature Area | Feature | Supported | | ------------ | ----------------------------------------------------------------- | :-------: | | Core | App Auto-discovery | ✅ | | | Environment Auto-discovery | ✅ | | Alerts | Hosting Alerts | ✅ | | | Policy Alerts | ✅ | | | Release Alerts | ✅ | | | Task Alerts | ✅ | | | Log Alerts | ✅ | | Policies | Check Policies | ✅ | | Releases | Approval, Notification, Check Policy, Assign Task, Call API Tasks | ✅ | | | Build, Deploy Tasks | ✅ | | | Start / Stop Task | ✅ | | | Backup Task | ✅ | | Tasks | Create / Assign Tasks | ✅ | | Insights | Component Insights | ✅ | | | User Insights | ✅ | | | Log Insights | ✅ | | | Reports | ✅ |
Mendix for Kubernetes (Connected) {% hint style="info" %} Not all AppControl features are currently supported on Mendix for Kubernetes. Be aware that some unsupported features simply fail silently and thus may not be obvious to the user. {% endhint %} | Feature Area | Feature | Supported | | ------------ | ----------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------: | | Core | App Auto-discovery | ✅ | | | Environment Auto-discovery | 🛑 Environments must be added manually by using the environment ID found in the Mendix Private Portal. See the Environments page in these docs for details. | | Alerts | Hosting Alerts | 🛑 | | | Policy Alerts | ✅ | | | Release Alerts | 🛑 | | | Task Alerts | ✅ | | | Log Alerts | 🛑 | | Policies | Check Policies | ✅ | | Releases | Approval, Notification, Check Policy, Assign Task, Call API Tasks | ✅ | | | Build, Deploy Tasks | 🛑 | | | Start / Stop Task | 🛑 | | | Backup Task | 🛑 | | Tasks | Create / Assign Tasks | ✅ | | Insights | Component Insights | ✅ | | | User Insights | 🛑 | | | Log Insights | 🛑 | | | Reports | ✅ |
# Add apps Your Mendix apps are detected automatically by AppControl once you add one or more hosting platforms to the system. AppControl uses the credentials and URL that you provide to poll the hosting platform for a list of apps hosted on that platform. Use the instructions below to add hosting platforms to AppControl: {% content-ref url="/pages/MGbSMtk5QVl18YWwoPuZ" %} [System Configuration](/administration/system/system-configuration) {% endcontent-ref %} After you have added your hosting platforms to AppControl, wait about 10-15 minutes for all apps to appear in the app dashboard. # Add users Users can either be added manually to AppControl from the accounts page or they can be provisioned automatically if you have configured SSO. Follow the instructions below to add users to AppControl: {% content-ref url="/pages/48VtUuOk8ng1pzUrLmrj" %} [Accounts](/administration/system/accounts) {% endcontent-ref %} After you have added users to AppControl you will need to configure their permissions before they can view and manage apps. # Give permissions There are 2 steps to giving permissions in AppControl: 1. **Assign roles.** The first step is to assign 1 or more user roles to a user. User roles provide access to role-specific functionality. Except for the Platform Administrator role, roles do not affect which apps a user can view. Roles are assigned from the Administration > Accounts page. 2. **Assign apps.** The second step is to assign apps to the user so that they can view and manage those apps. This is done by assigning users to 1 or more groups, or to specific apps. For information on users roles and assigning apps see the following documentation: {% content-ref url="/pages/Fcv2J6C2v9NkskvtjDnc" %} [User Roles & Access](/overview/user-roles-and-access) {% endcontent-ref %} # User Roles & Access AppControl uses two access layers: 1. **User role** decides which product areas a user can use. 2. **App role** decides what a user can do in each app they can see. Most users need both. * A user role without app access means the user can sign in, but may see no apps. * App access without the right user role means the user can see an app, but some actions stay unavailable. * **Platform Administrator** is the exception. This role already has full visibility. {% hint style="info" %} Rule of thumb: * **User role** = feature access * **App role** = app-level actions * **App Groups** = delegation (policy / release / task management) and visibility * **User Groups** = app role assignment at scale {% endhint %} ### Access model at a glance {% code title="How AppControl decides access" overflow="wrap" %} ``` User signs in ↓ User role unlocks product areas ↓ App access makes apps visible ↓ App role unlocks actions in each visible app ``` {% endcode %} {% code title="Ways a user gets app access" overflow="wrap" %} ``` Platform Administrator └─ sees all apps Other users ├─ Direct app access │ └─ one user → one app ├─ App group membership │ └─ one user → all apps in one app group → App Member └─ User group membership └─ many users → many apps → configurable app role ``` {% endcode %} ### Choose the right access path {% columns %} {% column %} #### App groups Use app groups to delegate management. * One app belongs to one app group. * Group members get **App Member** on all apps in that group. * Group administrators manage group members and group resources. See [App Groups](/administration/app-groups). {% endcolumn %} {% column %} #### User groups Use user groups to grant app roles to many users. * One user group can contain many apps. * Members inherit access on every app in the group. * Each member can be **App Owner**, **App Administrator**, **App Member**, or **App Operator**. See [User Groups](/administration/user-groups). {% endcolumn %} {% endcolumns %} #### Direct app access Use direct app access for one-off cases. This is useful when a user needs access to one app only. ### User roles User roles control which product areas a user can use.
RoleUse this forAccess
Platform AdministratorCentral platform managementManage system settings, groups, access, all policies, all pipelines, and all tasks. View all apps and repository data.
Group AdministratorDelegated management for one or more app groupsManage group members, user access, group policies, group pipelines, and group tasks for assigned groups.
App AdministratorApp-level operationsManage app policies, app pipelines, and app tasks for apps the user can access.
App ViewerRead-only accessView visible apps and their related dashboards and data.
Policy ViewerPolicy and insight reviewView policy and insight data for visible apps. Policy changes still require the right app role.
No AccessDisabled or inactive usersNo access to AppControl.
{% hint style="warning" %} **App Administrator** exists in two places: * as a **user role**, it unlocks app management features * as an **app role**, it grants admin rights on a specific app A user needs both to fully manage an app. Note that if you add a user as an App Administrator to an app, that the App Administrator user role will automatically be granted to them. {% endhint %} ### App roles App roles apply per app.
RoleUse this forAccess
App OwnerBusiness or service ownershipManage app info and approve releases. View policy, release, task, environment, and repository information.
App AdministratorOperational ownershipManage app policies, app pipelines, app tasks, create releases, and approve releases. View policy, release, revision, environment, configuration, task, and repository information.
App MemberGeneral team accessView policy, release, environment, task, and repository information.
App OperatorRelease executionCreate releases. This can be limited to specific environment types.
{% hint style="info" %} Users with the **Policy Viewer** user role only get policy access for apps where they also have app visibility. {% endhint %} ### Common combinations These combinations cover most setups: * **Platform Administrator** — full platform access and full app visibility. * **Group Administrator** + assigned app group — delegated management for one domain or team. * **App Viewer** + app group membership — read-only access to every app in that group. * **App Administrator** user role + **App Administrator** app role — full app-level operations for a specific app. * **Policy Viewer** + **App Member** — review policy results and insights without release or task management. ### Common scenarios #### Give a team read-only visibility for a set of apps Add the users as members of an app group. Give them the **App Viewer** user role. #### Give an operations team release rights across many apps Create a user group with those apps. Add the users to the user group with the **App Operator** app role. #### Delegate management for one app domain Create an app group. Assign a **Group Administrator** to that group. Use user groups when the team also needs app roles across the apps in that group. ### Troubleshooting access issues #### The user can sign in, but sees no apps Check whether the user has app access through one of these paths: * direct app access * app group membership * user group membership #### The user can see an app, but cannot perform an action Check both layers: * does the user role allow the product area? * does the app role allow the action on that app? #### The user was added to an app group, but still lacks release or admin rights App group membership only grants **App Member**. Use a user group or direct app access when the user needs **App Owner**, **App Administrator**, or **App Operator**. ### See also * [Getting Started](/overview/getting-started) * [Platform Administrator](/overview/getting-started/platform-administrator) * [Group Administrator](/overview/getting-started/group-administrator) * [App Groups](/administration/app-groups) * [User Groups](/administration/user-groups) # Getting Started The getting started guides help each role focus on the right AppControl features. Choose the guide that matches your role: * **Platform Administrator.** Manage platform-wide settings, standards, hosting, and licenses. * **Group Administrator.** Manage app groups, access, and standards for a delegated set of apps. * **App Owner.** Manage service ownership for one or more Mendix apps. * **App Administrator.** Manage daily app operations, releases, policies, and tasks. * **Developer.** Build Mendix apps in line with organizational standards. ### Role guides * [Platform Administrator](/overview/getting-started/platform-administrator) * [Group Administrator](/overview/getting-started/group-administrator) * [App Owner](/overview/getting-started/app-owner) * [App Administrator](/overview/getting-started/app-administrator) * [Developer](/overview/getting-started/developer) ### Task-based tutorials Use [Tutorials](/overview/tutorials) when you want step-by-step help for a specific workflow. # Platform Administrator AppControl supports Mendix platform administrators to automate and control the usage of the Mendix platform in their organization. After performing the [initial setup](/overview/initial-set-up), the following are useful features for your role: * **Global Policy.** The global policy in AppControl checks the state of all deployed Mendix apps to ensure that they are compliant with your standards. After installing AppControl a default set of policy rules is used. Configure the global policy to bring it in line with the needs of your organization (E.g. minimum Mendix versions, naming standards, etc.). {% content-ref url="/pages/oW05ZvSvyvO5EYS3EQVp" %} [Policies](/administration/policies) {% endcontent-ref %} * **Global Pipelines.** Global pipelines can be configured to enforce your global policies, and to ease the build and deployment process for DevOps teams. By default there are no global pipelines, and thus you will need to configure at least one global pipeline if you want teams to use a standardized process for building and deploying apps. {% content-ref url="/pages/xabNN6JrKEbEhHjvhSnj" %} [Pipelines](/administration/pipelines) {% endcontent-ref %} * **Global Tasks.** Global tasks enable you to keep track of manual activities that need to be performed per app (E.g. compliance activities, certificate renewals, etc.). If there are common tasks that must be performed by all app owners or app administrators, create a global task for this need and assign it. {% content-ref url="/pages/YQ8RDqZkLJWmzJMjZKsg" %} [Tasks](/administration/tasks) {% endcontent-ref %} * **Insights.** Insights gives you insight into the Mendix versions and Mendix Marketplace components used by all Mendix apps in your organization. Use Insights to answer questions such as 'Which apps are still using Mendix 8?' or 'Which apps are using the SAML module version older than 3.0?'. {% content-ref url="/pages/qypZKxVmpCxgtW6bN7o6" %} [Insights](/dashboards/insights) {% endcontent-ref %} * **App Groups.** As your Mendix landscape grows it can be useful to assign responsibilities for groups of apps to distributed teams. In AppControl you can create app groups for this need. By creating an app group you can give rights to a group administrator to create group policies, group pipelines, and group tasks. {% content-ref url="/pages/XRxPiUZ8aV1jhA14hIvI" %} [App Groups](/administration/app-groups) {% endcontent-ref %} * **User Groups. User** groups give you the ability to grant access rights in AppControl to groups of persons to a group of apps. This can be useful if (for instance) you have a group of apps that are managed by an internal or external app management team. {% content-ref url="/pages/CL3mMEkxwz8vNYdiQedo" %} [User Groups](/administration/user-groups) {% endcontent-ref %} ### Recommended tutorials Start with the workflows that set standards and delegate ownership. * [Configure a global policy](/overview/tutorials/policies/configure-a-global-policy) * [Create a global pipeline](/overview/tutorials/releases/create-a-global-pipeline) * [Create and assign a global task](/overview/tutorials/tasks/create-and-assign-a-global-task) * [Create an app group](/overview/tutorials/administration/create-an-app-group) * [Create a user group](/overview/tutorials/administration/create-a-user-group) # Group Administrator AppControl supports Mendix group administrators to manage a delegated set of apps. Before you start, a Platform Administrator must assign you to at least one app group. Your permissions only apply to the groups you manage. For role details, see [User Roles & Access](/overview/user-roles-and-access). The following are useful features for your role: * **App Groups.** Use [App Groups](/administration/app-groups) to manage group members and review the apps in your group. * **User Groups.** Use [User Groups](/administration/user-groups) to assign app access across the apps in your group. * **Policies.** Use [Policies](/administration/policies) to create group-specific standards when needed. * **Pipelines.** Use [Pipelines](/administration/pipelines) to standardize releases for the apps in your group. * **Tasks.** Use [Tasks](/administration/tasks) to manage recurring work across your group. ### Recommended tutorials Start with the workflows that keep your group secure and moving. * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Assign app access with a user group](/overview/tutorials/administration/assign-app-access-with-a-user-group) * [Create a group policy](/overview/tutorials/policies/create-a-group-policy) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) # App Owner AppControl supports Mendix app owners to control the quality, maintainability and daily operation of their apps. Before you can use AppControl to manage your apps, the AppControl platform administrator will need to assign you as an app owner for one or more apps. Afterwards, the following are useful features for your role: * **Policy Dashboard.** AppControl checks the state of all your apps to ensure that they are compliant with your organization standards (security, quality, maintainability, development standards). Use the policy dashboard to view the current state of your apps. {% content-ref url="/pages/CCXsc1xd9Tr0sRNHq4If" %} [Policies](/dashboards/policies) {% endcontent-ref %} * **Releases.** AppControl uses pipelines to enforce policies, and to ease the release process for DevOps teams. The releases dashboard gives you an overview of all releases for your apps, and can be used to approve releases that have been prepared by your development teams. Note: An app administrator needs to configure this feature before you can use it. {% content-ref url="/pages/RNBsj5asjVlqgGINRqby" %} [Releases](/dashboards/releases) {% endcontent-ref %} * **Tasks.** Tasks enable you to keep track of manual activities that need to be performed per app (E.g. compliance activities, certificate renewals, etc.). If there are common tasks (or app-specific tasks) that must be performed regularly, you can use AppControl to keep track of who tasks are assigned to, whether or not they have been executed, and what the results are. Note: An app administrator needs to configure this feature before you can use it. {% content-ref url="/pages/YQ8RDqZkLJWmzJMjZKsg" %} [Tasks](/administration/tasks) {% endcontent-ref %} * **Insights.** Insights gives you insight into the Mendix versions and Mendix Marketplace components used by all your Mendix apps. Use Insights to answer questions such as 'Which apps are still using Mendix 8?' or 'Which apps are using the SAML module version older than 3.0?'. {% content-ref url="/pages/qypZKxVmpCxgtW6bN7o6" %} [Insights](/dashboards/insights) {% endcontent-ref %} ### Recommended tutorials Start with the workflows that help you review risk and move releases forward. * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Create a release](/overview/tutorials/releases/create-a-release) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # App Administrator AppControl supports Mendix app administrators to automate and simplify the daily operations for managing Mendix apps. Note: Before you can use these features you must be assigned as an app administrator to one or more apps. The following are useful features for your role: * **Policies.** AppControl checks the state of your Mendix apps to ensure that they are compliant with your organizational standards. Use the policy dashboard to view the current compliance of your apps to your organizational standards. {% content-ref url="/pages/CCXsc1xd9Tr0sRNHq4If" %} [Policies](/dashboards/policies) {% endcontent-ref %} * **Pipelines.** App pipelines can be configured to enforce your policies, and to ease the build and deployment process for your apps. By default there are no pipelines, and thus you will need to configure at least one pipeline if you want to use a standardized process for building and deploying your apps. Note: By default only the platform administrator can create pipelines. Contact your platform administrator to discuss enabling this feature for you. {% content-ref url="/pages/xabNN6JrKEbEhHjvhSnj" %} [Pipelines](/administration/pipelines) {% endcontent-ref %} * **Releases.** AppControl uses pipelines to enforce policies, and to ease the release process for DevOps teams. The releases dashboard gives you an overview of all releases for your apps, and the current state of the release (pipeline) process. {% content-ref url="/pages/RNBsj5asjVlqgGINRqby" %} [Releases](/dashboards/releases) {% endcontent-ref %} * **Tasks.** Tasks enable you to keep track of manual activities that need to be performed per app (E.g. compliance activities, certificate renewals, etc.). AppControl enables you to create and manage recurring (or one-time) tasks for your apps. Additionally, you can also manage the tasks that have been assigned to you by a group or platform administrator (e.g. organizational compliance tasks). {% content-ref url="/pages/YQ8RDqZkLJWmzJMjZKsg" %} [Tasks](/administration/tasks) {% endcontent-ref %} * **Insights.** Insights gives you insight into the Mendix versions and Mendix Marketplace components used by your Mendix apps. Use Insights to answer questions such as 'Which apps are still using Mendix 8?' or 'Which apps are using the SAML module version older than 3.0?'. {% content-ref url="/pages/qypZKxVmpCxgtW6bN7o6" %} [Insights](/dashboards/insights) {% endcontent-ref %} ### Recommended tutorials Start with the workflows that help you operate apps day to day. * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Create a release](/overview/tutorials/releases/create-a-release) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) * [Find outdated components](/overview/tutorials/insights/find-outdated-components) # Developer AppControl supports Mendix developers to create apps that are compliant with organizational security, quality, and development standards, and to automate and simplify their daily development activities. The following are useful features for your role: * **Policies.** AppControl checks each deployed revision of a Mendix app to ensure that it is compliant with your organizational standards. Use the policy dashboard to view the current compliance of your apps to your organizational standards. The results of a policy check will help you to change your app to bring it into compliance with standards before you deploy it to production. {% content-ref url="/pages/CCXsc1xd9Tr0sRNHq4If" %} [Policies](/dashboards/policies) {% endcontent-ref %} * **Releases.** AppControl uses pipelines to enforce policies, and to ease the release process for developers. The releases dashboard gives you an overview of all releases of your apps, and the current state of the release (pipeline) process. From the release dashboard you can prepare and deploy new releases of apps to each environment you have access to. {% content-ref url="/pages/RNBsj5asjVlqgGINRqby" %} [Releases](/dashboards/releases) {% endcontent-ref %} * **Tasks.** Tasks enable you to keep track of manual activities that need to be performed per app (E.g. code reviews, environment configurations, etc.). The task dashboard enables you to manage the tasks that have been assigned to you. {% content-ref url="/pages/6p2oQ41MlmVSF8S4NZR0" %} [Tasks](/dashboards/tasks) {% endcontent-ref %} * **Insights.** Insights gives you insight into the Mendix versions and Mendix Marketplace components used by your Mendix apps. Use Insights to answer questions such as 'Which apps are still using Mendix 8?' or 'Which apps are using the SAML module version older than 3.0?'. {% content-ref url="/pages/qypZKxVmpCxgtW6bN7o6" %} [Insights](/dashboards/insights) {% endcontent-ref %} ### Recommended tutorials Start with the workflows you use most during delivery. * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Compare policy results between revisions](/overview/tutorials/policies/compare-policy-results-between-revisions) * [Create a release](/overview/tutorials/releases/create-a-release) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) # Tutorials Task-based guides for common AppControl workflows. Use these tutorials when you know the job you need to complete. ### Browse by area * [Policies](/overview/tutorials/policies) — Configure standards, review failures, and measure improvement. * [Releases](/overview/tutorials/releases) — Build release flows and run releases with confidence. * [Tasks](/overview/tutorials/tasks) — Create recurring work and track completion. * [Insights](/overview/tutorials/insights) — Find trends, risk hotspots, and governance signals. * [Administration](/overview/tutorials/administration) — Set up access, delegation, and operating structure. ### Start by role * **Platform Administrator:** [Configure a global policy](/overview/tutorials/policies/configure-a-global-policy), [Create an app group](/overview/tutorials/administration/create-an-app-group), [Create a user group](/overview/tutorials/administration/create-a-user-group) * **Group Administrator:** [Create a group policy](/overview/tutorials/policies/create-a-group-policy), [Manage group members](/overview/tutorials/administration/manage-group-members), [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) * **App Owner:** [Review policy compliance](/overview/tutorials/policies/review-policy-compliance), [Create a release](/overview/tutorials/releases/create-a-release), [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) * **App Administrator:** [Create a release](/overview/tutorials/releases/create-a-release), [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks), [Find outdated components](/overview/tutorials/insights/find-outdated-components) * **Developer:** [Review policy compliance](/overview/tutorials/policies/review-policy-compliance), [Create a release](/overview/tutorials/releases/create-a-release), [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) # Policies Use these tutorials to configure standards, review failures, and track improvement. ### Tutorials * [Configure a global policy](/overview/tutorials/policies/configure-a-global-policy) * [Create a group policy](/overview/tutorials/policies/create-a-group-policy) * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Compare policy results between revisions](/overview/tutorials/policies/compare-policy-results-between-revisions) # Compare policy results between revisions Use this tutorial to measure whether a revision change improved compliance. ### Before you start * You need access to the target app. * Both revisions must already be checked. {% stepper %} {% step %} ### Open the app revisions Go to the [App page](/dashboards/app). Open the **Revisions** tab for the app you want to review. {% endstep %} {% step %} ### Start a comparison Select the newer revision first. Then choose **compare**. {% endstep %} {% step %} ### Select the baseline revision Choose an older revision to compare against. Use a revision that represents the last known good state. {% endstep %} {% step %} ### Review what changed Open the comparison results. Check which results are new, unchanged, or resolved. Use this view to confirm whether the latest work reduced policy failures. {% endstep %} {% endstepper %} ### Next steps * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Create a release](/overview/tutorials/releases/create-a-release) * [Find outdated components](/overview/tutorials/insights/find-outdated-components) # Create a group policy Use this tutorial to apply shared standards to one app group. ### Before you start * You need the **Group Administrator** role for the target group. * The app group must already exist. * Policy management must be enabled. {% stepper %} {% step %} ### Open the policy manager Go to [Policies](/administration/policies). Choose the group policy scope. {% endstep %} {% step %} ### Select the target group Open the policy for the group you manage. If the group does not have its own policy yet, create one first. {% endstep %} {% step %} ### Configure the group rules Start from the inherited policy. Add stricter rules only where the group needs them. Keep mandatory global rules unchanged. {% endstep %} {% step %} ### Save and validate Apply the policy changes. Then open [Dashboards → Policies](/dashboards/policies) and review apps from the group. {% endstep %} {% endstepper %} ### Next steps * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Assign app access with a user group](/overview/tutorials/administration/assign-app-access-with-a-user-group) * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) # Review policy compliance Use this tutorial to find failed checks and decide what to fix next. ### Before you start * You need access to the target app. * The app revision must already be checked. {% stepper %} {% step %} ### Open the policy dashboard Go to [Dashboards → Policies](/dashboards/policies). Select the environment type you want to review. {% endstep %} {% step %} ### Open the app results Choose the app row from the overview. This opens the [Policy Viewer](/dashboards/policies/policy-viewer). {% endstep %} {% step %} ### Review the failed checks Start with the policy overview and failed result counts. Then inspect the failed check results in detail. Focus first on high-risk issues. {% endstep %} {% step %} ### Decide the next action Fix the issue in the app when the result is valid. If a result is intentionally accepted, manage it as an accepted risk. Use [Compare Revisions](/dashboards/policies/compare-revisions) to confirm improvements after a change. {% endstep %} {% endstepper %} ### Next steps * [Compare policy results between revisions](/overview/tutorials/policies/compare-policy-results-between-revisions) * [Create a release](/overview/tutorials/releases/create-a-release) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # Configure a global policy Use this tutorial to define standards that apply across all apps. ### Before you start * You need the **Platform Administrator** role. * Policy management must be enabled. * You should know which checks must be mandatory. {% stepper %} {% step %} ### Open the policy manager Go to [Policies](/administration/policies). Start from the global policy. {% endstep %} {% step %} ### Review the policy scope Confirm you are editing the policy that applies to all apps. Use the app policy rules for platform-wide technical standards. Use the data policy rules for classification and role checks. {% endstep %} {% step %} ### Update the rules Enable the checks you want to enforce. Adjust settings such as minimum versions or standards where needed. Mark checks as mandatory when lower-level policies must not override them. {% endstep %} {% step %} ### Apply the policy changes Save the policy after you finish the updates. The policy version increases when you change the policy. {% endstep %} {% step %} ### Verify the outcome Open [Dashboards → Policies](/dashboards/policies). Review a few apps to confirm the new policy is active. Open the [Policy Viewer](/dashboards/policies/policy-viewer) for details. {% endstep %} {% endstepper %} ### Next steps * [Create an app group](/overview/tutorials/administration/create-an-app-group) * [Create a user group](/overview/tutorials/administration/create-a-user-group) * [Find apps using older Mendix versions](/overview/tutorials/insights/find-apps-using-older-mendix-versions) # Releases Tutorials for release management and pipeline workflows. ### In this section * [Create a release](/overview/tutorials/releases/create-a-release) * [Create a global pipeline](/overview/tutorials/releases/create-a-global-pipeline) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) # Create a group pipeline Use this tutorial to standardize releases for one app group. ### Before you start * You need the **Group Administrator** role for the target group. * Group pipeline management must be enabled. * The target app group must already exist. {% stepper %} {% step %} ### Open pipeline management Go to [Administration → Pipelines](/administration/pipelines). Choose the group pipeline library. {% endstep %} {% step %} ### Select the group Open the group you manage. Create a new pipeline in that scope. {% endstep %} {% step %} ### Add the release flow Configure scheduling and versioning. Then add the steps the group needs for builds, approvals, and deployments. {% endstep %} {% step %} ### Test the pipeline Use one app from the group to create a release. Confirm the pipeline appears in the group library and runs as expected. {% endstep %} {% endstepper %} ### Next steps * [Create a release](/overview/tutorials/releases/create-a-release) * [Create a group policy](/overview/tutorials/policies/create-a-group-policy) * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) # Create a release Use this tutorial to prepare and run a release for one app. ### Before you start * You need the **App Administrator** or **App Operator** app role. * Release management must be enabled for the app. * At least one pipeline must be available. {% stepper %} {% step %} ### Start a new release Go to [Dashboards → Releases](/dashboards/releases). Open [Create Release](/dashboards/releases/manage). {% endstep %} {% step %} ### Select the pipeline Choose the app and the pipeline library. Then select the pipeline you want to run. {% endstep %} {% step %} ### Configure the release Set the target environment, branch, and revision. Review scheduling, release notes, and version details. If the pipeline allows it, choose an existing package or update to a newer revision. {% endstep %} {% step %} ### Submit and monitor Start the release when the configuration is correct. Track the status from the release page until it completes. {% endstep %} {% endstepper %} ### Next steps * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) * [Compare policy results between revisions](/overview/tutorials/policies/compare-policy-results-between-revisions) # Create a global pipeline Use this tutorial to standardize releases across all apps. ### Before you start * You need the **Platform Administrator** role. * Release management must be enabled. * You should know which tasks each release must run. {% stepper %} {% step %} ### Open pipeline management Go to [Administration → Pipelines](/administration/pipelines). Start from the global pipeline library. {% endstep %} {% step %} ### Create the pipeline Add a new pipeline. Enter a clear name and confirm the scope is global. {% endstep %} {% step %} ### Configure scheduling and versioning Choose when the pipeline runs. Set how release numbers and release notes are generated. {% endstep %} {% step %} ### Add pipeline tasks Add the required steps in order. Typical tasks include policy checks, approvals, builds, deployments, and notifications. {% endstep %} {% step %} ### Enable and validate Enable the pipeline when it is ready. Then create a test release to confirm the flow works as expected. {% endstep %} {% endstepper %} ### Next steps * [Enable delegated pipeline management](/overview/tutorials/administration/enable-delegated-pipeline-management) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) * [Create a release](/overview/tutorials/releases/create-a-release) # Tasks Tutorials for task libraries, assignments, and day-to-day task work. ### In this section * [Create and assign a global task](/overview/tutorials/tasks/create-and-assign-a-global-task) * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) # Work with assigned tasks Use this tutorial to manage the tasks that were assigned to you. ### Before you start * You need access to the app related to the task. * The task must already be assigned. {% stepper %} {% step %} ### Open your task list Go to [Dashboards → Tasks](/dashboards/tasks). Filter the list to find your open tasks. {% endstep %} {% step %} ### Review the task details Open the task. Read the instructions, due date, and assignee details. If the task includes sub-tasks, complete them in order. {% endstep %} {% step %} ### Update progress Add comments or attachments when they help the reviewer. Use task updates to document what you completed. {% endstep %} {% step %} ### Complete the task Mark the task complete when all required work is done. If the task blocks a pipeline, the release can continue after completion. {% endstep %} {% endstepper %} ### Next steps * [Create a release](/overview/tutorials/releases/create-a-release) * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # Create and assign a group task Use this tutorial to manage recurring work for one app group. ### Before you start * You need the **Group Administrator** role for the target group. * The target app group must already exist. * You should know which role is responsible for the task. {% stepper %} {% step %} ### Create the task template Go to [Administration → Tasks](/administration/tasks). Use the group library for the group you manage. Create the task template. {% endstep %} {% step %} ### Set the assignment model Choose a one-time or recurring schedule. If the task always belongs to the same role, pre-configure the assignment type. {% endstep %} {% step %} ### Assign the task to apps Open [Task Assignment](/dashboards/tasks/task-assignment). Assign the task to the group, selected apps, or specific people. Set notification rules before you assign it. {% endstep %} {% step %} ### Monitor completion Track the assigned tasks from the task dashboard. Use reminders or reassignment if ownership changes. {% endstep %} {% endstepper %} ### Next steps * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # Create and assign a global task Use this tutorial to roll out a manual activity across many apps. ### Before you start * You need the **Platform Administrator** role. * You should know who owns the task. * You should know when the task starts and becomes due. {% stepper %} {% step %} ### Create the task template Go to [Administration → Tasks](/administration/tasks). Use the global library. Create a task template with a clear name and instructions. {% endstep %} {% step %} ### Configure the schedule Choose whether the task is one-time or recurring. Use a task list when multiple sub-tasks are required. {% endstep %} {% step %} ### Assign the task Open [Dashboards → Tasks](/dashboards/tasks). Use [Task Assignment](/dashboards/tasks/task-assignment) to select apps, start date, assignees, and notifications. {% endstep %} {% step %} ### Validate the assignment Confirm the task was assigned to the right apps and roles. If owner or admin assignments are missing, validate the assignment again after fixing access. {% endstep %} {% endstepper %} ### Next steps * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) * [Work with assigned tasks](/overview/tutorials/tasks/work-with-assigned-tasks) * [Create a user group](/overview/tutorials/administration/create-a-user-group) # Insights Use these tutorials to find trends, risks, and governance signals across your apps. ### Tutorials * [Find apps using older Mendix versions](/overview/tutorials/insights/find-apps-using-older-mendix-versions) * [Find outdated components](/overview/tutorials/insights/find-outdated-components) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # Find outdated components Use this tutorial to find modules, widgets, or libraries that need attention. ### Before you start * You need access to the apps you want to review. * The app revisions must already be processed. {% stepper %} {% step %} ### Open component search Go to [Components](/dashboards/insights/components) under [Insights](/dashboards/insights). {% endstep %} {% step %} ### Select the component type Choose modules, widgets, Java libraries, or Javascript libraries. Then set the app and environment filters you need. {% endstep %} {% step %} ### Filter for upgrade candidates Use name, version, or latest compatible version filters. Look for rows where the current version is behind the latest compatible version. {% endstep %} {% step %} ### Prioritize the work Focus first on components that affect many apps. Export the results or assign a task to the impacted app teams. {% endstep %} {% endstepper %} ### Next steps * [Find apps using older Mendix versions](/overview/tutorials/insights/find-apps-using-older-mendix-versions) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) # Find apps using older Mendix versions Use this tutorial to find apps that still run on older Mendix versions. ### Before you start * You need access to the apps you want to review. * The relevant environments must already be processed. {% stepper %} {% step %} ### Open the components view Go to [Dashboards → Insights](/dashboards/insights). Open [Components](/dashboards/insights/components). {% endstep %} {% step %} ### Search runtime versions Select the Mendix runtime component type. Choose the environment type you want to review. Filter by version when you are targeting a specific runtime range. {% endstep %} {% step %} ### Review the results Identify apps that still use the older runtime. Check the processed date if recent deployments are missing. {% endstep %} {% step %} ### Take action Export the result set when you need to share it. Or assign a task directly from the filtered list. {% endstep %} {% endstepper %} ### Next steps * [Find outdated components](/overview/tutorials/insights/find-outdated-components) * [Create and assign a global task](/overview/tutorials/tasks/create-and-assign-a-global-task) * [Review governance readiness](/overview/tutorials/insights/review-governance-readiness) # Review governance readiness Use this tutorial to check whether an app is ready for governance review. ### Before you start * You need access to the target app. * The app revision must already be processed and checked. {% stepper %} {% step %} ### Open the governance report Go to [Insights](/dashboards/insights). Open **Reports** and then [Governance](/dashboards/insights/reports/governance). {% endstep %} {% step %} ### Review the status tiles Check the governance areas that show errors, warnings, or information. Start with the areas that block audits or releases. {% endstep %} {% step %} ### Inspect the failed checks Use the tables below the tiles to see which policy checks failed. Open the related app or policy details when you need more context. {% endstep %} {% step %} ### Plan the remediation Create tasks for manual follow-up. Or use the failed checks to update standards, access, or release controls. {% endstep %} {% endstepper %} ### Next steps * [Review policy compliance](/overview/tutorials/policies/review-policy-compliance) * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) * [Create a global pipeline](/overview/tutorials/releases/create-a-global-pipeline) # Administration Use these tutorials to manage delegation, access, and platform-level setup. ### Tutorials * [Create an app group](/overview/tutorials/administration/create-an-app-group) * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Create a user group](/overview/tutorials/administration/create-a-user-group) * [Assign app access with a user group](/overview/tutorials/administration/assign-app-access-with-a-user-group) * [Enable delegated pipeline management](/overview/tutorials/administration/enable-delegated-pipeline-management) # Create an app group Use this tutorial to delegate app management to a group administrator. ### Before you start * You need the **Platform Administrator** role. * You should know which apps belong together. * You should know who will manage the group. {% stepper %} {% step %} ### Open app groups Go to [Administration → App Groups](/administration/app-groups). {% endstep %} {% step %} ### Create the group Add a new group. Give it a clear name and description. {% endstep %} {% step %} ### Assign apps Add the apps that belong to this group. Remember that one app can belong to only one group. {% endstep %} {% step %} ### Assign group administrators Add one or more group administrators. They can then manage group members and group-level resources. {% endstep %} {% endstepper %} ### Next steps * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Create a group policy](/overview/tutorials/policies/create-a-group-policy) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) # Create a user group Use this tutorial to grant app access to a group of users. ### Before you start * You need the **Platform Administrator** role. * You should know which apps belong together. * You should know which access profile the users need. {% stepper %} {% step %} ### Open user groups Go to [Administration → User Groups](/administration/user-groups). {% endstep %} {% step %} ### Create the group Add a new user group. Give it a clear name and description. {% endstep %} {% step %} ### Add apps Add the apps that this user group should cover. All members inherit access to those apps through the group. {% endstep %} {% step %} ### Add members with the right profile Add the users who need access. Choose the correct app role for each member. Use the default App Member role unless more access is required. {% endstep %} {% endstepper %} ### Next steps * [Assign app access with a user group](/overview/tutorials/administration/assign-app-access-with-a-user-group) * [Create an app group](/overview/tutorials/administration/create-an-app-group) * [Create and assign a global task](/overview/tutorials/tasks/create-and-assign-a-global-task) # Manage group members Use this tutorial to control which users can view apps in a group. ### Before you start * You need the **Group Administrator** role for the target group. * The app group must already exist. {% stepper %} {% step %} ### Open the app group Go to [Administration → App Groups](/administration/app-groups). Open the group you manage. {% endstep %} {% step %} ### Review the current members Check who already belongs to the group. Group members can view the apps in that group. {% endstep %} {% step %} ### Add or remove members Add the users who need visibility. Remove users who no longer need access. Changes take effect on the apps in that group. {% endstep %} {% step %} ### Confirm app access Check that group members can now see the right apps. If they need more than app visibility, use a user group as well. {% endstep %} {% endstepper %} ### Next steps * [Assign app access with a user group](/overview/tutorials/administration/assign-app-access-with-a-user-group) * [Create and assign a group task](/overview/tutorials/tasks/create-and-assign-a-group-task) * [Create a group policy](/overview/tutorials/policies/create-a-group-policy) # Assign app access with a user group Use this tutorial to manage app roles for many users at once. ### Before you start * You need the **Platform Administrator** role, or **Group Administrator** for the target group. * The user group must already exist. {% stepper %} {% step %} ### Open the user group Go to [User Groups](/administration/user-groups). Open the group you want to manage. {% endstep %} {% step %} ### Review the app list Confirm the group contains the correct apps. Members will receive access to every app in the group. {% endstep %} {% step %} ### Set member access profiles For each member, choose the required access profile. Use App Owner, App Administrator, App Member, or App Operator as needed. If you use App Operator, limit the allowed environment types where needed. {% endstep %} {% step %} ### Validate the result Confirm that the users can see the right apps and actions. Remember that other group memberships may also grant access. {% endstep %} {% endstepper %} ### Next steps * [Manage group members](/overview/tutorials/administration/manage-group-members) * [Create a user group](/overview/tutorials/administration/create-a-user-group) * [Enable delegated pipeline management](/overview/tutorials/administration/enable-delegated-pipeline-management) # Enable delegated pipeline management Use this tutorial to let group or app administrators create pipelines. ### Before you start * You need the **Platform Administrator** role. * Release management must already be enabled. {% stepper %} {% step %} ### Open system configuration Go to [Administration → System → System Configuration](/administration/system/system-configuration). {% endstep %} {% step %} ### Open feature settings Go to the **Feature Settings** tab. Find the **Release Management** settings. {% endstep %} {% step %} ### Enable delegation Turn on **Group admins can manage pipelines** when group admins should create group or app pipelines. Turn on **App admins can manage pipelines** when app admins should create app pipelines. {% endstep %} {% step %} ### Validate the new permissions Ask the target administrators to open [Pipelines](/administration/pipelines). Confirm the expected pipeline libraries are now editable. {% endstep %} {% endstepper %} ### Next steps * [Create a global pipeline](/overview/tutorials/releases/create-a-global-pipeline) * [Create a group pipeline](/overview/tutorials/releases/create-a-group-pipeline) * [Create a release](/overview/tutorials/releases/create-a-release) # Platform The platform dashboard provides an aggregated view of your entire Mendix app landscape managed by AppControl. The dashboard is visible to all users and is not limited to the specific apps that a person has access to. The dashbaord metrics are updated dynamically when loaded. The dashboard has the following tiles:
Apps This tile shows the number of apps that you have that are licensed or are free apps. Additionally, it shows the number and type of environments that you are using.
Alerts The Alerts tile shows you the number of apps with a specific alert status. Click on the tile to open the Alerts dashboard.
Components This tile shows the Mendix version in use by your production environments, as well as the number of and support status of the components in use by all apps in production environments.
Policies This tile shows the state of the policies that apply to your production environments. The breakdown of categories shows the number of policy checks for each category that have failed. For instance if you see that there are 114 security check failures, it means that in total 114 policy checks have failed across all apps in your production environments.
Development This tile shows a summary of your development activity: the number of commits, builds, and deploys. Note: Builds and deploy information is only available if you use the build and deploy tasks in pipelines in AppControl to build and deploy your apps.
# Alerts The Alerts Dashboard gives you a complete overview of the current state of your apps.
Status The Status tab provides an aggregated overview of the state of any alerts generated by your apps (with a single row per environment). It aggregates information about policies, pipelines, tasks, logs, and your hosting platforms. When problems occur with an app an alert is generated by AppControl. Additionally, alerts are automatically received and processed from your hosting platforms. AppControl checks every 5 minutes of there are unacknowledged alerts for each app and updates the status in this dashboard. The following events generate alerts in AppControl: * **Policies.** If an app fails a policy check an alert is generated. * **Hosting.** If a hosting platform is experiencing problems an alert is generated. * **Pipelines.** If a pipeline fails to execute an alert is generated. * **Tasks.** If tasks are overdue an alert is generated. * **Logs.** If a log processing rule matches a log entry an alert is generated. The current status for a specific category (E.g. Policies, Releases, etc.) shows the worst alert state (ERROR / WARNING / HEALTHY) for all alerts sources (E.g. DATABASE, APP MEMORY, APP DISK) for the environment that has not yet been acknowledged. If AppControl receives a HEALTHY alert from a given source (E.g. HEALTHY alert is received for APP DISK from Acceptance Envioronment), it will automatically acknowledge all other alerts from the same source (all APP DISK alerts from the Acceptance Environment). Click on an app to open the app dashboard.
Alerts The Alerts tab lists all alerts generated by all apps and environments. Use this view to search for and filter alerts. The following information is available for each alert: * Alert ID. A unique ID generated by the source of the alert. * Message. A description of the reason the alert was generated. * Is Acknowledged. If checked, this alert is no longer used to calculate the current state of the app in the app status dashboard. This is flag is automatically set by AppControl. * Alert level. The severity level of the alert. * Alert type. The alert category: Policies, Tasks, Hosting Platform, Logs, Releases. * Alert source. What generated the alert. Usually this is AppControl or a hosting platform. * Timestamp. The timestamp of the alert. * Service. A sub category of the alert type. This information is not always available for all alerts, but when available, it helps to further identify the source of the alert. (E.g. 'Application Container Memory Percentage' for an alert with the alert type 'Hosting Platform') * App. The name of the app that the alert was generated for. * Environment. The ID of the environment that the alert was generated for.
# App The app dashboard provides access to app-specific information, as well as giving access to app-specific functions. Some functions are limited to users with the App Administrator role. The following tabs are only visible if you have the App Administrator role: Revisions The following tabs and tiles are available on this page:
Alerts This tab shows an overview of all alerts generated for your app by AppControl. Alerts are generated for the following events: * **Policies.** If this app fails a policy check an alert is generated. * **Hosting Platforms.** If the hosting platform used by this app is experiencing problems an alert is generated. * **Releases.** If a release for this app contains warnings or failures an alert is generated. * **Tasks.** If a task for this app is overdue an alert is generated. * **Logs.** If log filters or solutions detect a log message that matches, and the action has been set to 'alert', an alert will be generated. If you acknowledge an alert it will automatically update the status of the app in the app dashboard. If there are no more unacknowledged alerts for your app its status will return to normal in the app dashboard.
Info **App Details** This tile provides an overview of important technical and administrative information for your app. Users assigned as an app owner can also change the production date of the app. This information is used for various features in AppControl. **App Access** This tile provides an overview of the contacts for this app. Aside from providing an administrative overview of the contact for an app, each contact role affects the access that a user has to that app in AppControl: * **App Owner.** Can change app contact information, can approve releases. Only Platform Administrators and Group Administrators can manage the list of App Owners. * **App Administrator.** Can manage app pipelines, policies, and tasks. Only Platform Administrators, Group Administrators and App Owners can manage the list of App Administrators. Note: Except for users that have the 'PolicyViewer' user role, when adding a user as an App Administrator they automatically get the system role 'AppAdministrator'. * **App Member.** Can view basic app information (environments, policy status, scorecards, app details, app contacts). Only Platform Administrators, Group Administrators and App Owners can manage the list of App Owners. * **App Operator.** Can create releases for this app. The App Administrator, Group Administrator, or Platform Administrator can select which environments the App Operator can create releases for. The possible environments are: * **Production.** The user can create releases for production environments only. * **Production & Acceptance.** The user can create releases for production and acceptance environments only. * **Acceptance & Test.** The user can create releases for non-production environments only. * **All.** The user can create releases for all environments.
Configurations In this tab (visible in each environment) there is an overview of all configurations that have either been detected, or have been manually created. To create a new configuration click on the copy action for an existing configuration. **Configuration** This page enables you to change the values for a configuration. Note this is only possible for configurations that are manually created, and only for configurations that are not currently in use by a release. The following options are available: * **Name.** Give this configuration a name. This will be visible when selecting configurations to be used in a pipeline. * **Environment.** The environment that this configuration belongs to. * **Version.** An auto number assigned to this configuration. Each time a new configuration is detected or manually created, this number is automatically incremented. * **Is manually created?** If this configuration was detected by AppControl, this will be FALSE. * **Enabled?** If disabled, this configuration will no longer be able to be used for a new release. * **Constants.** For constants that are in your app, you can set a new value. Note: Only constants that have already been deployed can be managed. Although new constants that have not yet been deployed can be added to a configuration, you must deploy a version of your app with the new constant in it before you can deploy a configuration that contains the new constant. * **Scheduled Events.** For scheduled events in your app, you can choose to enable or disable them by typing 'Enabled' or 'Disabled'. Note: Do not enter any other text or values in this field besides 'Enabled' or 'Disabled' as this will cause the deployment of this configuration to fail. * **Custom Settings.** View and edit custom runtime settings. Note: Make sure that the name you use for the custom runtime setting matches exactly the name required by Mendix. If not, the deployment of this configuration will fail. Also, it is not possible to delete custom runtime settings once set (this is a limitation of the Mendix Cloud API).
Revisions This tab provides an overview of all branches and revisions of your app. Additionally, you can use this tile to browse detailed information about revisions that have been processed by AppControl, or compare policy results for revisions that have been checked. Revisions are processed automatically by AppControl once they are deployed to an environment. It is also possible to manually process and check a revision from this overview. The following actions are available for each revision (some may be hidden depending in the current status of the revision): * **Process.** This will download and process your app model so that you can view information about used components, security settings, project files, and other useful information (see below for details). * **Check.** This will check the revision for compliance with your policies. Note: Revisions can only be checked after they have been processed. * **Cancel.** If a revision is currently being processed or checked, this will cancel the current operation. * **View Details.** For revisions that have been processed, this will open the [revision page](/dashboards/app/revisions) to view the details that have been extracted by AppControl. * **Policy Results.** For revisions that have been checked, this will open the policy viewer to view the results of the policy check for this revision. * **Compare.** This enables you to compare the policy results between this revision and another revision that has already been checked. After clicking this link the [compare revisions](/dashboards/policies/compare-revisions) page will appear.
Tasks This tab provides an overview of all the tasks currently assigned to this app and their status. If you have the role Platform Administrator, Group Administrator, or App Administrator you can also assign a task to this app from this overview.
Releases This tab provides an overview of all pipelines configured for this app, as well as the status of any executed or executing releases. Pipelines can be configured from the Pipelines tab. For more information on how to configure pipelines see the [pipelines](/administration/pipelines) page in the AppControl documentation. Releases can be created by clicking on the 'new release' button from the 'Running' tab. For more information on how to create a release see the [releases](/dashboards/releases) page in the AppControl documentation.
Logs This tab provides an overview of all log messages generated by your app for the date selected. You can drill down into each environment and view a summary of log messages at log node level, and at the lowest level you can view individual log messages. For more information on log processing see the [Log Insights](/dashboards/insights/logs) page. Note that logs are processed once per day. If you select today's date you will have the option to download and process today's logs. Because this process happens in real time you will need to wait for the download and processing to complete. Depending on how large your logs files are this could take a while. Adter today's logs are downloaded an option appears to refresh the logs. This will perform the same process again and download the most up to date logs from the app. From this tab you can also configure log rules. Log rules are app-specific and are used to process log files for you automatically. To view and manage your log rules click on the 'manage log rules' button. You can then view or create an individual [log rule](/dashboards/app/log-rule).
# Environments This tab provides an overview of all the environments for this app. This information is automatically collected and updated by AppControl. If you hosting platform does not support the automatic detection of environments, it is also possible to manually add them from this overview. Only users with the Platform Administrator role can add environments for an app. Once an environment is manually added to an app the App Administrator for the app can change the deployed revision when needed. When adding an environment you need to provide the following information: * **Environment ID** : The environment ID of this hosting environment. This is the technical ID that is used to retrieve information about the environment from the hosting platform. {% hint style="info" %} If you are adding an environment that is hosted on a Mendix for Kubernetes (Connected) cluster, the environment ID can be found in the [environment details page](https://docs.mendix.com/developerportal/deploy/private-cloud-deploy/#environments) in the Mendix Portal. {% endhint %} * **Type** : The type of environment that you select affects how policies are applies. The following are the possible environment types: * **Production.** Used for production applications. * **Acceptance.** Used for acceptance applications. * **Test.** Used for test applications. * **Sandbox.** Used for free Mendix apps. * **Flexible.** Used for multi-instance Mendix apps. * **URL** : The URL used to access the app. * **Model Version** : The current model version deployed to this environment. Note: For environments that are manually added this information is not visible. * **Mendix Version** : The current Mendix version used by the app in this environment. Note: For environments that are manually added this information is not visible. * **Deployed Branch.** If this is a manually added environment, you need to tell AppControl which branch and revision are deployed. * **Deployed Revision.** If this is a manually added environment, you need to tell AppControl which branch and revision are deployed. After selecting the revision and saving the settings, AppControl will automatically perform a policy check of the selected revision. * **Refresh branch revisions.** If the revision you want to select is not visible, click this button to update the list of revisions for the currently selected branch. * **Production?** : If checked, this environment has been marked as a production environment. This affects policies as well as other features in AppControl. Additionally, if you are an app administrator information about the configuration of your app is visible. Configurations are the collection of constants, scheduled events, and custom runtime settings that are used by a specific environment. AppControl checks the configuration of each of your environments once every hour to see if it has been changed. If the configuration has changed, AppControl will automatically store a copy of your new configuration. The following tabs are shown: * **Current Configuration.** This is the most recent configuration that has been read out from the selected environment. * **Configurations.** This is the history of all configurations ready out from the environment. Every time a change in the configuration is detected a new configuration is automatically created. If you want to create a new configuration (for use in a pipeline), you can choose to create a copy of an existing configuration and then change the values. {% hint style="info" %} If AppControl does not have the correct access to your environement, configuration information will either not be visible or it will not be up to date. Check the '[System Status](/support/system-status)' tab in the 'Support' tab to determine what access AppControl has to your app. {% endhint %} # Log Rule Log rules are used to automatically scan your app logs for strings of text, and if they match, perform a specific action. Log rules are app-specific and can be access from the Logs tab in the app page. The following describes how to configure an individual log rule: * **Node.** Enter the exact node name of the log node that should be matched. The name must match exactly. * **Level.** Enter the log level to match. * **String to match.** Enter a regex (Java compatible) to use to match the log message. An important point is that some log messages are multi-line. To match the content of a multi-line message you must start your regex with the following: `(?s)^` An additional tip is that you often need to match the text after the text you are searching for by ending your regex with `.*` * **Action to take.** What action the system should take when a log message matches this rule. The available actions are: * **Ignore.** This log message will me flagged as ignored, and it will no longer count towards error, warning, etc. totals in the log message overview. * **Alert.** A log alert will be generated (changes the app status in the dashboard, sends out an alert to the app administrator). * **Use Solution.** The log message will be flagged as 'solution available', and this will be visible in the log message overview. This is helpful for app operators to know what they should do. # Revisions AppControl processes your app models to extract information that can be used for analysis and governance purposes. Processing a model involves downloading your Mendix app model and associated project files from your app repository, scanning them, and storing that information so that it is available for you to view online.
Revision Actions The following actions can be performed on app model revisions: * **Process:** Downloads the app from the repository, scans the model, and stores detailed information about your app such as used components and model information in AppControl. * **Check:** Validates the selected revision for compliance with your policies. * **Re-check:** For revisions that have already been checked, this action re-evaluates recurring type checks, such as data policies and component vulnerabilities. * **View Details:** Opens a page to display detailed information about your app, including used components and other app model and project specifics. * **Policy Results:** Opens a page to view the outcome of the last policy check for this revision.
Revision Details Once an app model has been processed the following information becomes available: * **Modules.** A complete list of all modules used by this revision. * **Widgets.** A complete list of all widgets used by this revision. * **Java Libraries.** A complete list of all Java libraries used by this revision found in the following locations: * `/userlib` * `/vendorlib` * **Javascript Libraries.** A complete list of all Javascript libraries used by this revision as found in the following locations: * `/../*.json` (any depdency files) * `/widgets//../*.json` (any depdency files) * `/javasource/../*.json` (any depdency files) * **Dependencies.** Per component, a list of all dependencies that have been detected are stored and available to be viewed. The following dependencies are detected: * Module > Java Library * Module > Javascript Library * Widget > Javascript Library * Java Library > Module * Javascript Library > Module, Widget * **Version Information.** The version number for the component that has been detected, what the latest version is of this component that is available, and what the latest version is that is compatible with the used version of Mendix. * **Security.** An overview of the project security settings for this revision. * **Files.** An overview of all files stored in the app repository for this revision, and the ability to directly download them. * **Mendix Model.** The ability to browse the Mendix model element tree for this revision. * **Model File.** The ability to directly download the Mendix model file (.MPR) for this revision. * **Security Model File.** The ability to download (in JSON format) the complete security model (user roles and module access rights) for this revision.
# Policies The policy dashboard provides an overview of the policies monitored by AppControl for your apps. Policies are monitored automatically by AppControl for each deployed revision by performing a set of checks against your app. These checks are based on policy rules for security, quality, maintainability, and development standards. By default AppControl checks your app against a library of community best practices maintained and developed by Blue Storm. This default configuration is the called the global policy. It is possible to configure policies that are specific to your needs. The following policies can be configured: * **Global Policy.** This policy applies to all apps managed by AppControl. * **Group Policy.** This policy applies to all apps in a specific group. * **App Policy.** This policy applies to a specific app. Note: Only a single policy is used to check an app. Policy rules are inherited (Global -> Group -> App), and it is possible to make rules mandatory so that they cannot be overriden by a lower level policy. For information on how to configure policies see the [policy administration](#policy-configuration) page in this documentation. The following information is available in the policy dashboard overview.
Environment Selector Select the environment type that you wish to view the policy status for for. The default is 'Production'.
Policy Overview For each deployed app with an environment that matches the environment type that you selected there is a single row in the overview. If an environment is not visible it means that the app does not have an environment of the type you have selected. **Note:** If 'not yet processed' is displayed for an environment, it means that the policies for that enviornment have not yet been checked. This typically happens in the period after a new revision has been deployed to an environment. If this message remains for more than a few hours, check the Support tab to see if there are any processing errors for your environment. For each app the following information is displayed: * App. The name of the app. * Revision. The branch and revision that was analyzed for the policy. * Security / Maintainability / Quality / Standards. The total number of low, medium, and high risk policy checks that failed for the given check category. * Policy Compliance. A summary of the total policy checks that failed for this app. The percentage shows the percentage of checks that were configured in the policy that passed. The star rating is a simple visualization of this percentage where 100% = 5 stars.
Click on an app to view the details of the policy results. # Policy Viewer The policy viewer shows you the current status of the policy for the selected app and revision. Policies are checked once every 24 hours. The following information is available:
Policy Configuration This tile displays the policy configuration that was used to generate the policy status: * **Mendix version.** The version of Mendix that is in use by the revision that was checked. * **Revision.** The revision that was checked. * **Last checked.** The last time this revision was checked. Normally deployed revisions are checked every 24 hours. * **'Policy results out of date'.** If you ignore check results in a different revision, it will affect all revisions for the associated app. If this is detected, you will need to click this button to update the policy results and remove all newly ignored check results. * **Policy Scope.** The policy that was used. This can be Global, Group or App. * **Policy version.** The version of the policy that was used. Every time you change a policy the version number increases. * **Ignore Marketplace modules?** If TRUE, the policy ignores results for model elements that are part of modules downloaded from the Mendix Marketplace. * **Accepted risks.** How many check results (risks) were accepted for this app. Click on the 'manage' link to view the check results that were accepted and not used for calculating the compliance score for this app.
Policy Overview The policy overview tile shows a summary of the results for each category of checks. For each category the following information is displayed: * **Total check results.** The total number of failed check results. (check result = unique combination of check type and specific element) * **Percentage.** The percentage shows the percentage of checks (=check types) that were configured for this scorecard that passed (= did not generate any failed check results). * **Star rating.** The star rating is a simple visualization of the percentage of checks that passed where 100% = 5 stars.
Policy History The policy history tile shows the compliance of your app over time to your policy. For each revision of your app that has been checked an dditional point is added to the graph. By default only the Policy Compliance score is shown, however by clicking on the graph you can turn on or off the other policy check categories to see their score.
Check Results This tile shows an overview of all failed check results for this app. Click on a[ check result](#check-results) to view its details.
Accepted Risks The [ignore checks](#ignored-checks) page is accessed by clicking on the 'manage' link from the policy configuration tile in the policy viewer. This page shows you the check results (risks) that have been ignored when calculating the compliance score for this app. From this overview you can choose to remove a single check result (the combination of a check type and a specific model element) or all check results of a specific check type.
# Check Result The check result pop-up appears when you click on a check result from the policy viewer. This shows you the details of a check result and what triggered it. The following information is available: * **Check type.** The check that was used. For more details click the help icon to open the online documentation. * **Severity.** The severity level of the check result. Possible values are Low, Medium and High. * **Category.** The check type category. Possible values are Security, Maintainability, Quality, and Standards. * **Message.** An optional message generated by the check. This provides extra information to help you fix the issue found by the check. * **Target.** The best practice target value configured for this check. This is taken from the check configuration. * **Value.** The actual value found by the check. * **Element type.** The type of model / app element that was checked. * **Element name.** The name of the model / app element that was checked. Note: Some element types do not have a name (E.g. the 'app' element). # Accept Risk The accept risk pop-up can be accessed from the check result pop-up. This dialog enables you to accept the risk that is reported by check result. Accepted risks are not used when calculating the compliance score for an app. After accepting a risk the score for the current app is re-calculated. The next time a new revision is checked the list of accepted risks will also not be used to calculate the score. The following options are available: * **What do you want to accept?** * **Ignore specific risk** : If you select this, the currently selected combination of check type, element type, and element name will be accepted. * **Ignore all risks of the same type** : If you select this, all check results of this type will be accepted. * **Comment.** Enter a comment that explains why you are accepting this risk. If the policy administrator has made it mandatory, you must enter a comment in this field. * **Check type.** The name of the check type to be accepted. * **Element type.** The element type to be accepted. * **Element name.** The element name to be accepted. # Compare Revisions The compare revisions page enables you to compare the policy results of 2 different revisions for the same app. This makes it possible to view changes between 2 versions of the same app. This page is accessed by first selecting a revision to compare from the 'Revisions' tab in the [app page](/dashboards/app), and then clicking the 'compare' link. The branch and revision of the first revision are automatically selected. Select the branch and revision to compare to. Note, only revisions that have already been checked are visible in the selector. Also, it makes sense to select an older revision for revision 2 so that you can see what improvements you have made in revision 1. After clicking 'compare' the results page will appear:
Comparison Results The comparison results card shows a summary of what has changed in revision 1 compared to revision 2: * **New.** New check results that did not exist in revision 2. * **Unchanged.** Check results that are in both revision 1 and revision 2. * **Resolved.** Check results that are in revision 2, but that are no longer in revision 1.
Check Results (Revision 1) The check results overview will show the policy results for revision 1. In addition to the standard check result details an extra colum 'Status' shows if the check result is new, unchanged, or resolved in comparison to revision 2.
# Releases The releases dashboard provides an overview of all running and completed releases for the apps that you have access to, and shows the current state of all releases (= the execution of a pipeline). From the dashboard you can also create a new release. To create a new release click on '[new release](/dashboards/releases/manage)' and select the app and pipeline that you want to execute. The 'Draft' tab shows releases that have been created but have not yet been run. To view the details of a running or completed release click on a release from the overview. To cancel a release open the release and click on 'cancel'. Releases that are scheduled for one-time execution in the future, recuring releases (DAILY / WEEKLY), or on-commite pipelines can be viewed and cancelled from the 'Scheduled' tab. The status of scheduled or running releases is updated every 15 seconds. {% hint style="info" %} From the 'Completed' tab it is possible to export a list of all completed releases to an Excel spreadsheet. Note that some columns are hidden by default (E.g. Approver) and need to be unhidden if you want them to appear in the exported spreadsheet. {% endhint %} # Create Release When you create a new release you first need to select the pipeline to use. Pipelines can be selected from one of the following [pipeline libraries](/administration/pipelines). (Note: When creating a new release from the App page the 'App Pipelines' library is automatically selected): * **Global Pipelines.** All global pipelines. * **Group Pipelines.** All piplines that belong to the App Group that the selected app belongs to. * **App Pipelines.** All app-specific pipelines that have been created for the selected app. {% hint style="info" %} Only users that have been assigned the app role 'App Administrator' or 'App Operator' for an app can create releases. {% endhint %} #### Release Details After selecting the pipeline you want to use the manage release page appears.
Release Status This tile shows status information about this release: * **Current status.** The current status of the release. The following are the possible statuses: * **Scheduled :** The release is scheduled for execution. * **Not started :** The release has not yet been submitted to the release scheduler and can still be changed. This is the default status for a new release. * **Waiting approval :** The release is waiting for an approval before it begins execution. * **Running :** The release is currently running. * **Successful :** The release has successfully completed * **Warning :** The release completed but generated warnings. * **Failed :** The release failed to complete successfully. * **Scheduled :** The release is scheduled for execution but has not yet started. * **Last message.** The most recent output of the release.
Approvals If your pipeline contains an approval task, the required approvals (or already given approvals) will be shown in the approvals tile.
#### Release Configuration Depending on the pipeline tasks that have been added to your pipeline, the following release configuration tiles may be visible.
Target Environment * **Environment.** The target environment for this release. Note: If this has been pre-configured in the pipeline it cannot be changed. * **Configuration.** If the selected pipeline has a 'Deploy Configuration' task, select the configuration to be used. Configurations are specific to the environment that you have selected. The list of configurations that are available can be managed from the Configurations tab for each environment in the [App page](/dashboards/app).
Scheduling * **Schedule type.** The schedule type used for this release. This is set by the pipeline configuration and cannot be changed. For details on the possible values see the [pipeline management](/administration/pipelines) page. * **Scheduled for.** The date and time when this release is scheduled to be executed. * **Use task scheduling.** If you enable this you can select the date and time for each pipeline task to be executed. Note that task scheduling is only available for pipelines with the schedule type 'on demand'.
Restore from Backup This tile is visible if your pipeline has a restore task. * **Source environment.** The environment that contains the backups that you want to restore from. Note that this option is only visible if it has been enabled by the pipeline administrator. The default is to only allow restores from the same environment as the target environment. * **Backup.** The backup you want to restore. * **Check for newer backups.** If you enable this you can select the date and time for each pipeline task to be executed. Note that task scheduling is only available for pipelines with the schedule type 'on demand'.
Backup Details This tile is visible if your pipeline has a restore task. * **Backup ID.** The unique ID of this backup from your backup repository. * **Created on.** When the backup was created. * **Model version.** The Mendix model version that was deployed when this backup was created. * **Comment.** User or system comment that identifies this backup. * **Status.** Technical status of the backup (may be empty). Can be helpful to determine if the backup is complete and ready to be used.
Revision This tile is visible if your pipeline has a deploy task. * **Use existing package.** If selected, the deploy task will use an existing package instead of building a new one. Note: This option will not be visible if the pipeline administrator has configured the pipeline to use a specific branch or revision. * **Package.** The package you want to deploy. Note: This option is only visible when 'use existing package' is selected. * **Check for newer packages.** If the package you want to use is not visible, use this action to update the list of packages available from your package repository. * **Branch.** The source branch for this release. Note: If this has been pre-configured in the pipeline it cannot be changed. * **Revision.** The source revision for this release. Note: If this has been pre-configured in the pipeline it cannot be changed. In some cases the revision selected is not the most recent revision in the app repository. * **Check for newer revisions.** Use this action to scan your app repository for newer revisions for the selected branch.
Revision Details This tile is visible if your pipeline has a deploy task. * **Commit message / description.** The last commit message for the source revision used by this release, or the description of the selected package. * **Mendix version.** The version of Mendix used by the source revision or package used by this release.
Release Notes & Versioning * **Release version.** The version number to be used for this release. * **Release notes.** The release notes to be used for this release.
#### Pipeline Tasks The pipeline tasks section is always visible and shows you the current status of all tasks that will be executed as part of this release. For each task the current status is displayed as well as the last message that was output by the task. The status of pipeline tasks is automatically updated every 20-60 seconds. If task scheduling has been enabled for this release, it is possible to set the date and time when each task will be executed. Note: The date and time set is not guaranteed. This setting means that the task will start execution at the selected date and time as long as all previous tasks have completed execution. {% hint style="info" %} If a pipeline task fails additional information may be available from the [logs](/support/docs) tab. {% endhint %} # Tasks The tasks dashboard shows an overview of all tasks that are currently assigned to you and that have been completed. If you have the role Platform Administrator you will also see a tab to view all tasks in AppControl. Tasks enable you to manage recurring (or one-off) activities that are needed to manage your Mendix apps. For example: renewing certificates, renewing functional accounts, collecting information for audit reports, or checking who has access to your app. Before a task can be assigned it has to be configured. Task templates are managed from the Administration > Tasks page. For more information on how to configure task templates see the [tasks administration](/administration/tasks) page in this documentation. Once a task template has been configured it can be assigned. To assign a task select the 'task assignments' tab and click on 'assign new task'. See the [task assignnment](/dashboards/tasks/task-assignment) page for details. After a task has been assigned AppControl will create a task for each app that the task is assigned to, and will notify the persons responsible. Assigned tasks show up in the task dashboard. To view the current status of a task and to complete it click on it from the overview. See the [task details](/dashboards/tasks/task-details) page for more information. # Task Assignment The task assignment page is used to define which apps the task is associated with, and which role is responsible for performing the task. Provide the following information to assign a task: * **Select a task.** Select the task you want to assign. You can choose to assign a task from the Global, Group, or App task libraries. If you select Group or App you will also need to select the specific group or app task library that you want to assign from. * **Select apps.** Select the apps that this task should be assigned to. The choices are: * **All apps :** The task will be assigned to all apps. * **Group :** The task will be assigned to all apps that are currently a member of the group you select. * **List of apps :** The task will be assigned to the list of apps that you select. * **Specific app :** The task will be assigned to the app you select. * **Choose a start date.** Choose when the task should start and when it is due. The possible values are: * **Today :** The start date will be the current date and time. Select date in the future when the task is due. * **Specific date :** The start date will be the date and time you select. Select date in the future when the task is due. * **Production date :** The start date will be the production date of the app. Select how many days after the production date that the task is due. Note: If the app does not have a production date the task will not be assigned. * **Assign to.** The person that the task should be assigned to. The choices are: * **Application Owner :** The task will be assigned to the application owner(s) of each app. * **Application Manager :** The task will be assigned to the application managers(s) of each app. * **Specific Person :** The task will be assigned to the person you select. * **List of Persons :** The task will be assigned to the list of persons that you select. * **Notifications.** Use these options to control how notifications for a task assignment are sent out. Notifications are sent both to the creator of the task assignment, and to the assignees. Notification settings can be changed after the task has been assigned. Notifications can be sent out for the following events: * **Task is almost due.** When the task is almost due (1 week before). * **Task is overdue.** When the due date of the task has passed and it is not yet completed. * **New comment or attachment.** When a new comment or attachment is added. * **Task is completed.** When the task is completed. * **Task is assigned.** (Only for Assignee). When the task is assigned. * **Message to assignees.** Enter a message that will be sent to assignees when the task is first assigned. After the task is assigned, it is possible to send a new message by filling in the message, and clicking the 'send notification' button. The option 'send notification to open tasks only' will only send the notification to assignees of tasks that have not yet been completed. The following actions are available for task assignments: * **Assign Task / Reassign Task.** When a task assignment is new, clicking the 'assign task' button will create tasks, assign them, and send out notifications. When a task assignment is active, the 'reassign task' button will change the assignment of the task based on the new apps / persons that you have selected. * **Send Notification.** After a task assignment is active, you can enter a message in the 'message to assignees' section, and click 'send notification' to send a notification to all assignees. If the option 'send notification to open tasks only' is selected, the notification will only be sent to assignees of tasks that have not yet been completed. * **Validate Assignments.** When a task has been assigned, it is possible that the system was unable to find App Owners or App Administrators for a specific app. If so the task assignment for that app will fail. Once you have assigned an App Owner or App Administrator to those apps, click on the 'validate assignments' button to have the task assigned to all apps when the task assignment failed. This can also be used if the App Owners or App Administrators for an app change, and you want to validate that the assignments are still correct. * **Update Notification Settings.** If you change the notification settings for this task assignment after it is active, click this button to save the new notification settings. * **Archive Task.** This action will end the task assignment and mark all associated tasks as archived. # Task Details The purpose of a task is to describe you need to do, when you need to complete the task by, and give you the possibility to record information about the task. * **Task status.** This summarizes the current status of the task, when it is due, who it is assigned to, and which app this task relates to. * **Task instructions.** This describes how to perform the task. * **Comments.** Use this to record information about the execution of the task. This is a rich text editor and it is possible to paste screenshots or other images. * **Attachments.** Use this to store files that contain information about the execution of the task. When you have completed the task click on 'complete task' to mark the task as completed. Once you have completed a task you will no longer receive notifications that it is due (or overdue). {% hint style="info" %} Tasks can only be completed by the people they have been assigned to, or by the person that assigned the task. {% endhint %} # Insights Insights in AppControl collects and manages information about your Mendix apps. Every time an app is analyzed the information in Insights is updated. Use Insights to create reports, explore data about your apps, and use it as your central repository for all things Mendix. # Components The Components tab enables you to search through information about the following Mendix components: * **Mendix Runtimes.** The Mendix versions in use by your apps. * **Modules.** The Marketplace modules in use by your apps. * **Widgets.** The widgets in use by your apps. * **Java Libraries.** The Java libraries in use by your apps. * **Javascript Libraries.** The Javascript libraries in use by your apps.
Actions The following actions are available: * **Export.** The components that are visible (based on the filters you have selected) are exported to an Excel spreadsheet. * **Assign Task.** The task assignment page will be shown, pre-filled with the apps associated with all of the components that are visible (based on the filters you have selected).
Filters Depending on the type of component your are searching for various filters are available. The following describes these filters: * **Environment type.** The environment type that uses the components you are searching for. This will limits results to apps that have environments of the type that you have selected. * **App.** The specific app that you want to search for. If you leave this blank all apps will be searched. * **Name.** The name of the component you want to search for. * **Version.** The version of the component you want to search for. * **Latest Compatible.** The latest version of this component that is compatible with the version of Mendix used by your app. * **Latest Version.** The latest version of this component that is available. * **Latest Version.** (Not searchable) Shows the latest version of this component (if known). The version number is red if this component is not the latest, or green if it is. * **Marketplace.** Whether or not this component came from the Mendix Marketplace. * **AI.** Whether or not this is an AI-capable component. * **JAR name.** For Java libraries, the name of the JAR file you want to search for. * **Processed on.** When AppControl last updated the list of components for the selected environment. If just deployed a new revision to an environment it may take a while before the list is updated. If the filters you select return no results because there are no environments (of the selected type) for the selected app, or because the revision for that environment hasn't been analyzed yet, you will be notified.
# Reports The Reports tab displays all environments detected by AppControl in all of your hosting platforms. For each environment, if the deployed revision has been analyzed, a series of reports is available. Select the report type you want to generate from the 'Report type' selector. If AppControl does not have sufficient access to the app, or the deployed revision has not yet been analyzed, the message 'no deployed app' will be displayed. You can download a PDF version of the app report by clicking on the 'download PDF' link. Note: This feature must be configured first by your platform administrator from the feature settings tab in the [System Configuration](/administration/system/system-configuration) page. The following report types are available: * [Governance.](/dashboards/insights/reports/governance) Reports on the current governance status of the selected app / environment, and lists all details of issues and violations related to your controls. * [Security.](/dashboards/insights/reports/security) Reports on the current security status of the selected app / environment, and lists all details of security issues and violations. # Governance The Governance Report contains the information described below. Each tile shows the result of a scan of 1 or more policy checks related to the governance area shown. If the governance status for a particular areas shows an error, warning, or information, an additional table will appear below the status tiles that lists which policy checks failed. Use these tables to determine what has failed and how to resolve it.
App Info * **Name.** The name of the app. * **Mendix App ID.** The Mendix App ID for this app (also known as a 'project ID'). * **Hosting platform.** The hosting platform that AppControl detected this app on. * **App repository.** The app repository that this app is using to store it's project files.
Environment Info * **Name.** The name of the environment. * **URL.** The URL of the environment. * **Mendix Version.** The Mendix version in use by this environment. * **Model Version.** The model version that is currently deployed to this environment.
Code is Secure * **Description:** Code has been checked for known execution and access control vulnerabilities. * **Policy Checks:** All checks with the category 'Security' with the exception of COMP\_0001.
Code is Standard * **Description:** Code conforms to naming, organizational, documentation, and architectural best practices and standards. * **Policy Checks:** All checks with the category 'Standards'.
Audit Readiness * **Description:** App version, access control, configuration, logging, and control system changes are monitored, recorded, and secured from deletion so that they are available for audits. * **Policy Checks:** GOV\_0006
Components are Secure * **Description:** Third-party and vendor-supplied components do not contain known security vulnerabilities. * **Policy Checks:** COMP\_0001
Latest Components * **Description:** App is using up to date versions of third-party and vendor-supplied components, compatible with the currently used runtime. * **Policy Checks:** COMP\_0007, COMP\_0008, COMP\_0009
Supported Components * **Description:** The third-party and vendor-supplied components used by the app are supported by their vendors in case of bugs or critical issues. * **Policy Checks:** COMP\_0003, COMP\_0004
Logs Monitored * **Description:** App logs are reviewed daily for suspicious activity, infastructure and integration failures, and warnings that may lead to application failures. * **Policy Checks:** GOV\_0003
Access Control Monitored * **Description:** Who has access to the management systems used to change app code, configuration, and deployed software versions is monitored and recorded. * **Policy Checks:** GOV\_0004
Operational Tasks Monitored * **Description:** Tasks necessary for the secure and daily operation of the app are monitored, and have been completed on time. * **Policy Checks:** GOV\_0005
Controlled Releases * **Description:** Releases have been reviewed and approved, release notes documented, tested for policy compliance, and is known who the code committers are. * **Policy Checks:** GOV\_0001
Controlled Configurations * **Description:** Changes to app configurations are reviewed and approved, part of a planned release, and it is known who created and deployed the configuration. * **Policy Checks:** GOV\_0002
# Security The Securrity Report contains the following information:
App Info * **Name.** The name of the app. * **Mendix App ID.** The Mendix App ID for this app (also known as a 'project ID'). * **Hosting platform.** The hosting platform that AppControl detected this app on. * **App repository.** The app repository that this app is using to store it's project files.
Environment Info * **Name.** The name of the environment. * **URL.** The URL of the environment. * **Mendix Version.** The Mendix version in use by this environment. * **Model Version.** The model version that is currently deployed to this environment.
Policy Compliance The policy compliance tile shows a summary of the results of the policy check for the revision that is deployed to the selected environment. For each policy check category the following information is displayed: * **Total check results.** The total number of failed check results. (check result = unique combination of check type and specific element) * **Percentage.** The percentage shows the percentage of checks (=check types) that were configured for this scorecard that passed (= did not generate any failed check results). * **Star rating.** The star rating is a simple visualization of the percentage of checks that passed where 100% = 5 stars.
Vulnerable Components The vulnerable components tile shows a summary of the components used by the currently deployed revision that have known vulnerabilities. For each vulnerable component the following information is displayed: * **Component Type.** The type of component. * **Name.** The name of the component. * **Version.** The component version. * **Vulnerabilities.** The list of known vulnerabilities.
Security Risks The security risks tile shows a summary of the security risks found in the currently deployed revision. Security risks represent all security type policy checks that have a high risk that failed. For each detected risk the following information is displayed: * **Severity.** The severity level of the risk. * **Risk ID.** The policy check ID of the risk. * **Security Risk.** A brief description of the risk. * **Element Type.** The type of app element that is affected by this risk. * **Vulnerabilities.** The number of vulnerabilities of this type that were found in the app.
# Users The users tab shows an overview of the unique number of users per app per enviornment for the selected day. Once a day AppControl analyzes the access logs for an app to determine the number of unique users. {% hint style="info" %} Detecting the unique number of users is an estiamte and not 100% accurate. AppControl scans access logs for all unique combinations of IP address and Browser User Agent that have accessed the Mendix runtime (/XAS), and uses this to create the total number of users. {% endhint %} # Logs The **Logs** tab provides a detailed overview of log messages per log level (such as Error, Warning, or Info) for each app and environment on the selected day. This helps you quickly identify where most log activity is happening and focus on potential issues. From the **first-level summary** (log level totals per environment), you can drill down to the **second-level summary**, where log messages are aggregated by **log node** within the selected environment. This view helps pinpoint which component of your app is generating specific logs. Clicking on a **log node** opens the **log message view**, where you see all individual log messages generated by that node. Each message includes additional status indicators that provide more context: * **Ignored** – the message is excluded from log level totals and doesn't contribute to error or warning counts. * **Alert** – an alert has been generated based on this message. * **Solution available** – a suggested solution is available for review and action. You can also see **why** a message is flagged as Ignored, Alert, or Solution—either because of a **log processing rule** or because a **solution has been linked** to it. Additionally, you can **export** log messages or summaries at every level—environment, log node, or individual log message—for further analysis or sharing. > **Note:** Ignored messages do **not** count toward the log level totals (e.g., Errors, Warnings), providing a clearer and more focused view of your log data. This drill-down flow—from environment summary to log node to individual log messages—allows you to efficiently investigate logs, understand the context of alerts, and act on available solutions. # Audit The **Audit** tab provides a complete overview of audit events generated by AppControl and supported hosting platforms. These events give you visibility into changes, access, and system activity across your apps and environments, supporting traceability, compliance monitoring, and incident analysis. Where the Logs tab focuses on technical runtime messages, the Audit tab focuses on **governance-relevant events** — structured records of actions, state changes, and control outcomes across the lifecycle of your applications. View all [audit event types](#audit-event-types) supported by AppControl. *** ### What You See in the Audit Tab The Audit tab displays a filterable list of audit events across your selected scope. Each event includes: * **App** – The application the event relates to * **Environment** – The environment (e.g., Production, Acceptance) * **Event ID** – Unique identifier of the audit event * **Timestamp** – When the event occurred * **Event Type** – The classification of the event (e.g., `CONTROL_FAILED`, `REVISION_CHANGED`) * **Actor** – The user or system responsible for the event * **Event Source** – The originating system (e.g., SYSTEM, hosting platform) * **Event Details** – Structured metadata describing the event The table can be filtered by any of these fields to narrow the view to specific apps, environments, actors, or event types. *** ### Filtering and Investigation You can filter audit events by: * App * Environment * Event ID * Date / time range * Event type * Actor * Event source * Event detail content This makes it possible to: * Investigate a specific incident * Review all control failures in a given period * Trace changes in a specific environment * Analyze activity performed by a particular actor * Support internal audits or external compliance reviews Audit events are stored as structured data, enabling consistent filtering and export. *** ### Event Types Audit events are categorized by **Event Type**. Examples include: * `CONTROL_FAILED` * `CONTROL_PASSED` * `REVISION_CHANGED` * (additional event types are documented below) Each event type represents a specific governance-relevant occurrence within the lifecycle of an app or environment. > A complete overview of supported event types and their meaning is provided in the table below. *** ### Relationship to Compliance Policies Compliance Policies (such as **GOV\_0001 – Change Management**) analyze audit events to determine whether governance controls are functioning as expected. For example: * A missing approval before deployment may result in a `CONTROL_FAILED` event. * A revision update may generate a `REVISION_CHANGED` event. * Access-related actions may generate user or system activity events. Audit events therefore form the **evidence layer** used by Compliance Policies to continuously assess control effectiveness. *** ### Exporting Audit Data You can export audit events directly from the Audit tab. Exports can be used for: * Internal governance reporting * External audits * Incident documentation * Long-term record keeping Exports reflect the current filter selection, allowing you to extract only the relevant subset of events. *** ### How Audit Differs from Logs | Logs | Audit | | -------------------------------- | ------------------------------------------------- | | Technical runtime messages | Governance-relevant lifecycle events | | Aggregated by log level and node | Structured per event with metadata | | Focused on troubleshooting | Focused on traceability and control monitoring | | Driven by runtime logging | Driven by lifecycle actions and governance checks | Both tabs complement each other: * **Logs** help you understand what happened technically. * **Audit** helps you understand what happened from a governance and control perspective. *** ### Using Audit in Practice Typical use cases include: * Reviewing failed controls after a release * Preparing evidence for ISO 27001 or SOC 2 audits * Investigating unexpected changes in Production * Monitoring change management adherence * Tracing user or system activity over time The Audit tab provides a structured, centralized, and exportable record of lifecycle activity across your Mendix landscape. *** ### Audit Event Types The following audit events are generated by AppControl: | Control Domain | Event Code | Event Name | Description | | ----------------- | ------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Change Management | DEPLOY\_STARTED | Deployment started | A deployment process has been initiated for an app or environment, marking the start of a controlled change execution. | | Change Management | DEPLOY\_COMPLETED | Deployment completed | A deployment has successfully completed, confirming that the change was applied to the target environment. | | Change Management | DEPLOY\_FAILED | Deployment failed | A deployment attempt failed, indicating that the intended change was not successfully applied. | | Change Management | ROLLBACK\_EXECUTED | Rollback executed | A rollback has been executed, reverting the environment to a previous known revision after an issue or failed deployment. | | Change Management | CONFIG\_CHANGED | Configuration changed | A configuration setting was modified in the environment, impacting runtime behavior or operational setup. | | Change Management | REVISION\_CHANGED | Revision changed | The active application revision was updated, reflecting a new version or build deployed to the environment. | | Change & Release | CHANGE\_APPROVED | Change approved | A change request has been formally approved in accordance with defined change management controls. | | Change & Release | CHANGE\_REVIEW\_COMPLETED | Change review completed | A change review process has been completed, documenting assessment prior to approval or deployment. | # Policies The policy manager is used to configure the policies that control your apps. AppControl has a default set of policy checks and all of these are included in the global policy. This is automatically created, configured and is checked automatically. The global policy can be configured to meet the needs of your organization. Policies have a specific scope. The scope determines which apps a policy applies to. There are 3 differentscopes in AppControl: * **Global.** This policy will apply to all apps in your organization. * **Group.** This policy applies to all apps in a specific app group. * **App.** This policy applies to a specific app. Policies are applied hierarchically (Global > Group > App), however only a single policy is used to check an app. If for instance a group policy is configured, this policy will be used instead of the global policy. If you want specific checks to be mandatory for all apps (or the entire policy), you can make the complete global policy mandatory or just specific checks in the global policy. There are 2 tabs in the policy manager: * [**App**](/administration/policies/app)**:** This is an overview of all your app policies. These policies contain the policy checks that check the state of your apps. * [**Data**](/administration/policies/data)**:** This is an overview of your data policies. Data policies are used to classify app data, module role access, and user role access. The information in these policies is used by app policies to check the security of your apps. # App Policy **App Policies** are used to enforce specific configurations and actions within applications to ensure compliance and strengthen security. These policies provide administrators with the ability to define rules and checks that apps must adhere to. They can include mandatory settings which apps cannot override, apply certain actions when checks fail, and even incorporate different severity levels for potential issues. App policies help maintain a consistent operational environment across all applications in an organization by controlling configurations and responses to non-compliance. For details about all available policy checks see the 'Checks' section of this documentation. Policy settings and actions at the policy check level determine how compliance issues within an application are managed and addressed. Settings define whether a policy is mandatory, its applicability, and the severity of any potential non-compliance issues. Actions specify what happens when a check fails, such as doing nothing, generating an alert, or assigning a task. These configurations ensure that the necessary controls are in place to handle rule violations effectively, maintaining application security and organizational compliance.
Policy Settings Aside from the individual policy checks that you enable or configure, there are settings that apply to the entire policy: * **Mandatory?** If enabled, this policy applies to all apps in the scope (Global or Group) of the policy, and the configuration cannot be overridden by group or app administrators (for Global policies) or app administrators (for Group policies). * **Ignore Marketplace modules?** If enabled, policy checks will not apply to Marketplace modules. * **Enabled?** If set, this policy will be checked. If not, this policy will not be checked. * **Severity.** The severity level for this policy check. The configured level will be used when creating a check result when this check fails.
Policy Actions When a policy check fails it is possible to configure an action to take. This action will only occur once per failure of a specific check type. If there are multiple check results for a given check type, the action will only execute once. The following actions can be configured: * **Nothing.** (Default) No additional action will be taken. * **Alert.** An alert will be generated with the details of the check type that failed and the environment. This will appear in the AppControl alerts dashboard. * **Assign Task.** When this check fails the selected task will be assigned. Note that if a task is assigned, it will not be assigned multiple times. If the assigned task is completed and the check fails again, a new task will be assigned. When this action is selected the following options appear: * **Task library.** The task library that contains the task you want to assign. Only tasks with the scheduled type 'One Time' can be selected. Note: The task libraries that are available to be selected from depends on the policy scope: * Global: Only the Global Task Library can be used. * Group: The Global and Group task libraries can be used. * App: The Global, Group and App libraries can be used. * **Task to assign.** The task you want assigned. * **Assign task to.** Which role you want to assign the task to. If the task assignment type has been pre-configured in the task template it is not possible to change it here.
# Data Policy Data policies are essential guidelines and rules that help manage and safeguard application data. They provide a framework to: * **Classify Data**: Categorize data based on sensitivity and relevance, ensuring appropriate handling. * **Validate Access**: Confirm that modules and users have the appropriate level of access and permissions, tailored to their role. * **Support Security Measures**: Serve as a reference for app policies to ensure application security and prevent unauthorized access or excessive rights. These policies are crucial for maintaining data integrity, confidentiality, and compliance with regulatory standards. Data policies are automatically generated the first time an app is processed by AppControl. When a data policy is first created it has the following statuses: * **Data Classification: INCOMPLETE.** You need to classify all data in your domain model according to its access and sensitivity, and flag personal data stored in your app. * **Module Role Access: REQUIRES VALIDATION.** You need to validate the mdoule and entity access that has been granted to each module role. * **User Role Access: REQUIRES VALIDATION.** You need to validate the module roles that have been granted to your user roles, which users they can manage, what level of data they can access, and categorize your user roles. To complete your data policy so that it is complete and validated, perform the following steps: Classify Data, Validate Module Roles, Validate User Roles.
# Classify Data The Classify Data tab is where you assign a sensitivity classification to every entity and attribute in your Mendix application. Completing this classification is required before a data policy can be considered fully configured. *** **Classification levels** Each entity and attribute must be assigned one of the following levels: Level 1 — Public No restrictions. Safe for unrestricted access or publication. Level 2 — Internal For internal use only. Not intended for external audiences. Level 3 — Confidential Sensitive data with restricted access. Requires explicit authorization. Level 4 — Restricted Highest sensitivity. Strictly controlled access, often subject to regulatory requirements. In addition to the classification level, attributes can be flagged as containing personal data. Use this to identify fields that fall under GDPR or similar data protection obligations. *** **Navigating the view** You can navigate the classification view in two ways: Left panel (domain model tree): Drill down from modules to entities using the expandable tree. This gives you a structural overview of your data model. Right panel (list view): Navigate by selecting a module to see its entities, then select an entity to see its attributes. The list updates based on your selection. Both navigation paths lead to the same classification interface — use whichever suits your workflow. *** **Classifying data manually** To classify an individual item, use the Default Level dropdown in the list to assign the appropriate level. For attributes, you can additionally toggle the personal data flag. The Status column shows whether classification for that item is complete. *** **Bulk classify** To speed up classification, use the Bulk classify button to apply a classification level to multiple items at once. How to use it: 1. Select the items you want to classify using the checkboxes. 2. Choose a Classification Level from the dropdown. 3. Optionally configure the two additional options described below. 4. Click Bulk classify. Bulk classify options: Auto-classify — When enabled, the selected modules or entities will automatically classify any new entities or attributes added in the future, using the level you have set. This is useful for keeping newly imported modules or extended entities compliant without manual follow-up. Override Classification — When enabled, the bulk action will overwrite any classification levels that have already been set on the selected items. If this is left off, only unclassified items will be updated and existing classifications are preserved. Note: Bulk classify operates at the level you are currently viewing. If you are viewing the module list, it applies to modules. If you are viewing entities or attributes, it applies to those respectively. # Module Roles The Module Roles tab is where you review and validate the access rules defined in your Mendix application. For each entity, you can inspect which module roles have access, what their default access rights are, any XPath constraints that apply, and what read/write permissions exist per attribute. Validating access rules is an important step in your data policy — it confirms that you have reviewed and accepted the current security configuration of your application. *** **Navigating the view** Navigation works the same way as in the Classify Data tab, using either the left panel tree or the breadcrumb list on the right. There are four levels: Modules — the top-level list of all modules in your application. Entities — the entities within a selected module. Access Rules — the module roles that have an access rule defined for the selected entity. For each role you can see: * Create — whether the role can create new records of this entity. * Delete — whether the role can delete records of this entity. * Constraint — any XPath constraint applied to limit which records the role can access. * Default access — the default member access applied to attributes (read, write, or none). * Auto Validate — whether this access rule is set to auto-validate. * Status — whether this access rule has been validated. Member Access Rules — the individual attributes and associations for a selected access rule, showing the access level (read, write, or none) that the module role has for each member. *** **Validating access rules manually** To validate an individual access rule or member access rule, use the Status column. Once reviewed, mark the item as validated to confirm you have accepted the current configuration. *** **Bulk validate** To validate multiple items at once, select them using the checkboxes and click Bulk validate. This marks all selected access rules or member access rules as validated in one action. Bulk validate has one additional option: Auto-validate — When enabled, the selected modules, entities, or access rules will automatically be marked as validated whenever their security configuration changes in the future. This means future changes to access controls will be accepted without requiring a manual review. {% hint style="warning" %} Warning: Auto-validate should be used with caution. It is good practice to review all changes to access rules before accepting them. Enabling auto-validate on sensitive entities may cause security changes to go unnoticed. Only use this option for modules or entities where the access configuration is stable and well-understood. {% endhint %} Note: Bulk validate operates at the level you are currently viewing. If you are viewing the access rule list, it applies to access rules. If you are viewing member access rules, it applies to those respectively. # User Roles The User Roles tab is where you review and validate the user roles defined in your Mendix application. For each role you must confirm a set of required settings before it can be marked as validated. These settings are used by AppControl's policy checks to evaluate whether your application's security configuration is appropriate. The left panel lists all user roles in your application. Roles showing a warning icon still require validation. Roles showing a green checkmark have been validated. *** **Validating a user role** Select a user role from the left panel to open its detail view. If the role has not yet been validated, you will see a notice prompting you to review and confirm the settings before proceeding. Once all required fields are filled in, click Mark as validated in the top right corner. *** **Settings to confirm** Each user role requires the following settings to be configured before it can be validated. User role type — Identifies the nature of the role to AppControl. This is required for security checks performed by app policies. The available types are: * System Administrator Role: The system administrator role as defined in your Mendix application. This type is detected automatically and cannot be changed. * Anonymous User Role: The role assigned to unauthenticated (anonymous) users. This type is detected automatically and cannot be changed. * Default User Role: The role automatically granted to newly created users. Only one user role in your application can be assigned this type. * Admin Role: Use this for roles with administrative privileges, such as managing other users or controlling access to important application data or functions. * User Role: Use this for all other non-administrative roles. Max data access level — The highest classification level that this user role should be permitted to access. This is checked against your data classifications to identify potential over-exposure. Can access personal data — Enable this if the role is permitted to view personal data belonging to other users. If left off, the role is expected to only access its own personal data or none at all. *** **Additional role information** The lower section of the detail view is read-only and shows additional information about the role drawn from your Mendix security configuration. User management — Shows whether the role can manage all users or manage users without a role assigned. Manageable roles — Shows which other user roles this role is permitted to manage. If no manageable roles are configured, this section will show that the user cannot manage other roles. Module roles — Lists the module roles that are mapped to this user role, along with their validation status. This gives you an overview of which underlying access rules are in effect for this role. # Pipelines Pipelines are used to standardize and automate the build and deployment of apps. Platform Administrators can create global, group or app pipelines, enabling you to enforce standards across all of your apps. However, it is also possible to allow Group Administrators and App Administrators to create pipelines if you want to allow more freedom and flexibility in creating releases. For more informtion on enabling this feature see the [System Configuration](/administration/system/system-configuration) documentation. There are 3 different types of pipelines: * **Global.** These pipelines apply (and are visible) to all apps. Only Platform Administrators can manage global pipelines. * **Group.** These pipelines apply (and are visible) to all apps in a specific group. Only Platform and Group Administrators can manage group pipelines. * **App.** These pipelines apply (and are visible) to a single app only. Platform, Group and App Administrators can manage app pipelines. {% hint style="info" %} By default only Platform Administrators can create pipelines. Pipelines created by Platform Administrators are read-only for other administrators. If you want Group or App Administrators to be able to create their own pipleines you must enable this feature in the [System Configuration](/administration/system/system-configuration) page. {% endhint %} After a pipeline has been created they are automatically available to be used for a release by an app administrator and do not require additional configuration. To add a new pipeline click on 'add pipeline'.
Info When adding a new pipeline the following options are available: * **Name:** This is the name that is visible to users of the pipeline. Note: When changing the name it is immediately saved. You don't need to click the 'save' button to make this visible. * **Version:** The version of this pipeline. The version is incremented automatically when you choose to update the pipeline. When new releases are created that use this pipeline, the newest version will always be used. By default a pipeline is enabled. If you want to disable a pipeline click on the 'disable pipeline' button. When a pipeline is disabled is cannot be executed and it is no longer visible as an option when creating a new release.
Scheduling Chose the scheduling configuration that you want to use for this pipeline. The following scheduling options are available * **On Demand:** This pipeline will be available to users when manually creating a release. * **On Commit:** A new release will be automatically creates when a new commit is detected for the selected branch. * **Daily:** A new release will be created daily for the selected branch. * **Weekly:** A new release will be created daily for the selected branch. Note: For On Commit, Daily or Weekly schedules, the pipeline will only be scheduled for an app after an App Administrator creates a new release for their app. After that, the release will automatically be created and updated.
Versioning Configure how version numbers and release notes are generated for each release created by this pipeline. Note: These options are used when creating a new release either manually (On Demand) or automatic (a pipeline that uses a recurring schedule). When creating a release manually it is possible to override the version number and release notes. * **Base Release Number:** This is the base release number that will be used for generating release numbers for releases. For each new release the base release number will be incremented. * **Release number generation:** How the base release number will be incremented. The following options are available: * **Increment patch version (BRANCH):** The patch version number of the last successful release for the selected branch will be incremented by 1. * **Increment minor version (BRANCH):** The minor version number of the last successful release for the selected branch will be incremented by 1. * **Increment patch version (APP):** The patch version number of the last successful release for the app will be incremented by 1. * **Increment minor version (APP):** The minor version number of the last successful release for the app will be incremented by 1. * **Release notes generation:** How release notes will be generated for a release. The following options are available: * **Use latest commit:** The commit message of the revision used for the release will be used. * **Use last release:** The commit messages of all revisions since the last successful release for the selected branch will be used. Note: This total length of the release notes will be truncated to 2000 characters.
Actions At the bottom of the pipeline page the following actions are available: * **Update pipeline:** This action will apply the changes you made on the page, and will increment the version number of the pipeline. * **Enable:** If a pipeline is disabled you can renable it. This makes the pipeline visible to app administrators to be used for new releases. * **Disable:** By default a pipeline is enabled. If you want to disable a pipeline click on this button/ When a pipeline is disabled is cannot be executed and it is no longer visible as an option when creating a new release. * **Delete:** If you delete a pipeline it cannot be used for releases anymore. All pipeline configurations will be deleted, however historical release information will not be affected. By default a pipeline is enabled. If you want to disable a pipeline click on the 'disable pipeline' button. When a pipeline is disabled is cannot be executed and it is no longer visible as an option when creating a new release.
Pipeline Tasks A pipeline consists of 1 or more tasks that are executed in order. A variety of task types are available to choose from. Click on 'add task' to add a new task to your pipeline. After selecting a task type a pop-up will appear enabling you to configure the task. See the sub-pages of this page for information about each task type.
# Approval An approval task enables you to get the approval of an app owner or app administrator before the pipeline will continue executing. In general this task should be placed first in the pipeline, however you can place it anywhere that you require an approval. The pipeline will pause execution until the required approvals have been received. The following options are available: * **Approvers:** Select who is required to approve the release. When the pipeline executes the approvers will be sent an e-mail to notify them that a release is waiting for their approval. * **Notification frequency:** How often (in days) that the approvers will be notified that the release is waiting for approval. # Assign Task An assign task pipeline task enables you to assign a task to be completed before a pipeline can continue executing. Typically this is used to have someone do manual checks of a release, or perform an action that can't be automated. When a new release is created that contains one or more 'assign task' steps, all tasks in the pipeline will be assigned at the same time. When pipeline execution reaches a task step, it will pause execution until the task has been completed. If a task is overdue and is not completed within the number of days configured (see below), the pipeline task will fail. See the [tasks](/administration/tasks) section of the documentation for more details on how to create tasks. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Library:** The task library that contains the task you want to assign. * **Task name:** The task that will be assigned by this step. Note: Only tasks with the schedule type 'one time' will be visible here. * **Assign task to:** Who the task should be assigned to. Note: If the task assignment type has been set in the configuration of the task you cannot change it here. * **Override task due date:** If enabled, you can override the number of days after which this task is due. * **Due after (days):** The number of days after which the task is assigned that the task is due. (Only visible if you have selected to override the default task due date.) * **Fail after (days):** The number of days after the due date, if the task has not yet been completed, that this pipeline step will fail. # Backup A backup task creates a backup of your environment. The backup is not stored in AppControl but in your Hosting Platform. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. # Build A build task creates a deployment package for your app. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Which branch do you want to use?** Specify the source branch for this pipeline. The choices are: * **Mainline :** When selected, the pipeline will automatically use the mainline of the app for the build. * **Specific branch :** When selected the user of the pipeline must select a specific branch to be used. * **Branch name** : When selected, provide the name of the branch to use. When the pipeline executes the system will try to find a branch with the name you provide. * **Which revision do you want to use?** Specify the source revision for this pipeline. The choices are: * **Latest :** When selected, the pipeline will automatically use the latest revision of the source branch configured for the pipeline. * **Specific revision :** When this is selected the user of the pipeline must select a specific revision to be used each time the pipeline is run. {% hint style="info" %} If you select a branch or revision in this task, these cannot be changed by the user of the pipeline when creating a new release. If you want the user to be able to select a specific branch or revision you must select 'specific branch' or 'specific revision'. {% endhint %} # Call API The call API task enables you to call an external API and parse the output. This can be used for instance to run external tests, or trigger other system to run other tasks. The following options are available: Note: The following variables can be used in the request URL / body, and the response URL / body: * %%REVISION\_ID%% - The ID of the revision used for this release. * %%BRANCH\_NAME%% - The name of the branch used for this release. * %%MX\_APP\_ID%% - The Mendix App ID of the app used for this release. * %%ENVIRONMENT\_ID%% - The environment ID of the environment used for this release. * %%APP\_URL%% - The URL of the environment used for this release. * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **API call type:** Synchronous or Asynchronous. When 'Synchronous' is selected the API will be called and the response will be parsed directly to determine if it was successful. When 'Asynchronous' is selected, a second API will be polled to determine if the call was successful or is still being processed. * **Use Authentication.** If selected, the call will use authentication. * **Authentication:** The authentication method to use for authentication. * **Username:** The username to use for authentication. * **Password:** The password to use for authentication. * **Use custom HTTP headers:** If selected, the call will use the custom HTTP headers that you configure. For each custom header you can specify the following: * **Name.** The name of the HTTP header. * **Value:** The value of the HTTP header. * **Request operation:** Select the HTTP operation used by the API: GET or POST. * **Request URL:** Enter the full URL used for the API request. The variables listed above can be used in the URL. * **Request body:** For POST type requests, the HTTP body to be sent. The variables listed above can be used in the body. * **Response operation:** Select the HTTP operation to be used for the response by the API: GET or POST. This option is only used when you have selected 'Asynchronous' for the API call type. * **Response URL:** Enter the full URL used for the API response. The variables listed above can be used in the URL. This option is only used when you have selected 'Asynchronous' for the API call type. This is the URL that will be called to check the response of the initial API request. * **Response body:** For POST type requests, the HTTP body to be sent. The variables listed above can be used in the body. This option is only used when you have selected 'Asynchronous' for the API call type. This is the body that will be sent to the API to check the status of the initial API request. * **Timeout (s):** The timeout (in seconds) to be used for all API calls. * **Success check:** The Regex to be used to determine if the API call succeeded. This is used for both synchronous and asynchronous API calls and will be used to parse the response from the API request. Use a regex that is supported by the Mendix *isMatch()* string function. For synchronous calls, if you leave this empty the call will be successful if an HTTP 2XX status code is returned. * **Processing check:** The Regex to be used to determine if the API call is still being processed. This is used only for asynchronous API calls and will be used to parse the response from the API (as returned from the Response URL configured above). Use a regex that is supported by the Mendix *isMatch()* string function. # Check Policy A check policy task will check the policies applicable to the target app and environment for compliance. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **What is the minimum policy status required for this check to pass?** If the policy state returned by the policy check is the same or better than the selected status, the policy check task will pass. E.g. If you select 'warning' and the policy check returns the status 'warning', the policy check task will pass. {% hint style="info" %} If the revision for the current release has already been checked previosuly by the system (E.g. someone has manually checked the revision, or it was already deployed to a different environment), the stored result of the check will be used. However, if the revision has not yet been checked, the model for the revision will be processed and checked during the pipeline execution. This will incur delay during your pipeline execution as revision checks can take a long time to execute. Additionally, if the settings of the policy that is applicable to your app have changed since the last time the revision was checked, it will be checked again by this task. {% endhint %} # Deploy A deploy task deploys a build to an environment. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Target Environment:** Select the target environment type that should be use for this deployment. When the pipeline is executed the first environment of this type for the app will be automatically used as the target of the pipeline. * **Select environment each time?** When selected, the user of the pipeline will need to select a specific environment when the pipeline is run. * **Perform restart?** When selected, the target environment will be restarted after deploying the build package. {% hint style="info" %} If you select an environment type in this task, this cannot be changed by the user of the pipeline when creating a new release. If you want the user to be able to select a specific environment you must select 'select environment each time'. {% endhint %} # Deploy Configuration A deploy configuration task deploys a configuration to an environment. The configuration to be deployed is selected at the time the pipeline is executed. Configuration are managed from the environments page of an app. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Is optional:** If enabled, no configuration has to be selected by the user when creating a release. If no configuration is selected, the task will be skipped. # Notification A notification task is used to send e-mail notifications. The following settings are available for this type of task: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Recpient(s):** Who the notification should be send to: * **App Owner.** Send the notification to the app owner(s). * **App Administrator.** Send the notification to the app administrator(s). * **Owner & Administrator.** Send the notification to all app owners and app administrators. * **Specific E-mail.** Send the notification to a specific e-mail address. * **E-mail Address(es):** The comma separated list of e-mail addresses to send the notification too. Only visible if the Recipient type is set to 'Specific E-mail'. * **Subject:** The subject of the notification. * **Message:** The content of the notification. The following tokens can be used in the message and will be replaced when the notification is sent: * `{%ApplicationName%}` - The name of the app that is the target for this release. * `{%Environment%}` - The name of the target environment for this release. * `{%Branch%}` - The name of the branch that is the source of this release. * `{%Revision%}` - The revision ID that is used for this release. * `{%ReleaseNotes%}` - The release notes for this release. * `{%ReleaseVersion%}` - The release version of this release. # Restore The restore task will restore a previously created backup of your environment to the target environment. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Target environment.** The environment to restore to. If selected the user of the pipeline cannot select a different environment. * **Select target environment each time.** If selected, the user of the pipeline can select the environment to restore to when executing the pipeline. * **Allow restore from different environment.** If selected, the user of the pipeline can select to restore from a different environment than the target environment. By default restores can only be done from the same environment as the target environment. # Start / Stop A start / stop task is used to start or stop your environment. The following settings are available for this type of task: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. * **Action.** The action to be taken. The options are: * Start. The environment will be started. * Stop. The environment will be stopped. * Restart. The environment will be restarted. # Validate Configuration The validate configuration task will check the configuration deployed by a pipeline to determine if all settings were set correctly. This task only works if you have a deploy configuration task earlier in your pipeline. When the task executes it does the following: * Downloads the current environment settings (constants, scheduled events, custom runtime settings) from the target environment. * Compares the current settings (names and values) to the settings in the configuration that was selected and deployed earlier in the pipeline. * If all settings match the task completes successfully, if not the task will fail. The following options are available: * **Proceed on Failure.** If enabled, the pipeline will continue executing when this step fails. # Tasks The task library is used to configure the tasks that you want to be able to assign in AppControl. Tasks are manual activities that are performed by persons to manage the operation of your apps. For example: renewing SSL certificates every year, renewing functional accounts, checking permissions in your apps for auditing purposes, etc. There are 3 levels of task libraries in AppControl: * **Global.** These tasks are defined and assigned by platform administrators. Tasks in this library can also be shared with group and app administrators so that they can be assigned by them as well. * **Group.** These tasks are defined and assigned by group administrators. Tasks in this library can also be shared with app administrators so that they can be assigned by them as well. * **App.** These tasks are defined and assigned by app administrators. These are app-specific tasks and can only be assigned to a specific app. Depending on your role there are 1 or more tabs visible that show you the Global, Group, and App task libraries. The task templates defined in the library are visible in the list. To add a new task template click on 'Add'. Creating and assigning tasks is a 2-step process: * **Create task in task library.** In this step you define the task details and instructions. After creating it is is available in the task library to be assigned. This step is performed from the Administration > Tasks page. * **Assign the task.** In this step you choose who to assign the task to, which apps the task applies to, and when it should be assigned. This step is performed from the Tasks page.
Task Template
# Single Task The task type 'Single Task' is the most basic type of task. It consists of instructions for the task assignee to complete, has a due date, has a schedule type, and can be pre-configured to be assigned to a specific type of role A 'single task' template has the following options: * **Name.** The name that is visible to users of this task. * **Short description.** A short description that is displayed to help users identify this task. * **Description.** Full description of what the person that this task is assigned to should do. This is a rich text editor and you can embed links and images if needed. * **Task Type.** Can be: * **Single Task.** A single task with a single set of instructions, assigned to a single role (or list of persons). * **Task List.** A list of tasks, each of which can be assigned to a different role. * **Schedule type.** How often this type of task should be performed. If you choose a recurring task, AppControl will schedule the task automatically when you assign it and will create new instances of the task as needed (E.g. For 'Monthly' tasks, AppControl will create a new task every month when it is assigned). * **Created by.** Who created this task. (read only) # Task List The task type 'Task List' is a task that consists of a parent task and multiple sub-tasks. Each sub-task consists of instructions for the task assignee to complete, and can be pre-configured to be assigned to a specific type of role. When a task list is assigned, the parent task is assigned in addition to each of the sub-tasks. It is possible to configure which role each sub-task (and the parent task) should be assigned to. If you do not configure which role to assign the sub-task to, this will be done by the task assigner when the task is assigned. A 'task list' template has the following options: * **Name.** The name of the task list that is visible to users of this task. * **Short description.** A short description for the task list that is displayed to help users identify this task list * **Description.** Full description of what the purpose of this task list is. This is a rich text editor and you can embed links and images if needed. * **Task Type.** Can be: * **Single Task.** A single task with a single set of instructions, assigned to a single role (or list of persons). * **Task List.** A list of tasks, each of which can be assigned to a different role. * **Schedule type.** How often this type of task should be performed. If you choose a recurring task, AppControl will schedule the task automatically when you assign it and will create new instances of the task as needed (E.g. For 'Monthly' tasks, AppControl will create a new task every month when it is assigned). * **Created by.** Who created this task. (read only) * **Configure assignment type.** If selected, you can pre-configure the assignment type of the parent task and each of the sub-tasks. Note: This prevents the task assigner from selecting which role to assign this task list to. This is convenient when you know which roles are responsible for each of the sub-tasks. * **Assignment type.** Which role that the parent task of the task list will be assigned to. When using a task list you must add at least one sub-task. The options for a sub-task are the same as the basic options for the parent task: Name, Short Description, Description. Additionally, if you have selected 'Configure assignment type', you must select the assignment type for each sub-task (= which role the sub-task will be assigned to). # App Groups Groups are an important part of how AppControl works. Groups are used to delegate the management of apps from the platform administrator to a group administrator. As the usage of Mendix grows in an organization, it is common that instead of a single central team being responsible for all Mendix development that responsibilities are delegated to separate groups. Groups can only be created by users with the Platform Administrator role. Once a group is created, has a group administrator assigned to it, and has apps assigned to it, its members can then be managed by the group administrator.
Apps Groups contain apps. Apps can be assigned to only a single group. Assigning an app to a group makes it inherit any group policies, group scorecards, group tasks, or group pipelines. Only users with the role Platform Administrator can manage the list of apps in a group.
Group Admins Groups can have 1 or more group administrators. Group administrators can manage the list of group members, and they can manage all resources in AppControl that are assigned to the group (E.g. Group Policies, Group Scorecards, Group Task Libraries, Group Pipelines). Only users with the Platform Administrator role can manage the list of group administrators. Note: When adding a user as a group administrator they automatically get the system role 'Group Administrator'.
Group Members Group members van view the apps that are assigned to the groups that they are member of. Group membership is used only for app visibility in AppControl. When a user is added to a group they are automatically added too each app in the group with the App Member role. Only users with the Group Administrator role and who are assigned as group administrator, or the Platform Administrator, can manage the list of group members for a group.
User Groups As a Group Administrator you can create user groups for your App Group. This enables you to assign specific app roles to groups of users and groups of apps. See the [User Groups](#user-groups) page for more details. Note: When managing user groups for an app group, the apps are limited to apps that are part of the App Group you are managing. However, it is possible to add any user in AppControl to the user group, not just members of the current app group.
# User Groups The user group manager enables you to create groups of apps, and then grant users access to those apps in AppControl. See the [User Roles & Access](/overview/user-roles-and-access) page for more details on access rights in AppControl. After creating a new group you can do the following: * **Add an app.** When you add an app to a group, all group members will automatically be added to that app with the access that you have configured. * **Add a member.** When you add a member to the user group, they will automatically be granted access to all apps in the user group using the access profile that you configure (see below). * **Remove a member.** When you remove a member from the user group, their permissions will be removed from all apps in the user group. Note: If the user has app permissions granted though other user groups or app groups, this permissions will remain unchanged. * **Configure access profile.** For each member of a user group you manage their access profile separately. From the add member pop-up you select what level of access the user group member should have. The following options are available: * App Owner * App Administrator * App Member: this is the default access and cannot be de-selected. * App Operator: this access can further be scoped by selecting the environment types that the user can operate. These are: * All * Production (all production environments) * Production & Acceptance * Acceptance & Test (all non-production environments) Changes to the list of apps or user group members takes immediate effect. The 'save' button on this page only affects the name and description of the user group. # System The pages under the System menu are used to configure how AppControl works at a technical level, and also provides logs and tools for monitoring and troubleshooting the operation of AppControl. # Accounts AppControl can use either local accounts or SSO to authenticate users. The Accounts page is visible to users with the Platform Administrator role and can be used to manage accounts, roles, and SSO settings. For more information about user roles and access to features in AppControl see the following: {% content-ref url="/pages/Fcv2J6C2v9NkskvtjDnc" %} [User Roles & Access](/overview/user-roles-and-access) {% endcontent-ref %}
Accounts The accounts tab provides an overview of all accounts currently configured in the AppControl. Use this overview to manage the roles that each user has. Note the following about user roles: * The default user role is '**NoAccess**'. If you are using SSO you can configure the SSO user provisioning settings to use a different default role. * There basic user role needed to use the complete feature set of AppControl is '**AppViewer**'. This role provides read-only access to all apps that a user has been configured to view. All users (including the Platform Administrator) must have this user role. * A limited access role called '**PolicyViewer**' is also available. Use this role instead of the 'AppViewer role' if you want to limit the functionality of a user to only Policies and Insights.
Authorized Domains Authorized domains is used for calculating user license metrics. When counting whether users are internal or external to your organization, AppControl uses the domains listed here. Add the domains that are internal to your organization so that the user metrics displayed on the AppControl dashboard are accurate.
SSO Depending on the authentication service you are using for AppControl (configured by setting the **MxOM\_Core.AuthenticationService** constant), additional settings will be available here. * **Local.** There are no additional settings available. * **Mendix SSO.** There are no additional settings available. Note: Mendix SSO only works if you have deployed AppControl to the Mendix Cloud. * **SAML.** The standard Mendix SAML module is used. For further information on how to configure the SAML module please refer to the [Mendix SAML documentation](https://docs.mendix.com/appstore/modules/saml/).
# Notifications The notifications page is used to configure how AppControl sends out e-mail notifications. E-mail notifications are send out for various reasons: * To the system administrator when there are problems with the system. * To user when they need to take action (E.g. Tasks have been assigned, problems have been detected with application logs, policies have been violated, etc.). The following settings are available:
System Alerts * **Destination Address:** The e-mail address that all system alerts should be sent to. * **Send alerts to all platform administrators:** If checked, system alerts will be sent to all users with the role 'PlatformAdministrator' in the system.
User E-mails * **Reply to address:** The FROM address that will be used for all e-mails sent to users. * **Display name:** The display name used for all e-mails sent to users.
SMTP Settings * **Username:** The username used to authenticate to the outgoing SMTP server. * **Password:** The password used to authentication to the outgoing SMTP server. * **Timeout:** The timeout to use when trying to send a single e-mail to the SMTP server. * **Digitally sign e-mails:** If checked, all outgoing e-mails will be digitally signed. Additional settings will also become visible (see below). * **Use SSL:** If checked, SSL will be used when connecting to the SMTP server. * **Use TLS:** If checked, TLS will be used when conencted to the SMTP server. * **Send max attempts:** The number of times the system will attempt to deliver an e-mail if it fails to send. * **Server host:** The host name or IP address of the SMTP server. * **Server port:** The port number of the SMTP server.
Digital Signing Settings * **Passphrase:** The password of the private key used to sign e-mails. * **File:** Select the private key to be used for signing e-mails.
Queue The Queue tab shows all e-mails that are either queued to be sent by the system, or that have already been sent. Use this overview to verify whether or not AppControl is sending notifications as expected.
Templates This tab enables you to customize the default template used by AppControl to send e-mails. The template editor has both a visual editor and a code editor (for editing HTML). To edit the HTML of the template directly click on the 3 dots menu, and then click on the 'code editor' icon. The following template variables can be used: * {%Date%} - The date the email was generated. * {%AppName%} - The name of the app (if applicable) that the notification was generated for. * {%EmailSubject%} - The subjet of the notification generated by the system. * {%UserName%} - The name of the recipient (if applicable) of the email. * {%MessageBody%} - The content of the notification generated by the system. * {%LinkUrl%} - The direct link to the item in the system that the notification is about (E.g. release, alert, policy check, etc.).
Apps This tab enables you to turn on and off notifications for each app and environment, and configure who should receive notifications. Platform Administrators can configure notification settings for all environments, and App Administrators can configure notifications for apps that they have access to. Click on an environment to change the following settings:
* **Recipient.** Who should receive the notifications. The possible options are: * **App Administrator (default).** All notifications will be sent to the App Administrator only. * **App Owner.** All notifications will be send to the App Owner only. * **Both.** Notifications will be sent to both the App Administrator and the App Owner. * **Specific Email.** Notifications will be sent to the e-mail address specified. * **Notification Type.** Select which notifications that you want to enable. When disabled, if alerts are generted for that specific type they will not be sent out.
# System Status The system dashboard provides an overview of the current status of AppControl. Use the information on this page to verify that AppControl has been properly configured, and that there are currently any known issues. Note that the information here relates only to the operation of AppControl and not to to operation of the apps managed by AppControl. {% hint style="info" %} When you first login as a user with the Platform Administrator role, you will be re-directed to this page if the configuration of the system is incomplete. After completing the configuration and resolving any errors, click the 'validate configuration' button to re-check your configuration. If it is complete and there are no errors, you will no longer be re-directed to this page. {% endhint %} {% hint style="info" %} If you have the Platform Administrator role, a system status bar will appear at the top of each page. This bar indicates if there are any error messages in the system logs, or if there are any feedback items waiting for you to process. {% endhint %}
Product License This tile displays information about your AppControl product license including the maximum number of apps that you can manage, when your license expires, and whether or not it is activated. When you receive a product license from Blue Storm, use the 'manage license' link to install and activate your license. For instructions on how to install a product license see the [product license](/administration/system/product-license) page of this documentation.
Product Version This tile shows the currently installed version of AppControl and the Mendix runtime version being used. Note: AppControl is only supported on the Mendix runtime version that it is designed for.
Management API This tile shows whether or not the Management API has been enabled or not. For more details see the [Management API](#management-api) page.
BlueStorm Portal This tile shows the current status of the connection between AppControl and the Blue Storm Portal. A connection with the Blue Storm Portal is required to download and activate your product license.
Insights Repository This tile shows the current status of the connection between AppControl and the Insights Repository. The Insights Repository contains the central repository of information about marketplace components, Mendix runtimes, known log solutions, and vulnerabilities. If the connection is not active the information in your local repository will not be up to date.
Hosting Platforms This tile shows all of the hosting platforms that you have configured. If this list is empty, AppControl will not be able to monitor or manage your apps.
Model Repositories This tile shows all of the app repositories that have been detected or configured. If this list is empty, AppControl will not be download or scan your app project files.
App Visibility This tile shows all of the apps that are not currently visible to any users in AppControl (aside from users with the Platform Administrator role). By default apps are not visible to users until you have added them to a group, or configured users as app owners, managers, or members.
System Tasks This tile shows all of background jobs that have been executed as well as those that have failed. AppControl uses queues to execute background jobs such as app scans and policy checks. If background jobs fail it usually means that there was either a network problem, authentication issue, or incorrect access rights to an app project and AppControl was not able to perform a task correctly.
Scheduled Events This tile shows all of the scheduled events required for the correct operation of AppControl and whether or not they are enabled. If a scheduled event is not enabled, AppControl will not operate correctly.
E-mail Settings This tile shows whether or not the e-mail notification settings have been configured correctly. If not, you will not receive any notifications from AppControl.
Model Processing & Policy Checks This tile shows whether there are environments that have models that have eithe failed model processing, or failed policy checking. Model processing and policy checking are essential to the operation of AppControl. If either of these processes fail you will en unable to view policy results or deploy apps (if your pipelines make use of policy checks). Contact Blue Storm if you see failures here.
PDF Service This tile shows the current configuration status of the [PDF service](#pdf-service). The PDF service is a Mendix Cloud hosted service used by AppControl to generate PDFs. If the service is incorrectly configured it is not possible to generate PDFs.
# System Logs & Tools The logs and tools page is used for the technical management of AppControl. The information on this page reflects the operation of AppControl and not the operation of the apps managed by AppControl. {% hint style="danger" %} Do not use any of the action in the 'System Tools' tab unless instructed to do so by Blue Storm support. Incorrect usage of these tools can cause data loss. {% endhint %} {% hint style="info" %} By default old log messages are not deleted. Over time the size of the log table can grow to become very large. To delete old log messages do the following: * Enable the Logging.CleanupDataLogging scheduled event. * Set the constant Logging.LogHistoryDays to the number of days that you want to retain old log messages. {% endhint %}
Logs This tab gives an overview of all logs generated by AppControl. Use these log messages to troubleshoot any unexpected behaviour of the system.
Background Jobs AppControl uses background jobs to perform tasks such as app scans and policy checks. This tab shows the current and historical status of all background jobs executed by AppControl. Use this information if you encounter problems with policies, scorecards, or other information in AppControl that is not updating as expected.
System Task Queue AppControl uses task queues to execute jobs in parallel. Use this tab to view which tasks AppControl is currently executing.
System Tools The tools on this page can be used to manually perform tasks that are usually performed autmatically by AppControl. Only use these tools when instructed to do so by Blue Storm support.
# System Configuration Use the system configuration page to configure how AppControl interacts with your Mendix hosting environments, and to configure which features are available to users. {% hint style="info" %} The following are the hosting platform currently supported by AppControl: * Mendix Cloud * Mendix Cloud Dedicated The following are the app repositories currently supported by AppControl: * Mendix Team Server (SVN) * Mendix Team Server (GIT) {% endhint %} {% hint style="warning" %} If adding multiple hosting platforms, make sure that the credentials you use for each hosting platform do not have access to the same apps. This can cause unpredictable behaviour in the user interface as the app will appear to move between hosting platforms. {% endhint %} {% hint style="warning" %} If your organization uses Bring Your Own IdP and enforces the use of 2FA, you must change the authentication type used by each detected app repository to be 'Personal Access Token' otherwise authentication will fail. {% endhint %}
Hosting Platforms The hosting platforms tab provides an overview of all hosting platforms currently configured in the AppControl. Use this overview to manage the hosting platforms that AppControl should manage. For each hosting platform added, AppControl will poll the platform every 5 minutes using the credentials provided. It will download the list of apps that the provided credentials have access to, and update the list of and current status of the environments for each app.
Repositories The repositories tab provides an overview of all app repositories currently configured in the AppControl. App repositories are detected automatically if you are using the Mendix Cloud. App repositories are used my AppControl to download and scan your Mendix app project files. App repositories are automatically detected each configured Mendix Cloud hosting platform. The only thing you will need to configure yourself is the type of authentication to use: * **Username & Password:** This is the default. The Mendix Platform user and password you configured in the hosting platform will be used to access the repository. * **Personal Access Token:** Select this if your organization uses Bring Your Own IdP and enforces 2FA. PAT will be used by AppControl to access the repository.
Apps The apps tab shows you an overview of all apps that have been detected by AppControl. From this overview you can turn ON and OFF various features. Note: These features need to be enabled first from the 'Feature Settings' tab before turning them ON or OFF has any effect: * **Release Management.** Enable pipeline management and configuration management for this app. * **Policy Management.** Enable policy checking for this app. * **Alert Management.** Enable remote alert management for this app (will create remote webhooks for receiving hosting alerts). * **Log Management.** Enable analysis of access and app logs (Insights). * **Enabled?** Will turn ON or OFF all features for this app. When disbabled the app will no longer appear in AppControl, even if AppControl has access to the app. Note: You can bulk enable or disable apps by selecting them from this list, and using the 'Enable' or 'Disable' button. * **Deleted?** If TRUE, this app was previosuly detected by AppControl but it no longer has access to it. To be able to perform each feature, AppControl needs specific rights to your app hosting platform. (See information about adding a hosting platform on this page) Use the 'verify app' button to check to see if AppControl has sufficient rights to perform all features.
Environments The environment tab shows you an overview of all the environments that have been detected by AppControl, and the current technical status of the environment (If it is running, and if the deployed model has been processed and checked by AppControl). From this overview you can turn ON and OFF various features at an environment level. Note: These features need to be enabled first from the 'Feature Settings' tab before turning them ON or OFF has any effect: * **Release Management.** Enable pipeline management and configuration management for this app. * **Policy Management.** Enable policy checking for this app. * **Alert Management.** Enable remote alert management for this app (will create remote webhooks for receiving hosting alerts). * **Log Management.** Enable analysis of access and app logs (Insights). For each environment the 'Revision Status' is displayed. This shows you whether or not AppControl has scanned and analyzed the revision deployed to the environment. The possible statuses are: * **Not Processed.** A newly deployed revision has been detected for this environment, but it has not yet been procssed. * **Processing Model.** The model for this environment is currrently being processed. * **Model Processed.** The model for this environment has been processed. After processing thee model, information about used components, widgets, Java Libraries, and other technical information is available to the system. * **Checking Revision.** The revision is currently being checked for compliance with your policies. * **Revision Checked.** The revision has been checked for compliance with your policies. Policy results are now available in the Policy Dashboard. * **Queued for Processing.** The model deployed to this environment is queued for processing. * **Queued for Checking.** The revision is currently queued to be checked for compliance with your policies. * **Processing Failed.** The system failed to process your model. You can attempt to process the model again from the 'Revisions' tab in the App page. You can check the logs for dettails as to why the processing failed. * **Check Failed.** The system failed to check the policy compliance of your revision. You can attempt to check the revision again from the 'Revisions' tab in the App page. You can check the logs for dettails as to why the policy check failed. **Note:** If AppControl detects that it has insufficient rights to perform the actions needed for a given feature, it will automatically disable the feature for the environment that it doesn't have access to. This is the reason you may see that certain environments have features disabled.
Feature Settings This tab enables you to turn ON and OFF the various features in AppControl. Depending on the governance needs of your organization you may wish to turn certain features ON or OFF. Additionally, it is possible to customize ceratin features so that they meet your governance needs. * **Release Management.** Use this to enable the use of pipelines and releases. * **Group admins can manage pipelines.** When enabled, users with the Group Administrator role that are assigned as the admin of an App Group can create group and app pipelines for apps in their group. * **App admins can manage pipelines.** When enabled, users with the App Administrator role can create app pipelines for apps where they are asigned the App Administrator role. * **Policy Management.** Use this to enable the use of policy and automated policy checking. When turned on AppControl will automatically check each deployed revision for compliance with your policies. When turned off policies will not be checked. * **Alert Management.** Use this to enable remote alerting (receiving alerts from your hosting platform). When you turn it on remote webhooks will be configured on your hosting platform to send alerts to AppControl. When you turn it off, the webhooks will be disabled. * **Log Management.** Use this to enable the automated analysis of access logs and app logs. When you turn it on, a scheduled event will download logs for each app environment and analyze them daily. When you turn it off, log analysis will no longer be performed. * **Management API.** Use this to enable the AppControl [management API](/administration/system/management-api). This enables you to integrate AppControl with your own management systems, providing additional automation possibilities. * **PDF Service.** Use this to configure the PDF service for downloading PDF reports. Before opening the configuration page you must add the /docgen/ request handler to your AppControl environments in the Mendix cloud (). After doing this click on 'configure PDF service' and fill in the following details: * **Deployment type.** Choose Mendix Public Cloud or Mendix Cloud Dedicated depending on where you have deployed AppControl. * **Application URL.** The URL to your AppControl instance. * **App ID.** The App ID of your AppControl app in the Mendix Cloud. * **Personal Access Token.** The one-time PAT that will be used to configure the PDF service.
# Hosting Platform A hosting platform is a specific operating environment for your Mendix apps. Add each of your hosting platforms to AppControl to be able to manage them. Many customers only have 1 hosting platform (E.g. Mendix Cloud), however some have both public and private clouds (E.g. Mendix Cloud and Mendix for Kubernetes). For more information on each type of supported hosting platform and which AppControl features are supported per hosting platform, see the [Add hosting platforms](/overview/initial-set-up/add-hosting-platforms) page. Depending on the type of hosting platform you are adding, the following information must be provided:
Mendix Cloud This is the default and most widely used Mendix hosting platform. When adding Mendix Cloud platforms the following information must be provided: * **Mendix Platform User:** The user that AppControl should use to access apps in the Mendix platform. For information on how to create this user see [AppControl User](/overview/initial-set-up/appcontrol-user). * **Mendix Platform User ID:** The user ID of the user that AppControl should use to access apps in the Mendix platform. For information on how to find this information see [AppControl User](/overview/initial-set-up/appcontrol-user). * **API Key:** The API key for the Mendix Platform user you provided. * **Personal Access Token (PAT):** The PAT for the Mendix Platform user you provided.
Mendix Cloud Dedicated This is the version of the Mendix Cloud that provides a segregated part of the Mendix Cloud that is dedicated to your organization. When adding Mendix Cloud Dedicated platforms the following information must be provided: * **Mendix Platform User:** The user that AppControl should use to access apps in the Mendix platform. For information on how to create this user see [AppControl User](/overview/initial-set-up/appcontrol-user). * **Mendix Platform User ID:** The user ID of the user that AppControl should use to access apps in the Mendix platform. For information on how to find this information see [AppControl User](/overview/initial-set-up/appcontrol-user). * **API Key:** The API key for the Mendix Platform user you provided. * **Personal Access Token (PAT):** The PAT for the Mendix Platform user you provided.
Mendix for Kubernetes (Connected) This is used for hosting Mendix in your private cloud environment. When adding Mendix for Kubernetes (Connected) platforms the following information must be provided: * **Mendix Platform User:** The user that AppControl should use to access apps in the Mendix platform. For information on how to create this user see [AppControl User](/overview/initial-set-up/appcontrol-user). * **Mendix Platform User ID:** The user ID of the user that AppControl should use to access apps in the Mendix platform. For information on how to find this information see [AppControl User](/overview/initial-set-up/appcontrol-user). * **API Key:** The API key for the Mendix Platform user you provided. * **Personal Access Token (PAT):** The PAT for the Mendix Platform user you provided.
# Repository The Repository manager is used to view the contents of the local Insights repository. The AppControl Insights repository provides additional information about used marketplace components, Java libraries, log solutions, and vulnerabilities. The local repository is synchronized every 24 hours with the central repository managed by Blue Storm. This ensures that you always have the latest information about the software components used by your apps. {% hint style="info" %} When apps are scanned by AppControl information about modules, widgets, Java libraries, and Mendix versions is stored in the local repository. If your apps use components that are not known in the central repository, information about these components is shared anonymously with the central AppControl Insights repository once every 24 hours. Blue Storm then reviews and verifies the information, and if necessary, adds these components to the central repository. {% endhint %}
Update Log The update log shows information about the synchronization of your local repository with the central AppControl repository. Errors in the synchronization process will prevent new component information from being downloaded, and this can cause policy states, scorecards, and reports to be incomplete.
Mendix Versions This tab shows all the known Mendix versions stored in your repository.
Modules This tab shows all the modules stored in your repository. Note: This includes public marketplace modules as well as private marketplace modules.
Widgets This tab shows all the widgets stored in your repository. Note: This includes public marketplace widgets, private marketplace widgets, and custom widgets.
Java Libraries This tab shows all the Java libraries stored in your repository. Note: This includes Java libraries used by Marketplace content as well as custom Java libraries in use by your apps.
Vulnerabilities This tab shows all the vulnerability information stored in your repository. Vulnerabilities have a vulnerability ID (an ID unique to AppControl) and in some cases a CVE ID. Vulnerability information is collected by Blue Storm from multiple sources and attached to those components with known vulnerabilities.
Solutions This tab shows all the log solutions stored in your repository. [Log solutions](/administration/system/repository/log-solution) are how-to articles created either by Blue Storm or yourself, and are automatically attached to log messages that have been scanned by AppControl and identified as having a known solution.
--- [Next Page](/llms-full.txt/1)