Data deployed from sandboxes
This feature is in beta and is available on Premium and Enterprise plans.
When you deploy data from sandboxes, only the supported entities are deployed. Refer to this page to understand:
the list of supported entities
the scenarios where deployment of supported entities is likely to fail
Supported entities
Only entities included in the below tables will be deployed from your sandbox.
Media data is not supported. This means media associated with supported entities (for example, icons of request types) won’t get deployed.
Jira
Only entities of company-managed project are supported. Entities of team-managed projects are not supported.
To deploy a supported scheme’s association with a project, you’ll need to select the
Projectentity. Otherwise, the scheme associated with the project on the destination will be retained.We currently don’t support deploying changes to an entity that once existed on the destination but has been deleted manually from the production.
Entity |
|---|
Automations |
Custom field and field context |
Field Configuration |
Field Configuration Scheme |
Field scheme |
Filter |
Work type |
Status |
Work type scheme |
Work type screen scheme |
Notification Scheme |
Permission Scheme |
Project role |
Board |
Screen |
Screen scheme |
Workflow |
Workflow Scheme |
Jira Service Management
In addition to the entities below, all entities supported by Jira are also supported by Jira Service Management.
Entity |
|---|
Assets
|
Forms |
Portal groups |
Request types |
Change management settings:
|
Incident management settings:
|
Unsupported operations
This following types of changes to supported entities will not be included in your deployment.
Entity type | Unsupported operation | Workaround |
|---|---|---|
Custom field | Removal of a custom field option | Manually remove the custom field option from the destination |
Custom field | Locked/ARJ/app managed custom fields | Make changes to these custom fields fields directly on production |
Custom field | Removal of a custom field config scheme | Manually remove the custom field config scheme from the destination |
Custom field | Removal of a custom field default value | Manually remove the custom field default value from the destination |
Custom field | Change to the type of a custom field | Manually change the custom field type in the destination |
Custom field | Association of a project with a global custom field context Removal of a project association with a custom filed config scheme or moving of any project association from one custom field config scheme to another. | Manually associate projects with global custom field contexts in the destination |
Custom field | Modifications to multi-user picker to filter users | You can manually modify the custom field’s user filter post deployment |
Workflow | Removal of work item status from an existing workflow | Manually remove redundant work item statuses from the workflow in the destination |
Workflow scheme | The change of a workflow association with any work type where the workflow has missing statuses | Manually change the workflow association with the work type in the destination |
Project | Modifications to the project name and project key of existing projects will not be deployed. | You’ll need to manually change these attributes in the destination. |
Automations | Any changes to connections in automations will not be deployed. | You’ll need to manually reconfigure connections in automations in the destination. |
Work type scheme | Removal of an work type from a scheme if issues are linked to that issue type | Manually remove work types from a scheme in the destination |
Work type | Changes to a work type icon | Manually make changes to the work type icon on the destination |
Work type | Hierarchy changes to an existing work type | Manually make changes related to work type hierarchy in the destination |
Filter | Changes to filter permissions If you create a new filter and select it in your deployment, the permission of that filter will be set to private in the destination. | Manually change the permissions of the filter in the destination |
Was this helpful?