The PUSH process facilitates the smooth propagation of changes from the Quality Assurance (QA) environment to the Production (PROD) environment. This process involves selecting the project and objects to be propagated through a few-step procedure. During the first and second steps of the PUSH process, users are required to choose the project and objects slated for propagation. This marks a significant improvement from the previous version, as users are no longer obligated to be aware of all dependent objects. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. Dependency resolution relies on other dependencies, with the following exceptions: UserRole: User role objects are not automatically marked as dependencies but can be selected in Step 2(choose object). UserRole Users: Users within user role objects are not synchronized at all. Cluster: Clusters are synchronized as a single object. This implies that all newly added or deleted columns will be synchronized, ensuring the cluster is identical after the synchronization process. Additionally, all dependent attributes and facts will be propagated to the target project. An attribute/fact can be deleted if the corresponding column was removed in the source project. Cluster and Joins: Clusters are recursively synchronized with all joined clusters. Flow: Currently, flows are not dependent on clusters or other objects and must be selected in Step 2(choose object). Flow Credentials: Credentials are created in the target project but without content and must be set again in the target project. WebDAV Files: All dependent files from WebDAV, including input files for inflow and images for dashboards, are ignored and must be synchronized manually. Folder: All objects within a folder are marked as dependent for synchronization. Market Packages: Currently, packages cannot be synchronized. This capability will be available at the beginning of February. Currently, conflicts can only be resolved by rewriting the target object. This entails rewriting both the title and content. Or the second option that the input object selected in step 2 will be ignored. This step shows only objects with conflicts, not all that will be added. To show and check all changes in the target project go to next step. In this step, users can check for all possible objects and data issues in the target project after the push. If everything is ok it will show: There may also be issues present in the target project before the push. Therefore, please carefully inspect the errors. If you are unsure, you can also review current issues in inModeler within the target project: 3. The capability to display differences between objects during conflict resolution. TBD 4. Mark inflows as dependent objects for clusters. Currently, inflow is not dependent on the cluster, and if the cluster is synchronized, the flow is not propagated to the target. TBD

The PUSH process facilitates the smooth propagation of changes from the Quality Assurance (QA) environment to the Production (PROD) environment. This process involves selecting the project and objects to be propagated through a few-step procedure. During the first and second steps of the PUSH process, users are required to choose the project and objects slated for propagation. This marks a significant improvement from the previous version, as users are no longer obligated to be aware of all dependent objects. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. Dependency resolution relies on other dependencies, with the following exceptions: UserRole: User role objects are not automatically marked as dependencies but can be selected in Step 2(choose object). UserRole Users: Users within user role objects are not synchronized at all. Cluster: Clusters are synchronized as a single object. This implies that all newly added or deleted columns will be synchronized, ensuring the cluster is identical after the synchronization process. Additionally, all dependent attributes and facts will be propagated to the target project. An attribute/fact can be deleted if the corresponding column was removed in the source project. Cluster and Joins: Clusters are recursively synchronized with all joined clusters. Flow: Currently, flows are not dependent on clusters or other objects and must be selected in Step 2(choose object). Flow Credentials: Credentials are created in the target project but without content and must be set again in the target project. WebDAV Files: All dependent files from WebDAV, including input files for inflow and images for dashboards, are ignored and must be synchronized manually. Folder: All objects within a folder are marked as dependent for synchronization. Market Packages: Currently, packages cannot be synchronized. This capability will be available at the beginning of February. Currently, conflicts can only be resolved by rewriting the target object. This entails rewriting both the title and content. Or the second option that the input object selected in step 2 will be ignored. This step shows only objects with conflicts, not all that will be added. To show and check all changes in the target project go to next step. In this step, users can check for all possible objects and data issues in the target project after the push. If everything is ok it will show: There may also be issues present in the target project before the push. Therefore, please carefully inspect the errors. If you are unsure, you can also review current issues in inModeler within the target project: 3. The capability to display differences between objects during conflict resolution. TBD 4. Mark inflows as dependent objects for clusters. Currently, inflow is not dependent on the cluster, and if the cluster is synchronized, the flow is not propagated to the target. TBD

The PUSH process facilitates the smooth propagation of changes from the Quality Assurance (QA) environment to the Production (PROD) environment. This process involves selecting the project and objects to be propagated through a few-step procedure. During the first and second steps of the PUSH process, users are required to choose the project and objects slated for propagation. This marks a significant improvement from the previous version, as users are no longer obligated to be aware of all dependent objects. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. The system leverages the Object Dependency Model (ODM) graph, illustrated in Image 1, to identify and manage dependencies. This eliminates the need for users to manually specify all dependencies. Dependency resolution relies on other dependencies, with the following exceptions: UserRole: User role objects are not automatically marked as dependencies but can be selected in Step 2(choose object). UserRole Users: Users within user role objects are not synchronized at all. Cluster: Clusters are synchronized as a single object. This implies that all newly added or deleted columns will be synchronized, ensuring the cluster is identical after the synchronization process. Additionally, all dependent attributes and facts will be propagated to the target project. An attribute/fact can be deleted if the corresponding column was removed in the source project. Cluster and Joins: Clusters are recursively synchronized with all joined clusters. Flow: Currently, flows are not dependent on clusters or other objects and must be selected in Step 2(choose object). Flow Credentials: Credentials are created in the target project but without content and must be set again in the target project. WebDAV Files: All dependent files from WebDAV, including input files for inflow and images for dashboards, are ignored and must be synchronized manually. Folder: All objects within a folder are marked as dependent for synchronization. Market Packages: Currently, packages cannot be synchronized. This capability will be available at the beginning of February. Currently, conflicts can only be resolved by rewriting the target object. This entails rewriting both the title and content. Or the second option that the input object selected in step 2 will be ignored. This step shows only objects with conflicts, not all that will be added. To show and check all changes in the target project go to next step. In this step, users can check for all possible objects and data issues in the target project after the push. If everything is ok it will show: There may also be issues present in the target project before the push. Therefore, please carefully inspect the errors. If you are unsure, you can also review current issues in inModeler within the target project: 3. The capability to display differences between objects during conflict resolution. TBD 4. Mark inflows as dependent objects for clusters. Currently, inflow is not dependent on the cluster, and if the cluster is synchronized, the flow is not propagated to the target. TBD