Abstract: Versions of an application are managed by receiving a request for a version of an application, retrieving, responsive to the received request, a version of a master application component based at least in part on version data that associates a version of the master application component with the version of the application, retrieving a relationship operable to relate the version of the master application component with a corresponding version of a first component on which the master application component depends for a function of the application, retrieving the corresponding version of the first component, responsive to the retrieving of the relationship, assembling the version of the application based at least in part on the retrieved version of the master component, the retrieved relationship, and the retrieved first component, and providing for an execution of the assembled version of the application.

Abstract: Versions of an application are managed by receiving a request for a version of an application, retrieving, responsive to the received request, a version of a master application component based at least in part on version data that associates a version of the master application component with the version of the application, retrieving a relationship operable to relate the version of the master application component with a corresponding version of a first component on which the master application component depends for a function of the application, retrieving the corresponding version of the first component, responsive to the retrieving of the relationship, assembling the version of the application based at least in part on the retrieved version of the master component, the retrieved relationship, and the retrieved first component, and providing for an execution of the assembled version of the application.

Abstract: Deployment of a software unit into a software application layer stack using deployment parameters including an ordering behavior parameter and a reference parameter. The deployment of the software unit may be in response to receipt of a software package for installation of the software unit. Installation of the software unit may be provided according to a hierarchical rule structure that includes determining whether the software unit comprises an upgrade or a patch to an existing software unit in the layer stack. If not an upgrade or a patch, an ordering behavior parameter may indicate a relative position to install the software unit in relation to a software unit designated by the reference parameter. If the deployment parameters are not valid, installation of the software unit may be provided according to a default rule.

Abstract: Versions of an application are managed by receiving a request for a version of an application, retrieving, responsive to the received request, a version of a master application component based at least in part on version data that associates a version of the master application component with the version of the application, retrieving a relationship operable to relate the version of the master application component with a corresponding version of a first component on which the master application component depends for a function of the application, retrieving the corresponding version of the first component, responsive to the retrieving of the relationship, assembling the version of the application based at least in part on the retrieved version of the master component, the retrieved relationship, and the retrieved first component, and providing for an execution of the assembled version of the application.

Abstract: Systems and methods for generating an application store metadata corresponding to a plurality of sub-applications, combining model-driven application and canvas-type applications. Lifecycle components of the plurality of sub-applications are coupled to each other using one or more data relationships defined by an embedding model and the stored metadata. The metadata points to a library associated with the plurality of sub-applications, and wherein the library comprises a newest version of one or more of the lifecycle components. The compiled plurality of sub-applications can then be run.

Abstract: Versions of an application are managed by receiving a request for a version of an application, retrieving, responsive to the received request, a version of a master application component based at least in part on version data that associates a version of the master application component with the version of the application, retrieving a relationship operable to relate the version of the master application component with a corresponding version of a first component on which the master application component depends for a function of the application, retrieving the corresponding version of the first component, responsive to the retrieving of the relationship, assembling the version of the application based at least in part on the retrieved version of the master component, the retrieved relationship, and the retrieved first component, and providing for an execution of the assembled version of the application.

Abstract: Deployment of a software unit into a software application layer stack using deployment parameters including an ordering behavior parameter and a reference parameter. The deployment of the software unit may be in response to receipt of a software package for installation of the software unit. Installation of the software unit may be provided according to a hierarchical rule structure that includes determining whether the software unit comprises an upgrade or a patch to an existing software unit in the layer stack. If not an upgrade or a patch, an ordering behavior parameter may indicate a relative position to install the software unit in relation to a software unit designated by the reference parameter. If the deployment parameters are not valid, installation of the software unit may be provided according to a default rule.

Abstract: A user interaction is detected, selecting a unit with a user input mechanism. A unit hierarchy path that is used to categorize units, is accessed and a node in the unit hierarchy path, corresponding to the selected unit, is identified. A set of ancestor nodes in the unit hierarchy path is also identified, and a user interface breadcrumb control is generated based upon the selected unit and the identified ancestor nodes. A display system is controlled to render a display page for the selected unit, along with the breadcrumb control.

Abstract: A user interaction is detected, selecting a unit with a user input mechanism. A unit hierarchy path that is used to categorize units, is accessed and a node in the unit hierarchy path, corresponding to the selected unit, is identified. A set of ancestor nodes in the unit hierarchy path is also identified, and a user interface breadcrumb control is generated based upon the selected unit and the identified ancestor nodes. A display system is controlled to render a display page for the selected unit, along with the breadcrumb control.

Abstract: A user interaction is detected, selecting a unit with a user input mechanism. A unit hierarchy path that is used to categorize units, is accessed and a node in the unit hierarchy path, corresponding to the selected unit, is identified. A set of ancestor nodes in the unit hierarchy path is also identified, and a user interface breadcrumb control is generated based upon the selected unit and the identified ancestor nodes. A display system is controlled to render a display page for the selected unit, along with the breadcrumb control.

Abstract: A computing system comprises, in one example, a display system configured to generate user interface displays and a property surfacing system configured to detect a request to access properties corresponding to a selected unit and to access a unit-property association store that stores one or more association entities. Each association entity associates a property entity with the selected unit. The property surfacing system obtains the properties based on the associated property entity. The computing system comprises a display system controller configured to control the display system to generate a user interface property display with a representation of the properties.

Abstract: A user interaction is detected, selecting a unit with a user input mechanism. A unit hierarchy path that is used to categorize units, is accessed and a node in the unit hierarchy path, corresponding to the selected unit, is identified. A set of ancestor nodes in the unit hierarchy path is also identified, and a user interface breadcrumb control is generated based upon the selected unit and the identified ancestor nodes. A display system is controlled to render a display page for the selected unit, along with the breadcrumb control.

Abstract: A computing system comprises, in one example, a display system configured to generate user interface displays and a property surfacing system configured to detect a request to access properties corresponding to a selected unit and to access a unit-property association store that stores one or more association entities. Each association entity associates a property entity with the selected unit. The property surfacing system obtains the properties based on the associated property entity. The computing system comprises a display system controller configured to control the display system to generate a user interface property display with a representation of the properties.

Abstract: Techniques for an inherited entity storage model are described that can be employed to implement inherited entity management for a CRM system. In at least some embodiments, input can be obtained to create a custom entity that is based at least in part upon a parent entity. The custom entity is created to inherit the parent entity according to an inheritance relationship established between the entities. To do so, the custom entity is created from the parent entity in a common table with the parent entity using some common fields and defining custom fields as appropriate. Data for the entities is then stored via the common table. This approach can reduce storage requirements, enable unified searching, and speed up data operations. Further, back-end business logic associated with parent entity in the CRM system can be automatically applied to the custom entity based upon the inheritance relationship established between the entities.

Abstract: Concepts and technologies are described herein for managing recurring appointments without losing historical data associated with the recurring appointments. In accordance with the concepts and technologies disclosed herein, a recurring appointment definition can be modified without deleting the recurring appointment definition and/or losing exceptions, notes, and/or other data associated with the recurring appointment definition. Additionally, the concepts and technologies disclosed herein allow the modification of an existing recurring appointment definition without creating a new recurring appointment definition. Thus, synchronization between rules-based calendaring applications and expansion-based calendaring applications can be accomplished without creating multiple instances of related recurring appointments created due to modifications of the recurring appointment definition.

Abstract: Not-started CRM dialogs are described to facilitate dialog management in a cooperative manner between a CRM system and a client. A workflow defining a set of actions to complete for a business process can trigger a dialog in a “not-started” state and assign the dialog to a particular user. Pending completion of the dialog, the workflow can be paused or continue in the background to a designated stopping point. The dialog that is assigned can appear in a list of scheduled/pending tasks for the particular user and can include a link or other functionality to resume the dialog. Selection of the dialog from the task list can cause the dialog to resume to an “in-progress” state and the status of the dialog can be updated. Thereafter, the workflow can detect completion of the dialog and continue with further actions to complete the business process.

Abstract: Techniques for an inherited entity storage model are described that can be employed to implement inherited entity management for a CRM system. In at least some embodiments, input can be obtained to create a custom entity that is based at least in part upon a parent entity. The custom entity is created to inherit the parent entity according to an inheritance relationship established between the entities. To do so, the custom entity is created from the parent entity in a common table with the parent entity using some common fields and defining custom fields as appropriate. Data for the entities is then stored via the common table. This approach can reduce storage requirements, enable unified searching, and speed up data operations. Further, back-end business logic associated with parent entity in the CRM system can be automatically applied to the custom entity based upon the inheritance relationship established between the entities.

Abstract: Techniques for a dialog page interaction model are described to implement dialog management for a customer relationship management (CRM) system. A workflow defining a set of actions to complete for a business process record can trigger a dialog that includes pages having a set of interactive activities. In a metadata generation mode, the CRM system can construct the page using state information that is stored as client data in one or more databases. The CRM system can also create a bookmark for the workflow in connection with the page that can be employed to resume the workflow. In a response delivery mode, the CRM system can resume the workflow to the bookmark position. To do so, the CRM system can employ the bookmark and stored state data to set the workflow to conditions and values defined by the bookmark.

Abstract: Concepts and technologies are described herein for managing recurring appointments without losing historical data associated with the recurring appointments. In accordance with the concepts and technologies disclosed herein, a recurring appointment definition can be modified without deleting the recurring appointment definition and/or losing exceptions, notes, and/or other data associated with the recurring appointment definition. Additionally, the concepts and technologies disclosed herein allow the modification of an existing recurring appointment definition without creating a new recurring appointment definition. Thus, synchronization between rules-based calendaring applications and expansion-based calendaring applications can be accomplished without creating multiple instances of related recurring appointments created due to modifications of the recurring appointment definition.