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 supported schemes associated with a project, you’ll need to select the
Projectentity. Otherwise, schemes 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 |
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 issue status from an existing workflow | Manually remove redundant issue statuses from the workflow in the destination |
Workflow scheme | The change of a workflow association with any issue type where the workflow has missing statuses | Manually change the workflow association with the issue 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 issue type from a scheme if issues are linked to that issue type | Manually remove issue types from a scheme in the destination |
Worktype | Hierarchy changes to an existing issue type | Manually make changes related to issue 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?