## Desired State Configuration

App Orchestration uses a Desired State model of configuration. This means that the administrator, or API caller, is not actually configuring the underlying components directly. Rather, they are specifying the state that they want the underlying components to eventually reach. The App Orchestration system ensures that the desired state is met by performing actions across multiple products, sites, domains, and datacenters, in the correct order and with the correct interdependencies.

App Orchestration allows administrators to change configuration even before the desired state is achieved. When this happens, the system will automatically recalculate the "shortest path" to the new desired state. It will supersede any incomplete workflows and instead schedule new workflows where necessary based on the new desired state.

There are several implications for adminsitrators and API callers:

1. Any changes made to the configuration are immediate and (as long as the change is logically valid) will complete successfully, long before the actual state of the entire deployment reaches the desired state.
2. Though it is possible to find and monifor the workflows created by administrator-initiated tasks, in general, it is currently not possible to reliable detect when an administrative action is "done" because those workflows may be superseded.
3. The system will intentionally allow configuration changes that may not be reachable without adding resources. For example, you may create delivery groups even when there are no delivery sites available, or you may specify a desired capacity which is larger than the number of session machines actually on-hand. In these situations, a notification is raised on the dashboard in the UI, and the API caller can obtain and react to the same list of notification by calling the GET DashboardData/Notifications API. There are usually two ways to react to this: either add resources, or change the desired state to something achievable with the existing resources.
4. If any workflows are required for "cleanup" when an object is deleted, it must undergo a Two-Phase Delete process.