View this page in the latest version of Appian. Deployment Guidelines Share Share via LinkedIn Reddit Email Copy Link Print On This Page This page applies to developers. It describes guidelines for deploying objects in support of Process HQ. Overview Process HQ fits easily into your DevOps lifecycle, letting your organization deploy apps between environments in the way that works best for you. The sections of this page provide guidance on the design objects you can deploy to support Process HQ. Note: You must have Administrator permissions for an application to deploy the application. Business processes Developers can deploy business processes they've designed in one environment for Process HQ access in another environment. Keep in mind the following considerations: You must have Data Steward permissions for all of the record types used in a process to deploy a business process object. You must add a business process object to an application before you can deploy the object to another environment. Business process objects can then be added to packages the same way you would add other design objects. Process artifacts, such as views and KPIs, are not part of the business process object and are not deployable. By default, once a business user edits a process in the target environment, that version of the object is treated as the authoritative version of the object, so deployment prevents updates to that object from the source environment. You can override this default behavior for an individual object using the forceOverrideProtection parameters in an import customization file. Learn more. Business process objects cannot be referenced by process models, so they cannot be included in a post-deployment process. Record types Once a developer prepares process data and report data in a development environment, it's time to deploy the relevant record types to the production environment, so your organization can access the production data in Process HQ. Keep in mind the following considerations: Make sure your package contains any record types you need for reporting or analyzing process data. For each process, ensure you have the case record type, event history, and any related record types. If appropriate for your organization's workflow, make sure the record types have been configured to display as datasets in the Data Catalog. If you skip this check, data governors in the source environment can also update this configuration. If you're deploying a records-backed record type, ensure the service account has the necessary security configured. During direct deployment, all evaluations of a deployed record type will be attributed to the service account that deployed the package. Reports and dashboards Developers can deploy reports and dashboards they've designed in one environment for Process HQ access in another environment, so that business users can view them in sites or use them as templates to create their own custom reports. Keep in mind the following considerations: You must be part of the Data Fabric Report Creators system group to deploy reports and dashboards. You must add a report or dashboard object to an application before you can deploy the object to another environment. Report and dashboard objects can then be added to packages the same way you would add other design objects. You cannot deploy the following: A report object that contains a dataset filter or quick filter set to a user, group, or document. A dashboard object that contains a process KPI. The presence of these conditions will trigger an error when the object is inspected as part of either direct deployment or manual export. By default, once a business user edits a report or dashboard in the target environment, that version of the object is treated as the authoritative version of the object, so deployment prevents updates to that object from the source environment. You can override this default behavior for an individual object using the forceOverrideProtection parameters in an import customization file. Learn more. Report and dashboard objects cannot be referenced by process models, so they cannot be included in a post-deployment process. Feedback Was this page helpful? SHARE FEEDBACK Loading...