Data deployed from sandboxes
This feature is in beta, and is available to participating organizations.
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.
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.
# | Entity |
|---|---|
1 | Custom field and field context |
2 | Field Configuration |
3 | Field Configuration Scheme |
4 | Filter |
5 | Work type |
6 | Status |
7 | Work type scheme |
8 | Work type screen scheme |
9 | Notification Scheme |
10 | Permission Scheme |
11 | Project role |
12 | Board |
13 | Screen |
14 | Screen scheme |
15 | Workflow |
16 | Workflow Scheme |
Jira Service Management
# | Entity |
|---|---|
1 | Forms |
2 | Portal groups |
3 | Request types |
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 |
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 | Only the follow scheme associations of a project will be deployed. Any other changes to project settings will not be deployed.
| Manually change other project attributes directly in the destination |
Project | Projects created on a sandbox | Before you start your deployment, create an empty project on production. |
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?