Restore Status Code

Category: Failed to create work items while restoring it

Reason:

1. Revyz internal issue: Failure could be due to one of the following reasons:

   1. Missing Required Fields:
      This occurs when older work items lack data for fields that were recently marked as mandatory (via workflow transitions or configuration updates). These items will fail validation during creation as the work items have no values against the mandatory fields.

   2. Atlassian API failure:
      Failures caused by API rate limits, structural constraints, or temporary transient errors.

2. Resolution:

1. Missing Required Fields: Temporarily change the configuration on the destination site to remove the mandatory field requirement and trigger a new restore.

2. Atlassian API failure: Reach out to Revyz support.

Category: Work item has been created successfully, however, failed to update a value for a certain field.

Reason: Field values for work items may fail to set due to:

• Invalid user: The specified user (such as for the field reporter or any other user field) is deactivated, suspended, or missing from the site.

• Atlassian API errors: Failures stemming from rate limits, structural constraints, or transient network issues.

Resolution:
Following actions are recommended based on the reasons of failure:

1. Invalid: Ensure all users are present and active on the site and trigger another restore.

2. Atlassian API failure: Reach out to Revyz support.

Category: Failed to create sub-task

Reason: Failed to create sub-task independently.

For example, the user selected a sub-task work item to restore, but its parent work item is
missing. In such cases, the sub-task cannot be created independent.

Resolution: Select both the parent work item and the sub-task work item to restore.

Category: Restoring the work-items failed to update the status.

Reason: Failed to Restore Work Item Status

Revyz cannot restore work item status if validations or post-functions are required during work item transition. Workflow status restrictions may require user intervention during work item transition, depending on the configuration.

Resolution: User should follow these steps:

• Navigate to Revyz Jobs → Restore jobs

• Select the restore job ID

• Select the “Post actions“ tab

  • Download the JQL file, which provides a filter to bulk edit and transition work items to their statuses.

Category: Create Issue

Reason: Failure setting intended status of restored issue either due to workflow restrictions or Jira API limitations

Resolution: Check 'Post actions' in job details to fix it

Category: While restoring a work item failed to add a comment.

Reason: Failures from Atlassian API rate limits, structural constraints, or temporary errors can cause comment creation to fail.

Resolution: Customer is advised to check the restore logs. If they can fix an Atlassian error, resolve it and retry the restore. Otherwise, contact Revyz support.

Category: While restoring a work item, failed to add attachment (s).

Reason: Restoring an attachment can fail for these reasons:

• Attachment size exceeds the allowed limit

• Attachment creation can fail due to Atlassian API rate limits, structural constraints, or temporary errors.

Resolution: We recommend following actions based on the reasons of failure:

Attachment size exceeds limit: Increase the attachment size in the site global settings and retry
work item restore.

Atlassian API failure: Reach out to Revyz support.

Category: Failed to add worklogs while restoring a work item

Reason: Worklogs creation can fail due to Atlassian API rate limits, structural constraints, temporary errors or worklogs limit

Resolution: Recommended to contact Revyz support.

Category: Failed to add original work item backed up data as an JSON attachment.

Reason: Revyz adds original backup work item as an attachment to restored issue, so that user can have original copy with them. It can be used for:

• Work item history

• Reconciling missing field values

Reason for failure;

• Atlassian API failure

• Revyz internal issue

Resolution: Recommended to contact Revyz support.

Category: Failed to add original work item backed up data in the form of CSV as an attachment

Reason: Failed to add original work item backup data as CSV attachment

Revyz attaches the original backed-up work item to the restored issue, ensuring users always have access to the original copy.

It can be used for following purpose:

1. Work item history

2. Reconcile missing field values

Reason of failure:

1. Atlassian API failure

2. Revyz internal issue

Resolution: Recommended to contact Revyz support.

Category: Issue_worklog_partial

Reason: Failure restoring one of the worklogs.

Resolution: Check logs. Collect information about cause if available and share it with Revyz.

Category: Failed to add Work item links

Reason: Revyz might fail to link work items due to one of the following scenarios:

• Linked work item is not present or might’ve been deleted.

• Linked work item was not selected for restore and is not present on the site.

• Atlassian API rate limits, structural constraints or temporary errors

Resolution: We recommend following actions based on the reasons of failure:

• Missing linked work items: Select the linked work items as well for restore in the same restore job.

• Atlassian API failure: Reach out to Revyz support.

Category: Failed to add a comment to the restored work item on behalf of the original author.

Reason: If the user who added the comment is absent, deactivated, suspended, or deleted, impersonating them to add a work item comment in the restored work item will fail.

Resolution: No action required.

Category: Issue_Comments_Connect_App_User

Reason: The issue comment was restored using the Connect app user as an error occurred while attempting to restore.

Resolution: The comment with the original comment owner.

Category: Issue_worklog_deactivated_user

Reason: Issue worklog restored with connect app user as deactivated user.

Resolution: Check logs. Collect information about cause if available and share it with Revyz.

Category: Issue_worklog_connect_app_user

Reason: The issue worklog was restored using the Connect app user as an error occurred while attempting to restore.

Resolution: The worklog with the original comment owner.

Category: Failed to upload the original work item history as a CSV attachment to the restored work item.

Reason: Atlassian API rate limits, structural constraints or temporary errors

Resolution: Contact Revyz support

Category: Failed to upload the original work item worklogs as a CSV attachment to the restored work item

Reason: Atlassian API rate limits, structural constraints, or temporary errors

Resolution: Contact Revyz support

Category: Failed to update a work item

Reason: When updating a work item, the API fails. It could fail due to one of the following reasons:

• A field custom might be mandatory as per the latest configurations.

• Atlassian API rate limits, structural constraints or temporary errors

Resolution: Contact Revyz support.

Category: Failed to update a work item

Reason: When updating a work item, the API fails. It could fail due to one of the following reasons:

• A field custom might be mandatory as per the latest configurations.

• Atlassian API rate limits, structural constraints or temporary errors

Resolution: Contact Revyz support

Category: Failed to add Work item links

Reason:

When restoring a work item, the associated work items are also linked. However, the associated work items may fail to be linked to the restored work item, if:

• Linked work item is not present or might've been deleted.

• Linked work item was not selected for restore and is not present on the site.

• Atlassian API rate limits, structural constraints or temporary errors

Resolution:

Following actions are recommended on the basis of reasons of failure:

• Missing linked work items: Select the linked work items as well for restore in the same restore job.

• Atlassian API failure: Reach out to Revyz support.

Category: Workflows

Reason: Failed to restore the workflow contains validators, post-functions can be skipped based on various conditions

Resolution: Contact Revyz support.

Category: Workflows

Reason: Failed to restore sub-configurations of the workflow

Resolution: Check restore job logs from job details.

Category:

Failed to create workflow rules (conditions, validators, post function)

Reason:

It could fail due to one of the following reasons:

1. Broken or non-functional rules.

2. Dependencies (field, status, groups, resolution, space roles, security level) used to create rules not available on site.

3. Plugin specific rules- Plugin not installed on the site.

Resolution:

We recommend following actions based on the reasons of failure:

1. Broken or non-functional rules: No Action Required: Since the original source rule was already broken and non-functional (pointing to a deleted field), it is of no use. You do not need to take any manual steps.

2. Missing dependencies: Identify the required dependency and investigate why it was not generated during the workflow creation phase.

• Dependency Analysis: During a restore, Revyz identifies and creates the required dependencies for your workflow. If a dependency fails to create, the associated workflow rule will be skipped.

• Resolution Steps: Review the error logs to determine why the dependency creation failed. If the issue is resolvable, apply the fix and retry the restore process.

3. Plugin-specific rules:

• Install the missing plugin on the instance and retry the restore process.

• Identification: Identify which third-party app the rule belongs to (e.g., ScriptRunner, JMWE, etc.)

• Installation & Licensing: Ensure the corresponding plugin is installed and licensed on your destination site, then retry the restore.

4. Other errors: Please contact Atlassian Support for further assistance.

Category: Failed to create workflow

Reason: It could fail due to one of the following reasons:

1. Duplicate workflow: Workflow with the same name already exists

2. Workflow name is too long

3. Atlassian API rate limits, structural constraints, or temporary errors

Resolution:

We recommend following actions based on the reasons of failure:

1. Duplicate Workflow name: Rename the workflow name that failed and retry the restore.

2. Workflow name is too long : Rename the workflow name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create request body to create workflow

Reason:

It could fail due to one of the following reasons:

1. Duplicate status found on destination site

2. Duplicate transition name

Resolution:

We recommend following actions based on the reasons of failure:

1. Duplicate status: Check which one is unused and delete it or else rename it and retry the restore

2. Duplicate transition name: No action require as Revyz creates all the transition by appending_revyz<job ID> to duplicate transition, but still you want to change it then go to the

   destination restored workflow and change the transition name

Category: The workflow is created with the suffix '_revyz<restore_job_id>'

Reason:

Jira restricts certain modifications (such as adding statuses or rules) to active workflows, Revyz creates a new workflow with a suffix.

The workflow is created with the suffix _revyz'<restore_job_id>' appended to the original name. Revyz adds this suffix when it cannot update the active workflow due to an Atlassian limitation.

Resolution:

1. Workflows with a Suffix (Optional): Check if your original workflow is still needed. If not, you can safely rename or delete it. If desired, you can then remove the suffix from the newly restored workflow name.

See detailed instructions.

To clean up your site and start using your newly created workflow, follow these steps on your destination site:

• Deactivate the old workflow: Remove the original workflow (the one without the _Revyz suffix) from its workflow scheme. This will move it to an inactive status.

• Associate the new workflow: Assign the newly created workflow (the one with _Revyz<job

• ID>) to the appropriate workflow scheme.

• Clean up: Delete the old, inactive workflow if you no longer need it.

2. Any other reason: Reach out to support.

Category: Failed to create workflow with duplicate name

Reason: This error occurs because the source site has two workflows with duplicate names. One of the workflows contains an accidental leading or trailing space in its name.

Failed to create workflow because a workflow with the same name exists on the destination. This error occurs when an extra space is at the start or end of the workflow name. In this case the job is marked as 'Action needed'

Resolution: We recommend following actions based on the reasons of failure:

1. Duplicate workflow: Locate the two workflow and rename the workflow with extra space at the start or end or the workflow name.

2. Any other reason: Reach out to support.

Category: Screens

Reason: Failed to restore the screen

Resolution: Contact Revyz support.

Category: Screen

Reason: Failed to restore sub-configurations of the screen

Resolution: Check restore job logs from job details.

Category: Screen tab

Reason: Locked fields can't added/associated in the screen tab if it is not available on destination site. Locked fields are not meant to be created or modified in that way due to Atlassian API limitation.

Category: Filters

Reason: Failed to restore the filter

Resolution: Contact Revyz support.

Category: Filters

Reason: Failed to restore sub-configurations of the filter

Resolution: Check restore job logs from job details.

Category: Failed to create Sub-Tasks

Reason:

Subtasks are not created as Subtask is disabled on the destination site.

Resolution: We recommend following actions based on the reasons of failure. Check restore job logs from job details.

1. Sub-Task Disabled: The admin should enable sub-task on the destination site, then retry the restore job.

Step-by-step instructions:

Go to: https://<your-destination-site-name>/secure/admin/subtasks/ManageSubTasks.jspa

2. Enable Sub-Tasks.

3. Retry restore of Sub-Tasks.

4. Any other reason: Reach out to support.

Category: Failed to create work type scheme

Reason: It could fail due to one of the following reasons:

1. Duplicate work type scheme: Work type scheme with the same name already exits.

2. Work type scheme name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors

Resolution:

1. Duplicate Work type scheme: Rename the work type scheme that failed and retry the restore.

2. Work type scheme name is too long: Rename the work type scheme by reducing the text length and retry the restore.

3. Any other reason: Reach out to support

Category: Failed to create work type

Reason:  

1. Duplicate work type: Work type with the same name already exits.

2. Work type name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors

Resolution:  

1. Duplicate Work type name: Rename the work type name that failed and retry the restore.

2. Work type name is too long : Rename the work type name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support

Category: Failed to add avatar to the work type

Reason:  

1. Avatars are not backed up by Revyz. If the work type is restored and the avatar is missing on the restored site, failure occurs.

2. Atlassian API rate limits, structural constraints, or temporary errors

Resolution: No action required.

Category: Work type of hierarchy level 1 cannot be created

Reason:

1. If the names on the two sites for hierarchy level 1 differ, Revyz treats the two work types as the same. Atlassian API does not allow creating another work type with hierarchy level 1.

2. Work type of epic creation failed due to Jira restrictions.

Resolution: Update the work type name on the destination site manually.

Category: Failed to update Work type description

Reason: It may fail for one of these reasons:

1. Description is longer

2. Atlassian API rate limits, structural constraints, or temporary errors

Resolution:

1. Work type description is too long : Reduce the length of the description and retry update.

2. Any other reason: Reach out to support

Category: Updating the work type scheme fails to disassociate the work type.

Reason:

1.  Work items are linked to the work types to be disassociated. Atlassian requires transitioning these work items to another work type first.

2. Atlassian API rate limits, structural constraints, or temporary

Resolution: Work items are linked: Transition the work items to another work type then retry the update.

2. Any other reason: Reach out to support

Step-by-Step User Action Required

1. Open your Job Details page and download the Work Type Scheme CSV Report.

2. Open the CSV file and filter the Status Code column by R_13007.

3. Look at the filtered list to find the exact work type that failed to remove (dissociate) from its scheme.

4. Log into your destination Jira site and go directly to this URL: https://<your-destination-site-url>/jira/settings/issues/issue-type-schemes

5. Find the failed scheme from your report and click Edit.

6. Try to manually remove the work type from the scheme.

7. Jira will pop up a window asking you to choose a new work type. Select an alternative work type to safely move (transition) the existing tickets into, then save your changes.

Category: Failed to create/update a Work type scheme that has no work types in it, i.e., the Revyz app could not create an empty Work Type Scheme.

Reason: If a work type scheme has no associated work types, the restore will fail. Jira's system does not allow you to create a completely empty Work Type Scheme (one that has zero work types inside it).

• How did an empty scheme exist on your old site? Jira allows users to delete individual work types without checking where they are being used. If a user previously deleted every single work type attached to a scheme, that scheme became an "empty shell" on your source site. The app cannot recreate this empty shell because Jira's system blocks it.

Resolution:

No Action Required: Since this scheme is completely empty, it is not being used by any project (space). You can safely ignore this error.

Category: Failed to create a work type scheme that does not have at least one standard work type in it.

Reason: Work type scheme must have at least one standard work type, so the Atlassian Jira API failed to create if there is no standard work type in the source.

Jira requires every scheme to have at least one Standard Work Type (like a Story, Task, or Bug). It cannot be created with only Sub-tasks.

• How did this happen on your old site? Similar to the error above, a user likely deleted all the standard work types from this scheme on your old site, leaving only Sub-tasks behind. Jira's system will bock the app from creating a scheme like this on the new site.

Resolution:

No Action Required: A scheme containing only sub-tasks cannot by Jira projects anyway. You can safely ignore this error.

Category: Failed to create field context as associated project linked to another context on destination

Reason for Failure: It could fail due to the following reasons:

1. The field context failed to create because its associated project is already linked to another context on the destination site.

2. The project cannot be removed from the existing destination context because doing so would convert it into a second global context, which violates Jira's rule allowing only one global context per custom field.

Resolution: We recommend following actions based on the failure reason found in your restore job logs:

1. Go to your restored custom field on the destination site and evaluate whether you need the destination project context or the source project context:

   • a. If you prefer the destination context: No further action is required.

   • b. If you need the source context: Manually delete or modify the conflicting destination context associated with that project, then retry the restore for the failed context. Refer detailed instructions below.

If you encounter such a failure, you can follow either step from the following 2 options to resolve the issue:

Option 1: Choose Between Source and Destination Configurations

Follow these steps if you only need one version of the context (either the source configuration or the existing destination configuration) to apply to your project.

1. Review the Configurations: Navigate to the restored custom field and its context settings on the destination site. Evaluate whether your project requires the source context layout ("US Offices & Remote Locations") or the current destination context layout ("Indian Offices & Remote Locations").

2. If You Prefer the Destination Context: No further action is required. You can leave the existing destination context as it is.

3. If You Require the Source Context: Manually delete or modify the conflicting destination context that is currently linked to the target project, then retry the restore operation for the failed context.

Option 2: Create a Shared Context

Follow these steps if you want to preserve both context options (US and India) within the same project.

1. Locate the Field: Go to your destination site's Custom Fields configuration and open the settings for the Location field.

2. Select the Destination Context: Find the existing Indian Offices & Remote Locations context.

3. Merge the Options: Edit the options for this context and manually add the missing source options (New York, San Francisco Office).

4. Generalize the Name: Rename the context to something broader and inclusive, such as International Corporate Offices.

5. Verify Project Link: Ensure the target project (Backup & Restore) remains assigned to this newly renamed context.

Expected Outcome: The target project remains cleanly linked to a single context, allowing users within that project to dynamically select either US or Indian office locations from the same dropdown menu.

2. Any other reason: Reach out to support.

Category: Field configuration scheme

Reason: Creating field configuration scheme failed

Resolution: Check restore job logs from job details.

Category: Field configuration scheme

Reason: Restoring field configuration failed

Resolution: Check restore job logs from job details.

Category: Field configuration scheme

Reason: Restoring field configuration items failed

Resolution: Check restore job logs from job details.

Category: Failed to create field

Reason:

It could fail due to one of the following reasons:

1. Duplicate field: Field with the same name already exists.

2. Field name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors

Resolution: Check restore job logs from job details.

We recommend following actions based on the reasons of failure:

1. Duplicate field: Rename the field that failed and retry the restore.

2. Field is too long : Rename the field by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create field context

Reason: It could fail due to one of the following reasons:

1. Duplicate field context option: Field context option with the same name already exists.

2. Field context option name is too long.

3.  Atlassian API rate limits, structural constraints or temporary errors

Resolution: We recommend following actions based on the reasons of failure:

1. Duplicate field context: Rename the field context option that failed and retry the restore.

2. Field context name is too long: Rename the field context by reducing the text length and retry the restore.

3. Any other reason: Reach out to support

Category: Failed to create field context option

Reason: Restoring field context options failed

It could fail due to one of the following reasons:

• Duplicate field context option: Field context option with the same name already exists.

• Field context option name is too long.

• Atlassian API rate limits, structural constraints or temporary errors

Resolution: We recommend following actions based on the reasons of failure:

1. Duplicate field context option: Rename the field context option that failed and retry the restore.

2. Field context option name is too long: Rename the field context option by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create field

Reason:

1. Failed to create/update Field due to Jira restrictions The system field cannot be created. Only custom fields can be created.

Reason of failure: Jira limitation

Resolution: No action required.

Category: Failed to create/up date locked field

Reason: Failed to create/update Locked Field due to Jira restrictions

The locked field cannot be created, updated or deleted. Only custom fields can be created.

Reason of failure: Jira limitation

Resolution: No action required.

Category: Failed to create plugin generated field

Reason: Plugin-generated fields can only be created if the corresponding plugin is installed on the site.

Failed to create plugin-generated field due to missing plugin on destination site. The field created by a plugin on the source site cannot be restored because the required plugin is not installed on the destination site.

Reason of failure: Destination site does not have the required plugin installed.

Resolution:

We recommend the following actions based on the reasons of failure:

1. Install the plugin: Install the corresponding plugin and then check if the field is auto-created else retry the restore of that field again. Follow the instructions below:

This field is an App or Plugin-specific field. It is automatically generated when the corresponding app is installed on your source/primary site. If that app/plugin is missing on your destination (secondary) site, the field creation will fail. In this scenario, the status for the Field is "Action Required".

Step-by-Step User Action Required

If you encounter this type of failure, follow these steps to resolve the issue:

• Identify the Errors: Download the CSV report and look for fields marked with an Error status.

• Verify the Root Cause: Check the error status codes. Revyz uses status code R_14010 to specifically indicate that a field creation failed due to a missing plugin on the destination site.

• Assess Business Impact: Evaluate whether this specific field is necessary for your current business processes.

• If it is NOT useful: You can safely skip any further action.

• If it IS useful: Proceed to the next steps.

• Install the Missing Plugin: Install the required app/plugin on your destination site.

• Verify Field Creation: Once the installation is complete, search for the field on your destination site to confirm it has been successfully created.

• Add the Field to the Screen: Review the Screen CSV report to see where the field belongs, and manually add the newly created plugin field to the relevant screen.

2. Any other reason: Reach out to support.

Category: Failed to create Field Scheme

Reason for Failure: It could fail due to one of the following reasons:

1. Duplicate Field Scheme: Field Scheme with the same name already exists.

2. Field Scheme name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Field Scheme name: Rename the Field Scheme name that failed and retry the restore.

2. Field Scheme name is too long: Rename the Field Scheme name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to associate a field to a field scheme

Reason for Failure:

1. It could fail due to the following reasons:

   • Failed to add the custom field to the field configuration scheme because the field is locked or plugin-generated, and is missing from the destination site.

   • Reason of failure:

     1. Field is a locked field

     2. Field is Plugin-generated field

     3. Atlassian API failure

     4. Revyz internal issue

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Locked field: No action required.

2. Plugin-generated field: Unable to add field. Install the corresponding plugin and retry the restore.

3. Atlassian error: If the error can be resolved on your end, fix it and retry the restore.

4. Any other reason: Reach out to support.

Category: Failed to dissociate a field from a field scheme.

Reason for Failure:

Failed to dissociate the field from the field scheme because the field is locked.

Field cannot be dissociated from the field scheme because the field is locked and it is unable to remove parameters to a field in a field scheme.

It could fail due to the following reason:

1. Field is a locked field

2. Atlassian API failure

3. Revyz internal issue

Resolution

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Locked field: No action required.

2. Atlassian error: If the error can be resolved on your end, fix it and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create work type screen scheme

Reason:

It could fail due to one of the following reasons:

1. Duplicate work type screen scheme: Work type screen scheme with the same name already exists.

2. Work type screen scheme name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors

Resolution:

We recommend following actions based on the reasons of failure:

1. Duplicate Work type screen scheme: Rename the work type screen scheme that failed and retry the restore.

2. Work type screen scheme name is too long: Rename the work type screen scheme by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create screen scheme

Reason:

1. It could fail due to one of the following reasons:

   1. Duplicate screen scheme: Screen scheme with the same name already exists.

   2. Screen scheme name is too long.

   3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution: We recommend following actions based on the reasons of failure:

1. Duplicate Screen scheme name: Rename the screen scheme name that failed and retry the restore.

2. Screen scheme name is too long: Rename the screen scheme name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create screen

Reason:

It could fail due to one of the following reasons:

1. Duplicate screen: Screen with the same name already exists.

2. Screen name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

We recommend following actions based on the reasons of failure:

1. Duplicate Screen name: Rename the screen name that failed and retry the restore.

2. Screen name is too long: Rename the screen name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support

Category: Failed to add a field to the screen tab as well as when we fail to create a tab

Reason: Failed due to one of the following reasons:

1. Screen tab name is too long.

2. Atlassian API rate limits, structural constraints or temporary errors

Resolution:

User Action: following actions based on the reasons of failure:

1. Screen tab name is too long: Rename the screen tab name by reducing the text length and retry the restore.

2. Any other reason: Reach out to support.

Category: Failed to add Locked field to screen tab

Reason: A locked field is missing on the destination site. Because locked fields cannot be created or edited, it could not be added to the screen tab.

Resolution:

The source field is locked and absent on the destination, so Revyz failed to add it to the destination screen tab. Note: Locked fields cannot be created or modified

1. Log Reason of Failure: 1. Jira limitation

2. User Action: We recommend following actions based on the reasons of failure:

   1. Locked field addition: No action required

   2. Any other reason: Reach out to support.

Category: Failed to create workflow scheme

Reason: It could fail due to one of the following reasons:

1. Duplicate workflow scheme: Workflow scheme with the same name already exists.

2. Workflow scheme name is too long.

3. Atlassian API failure: Atlassian API rate limits, structural constraints, or temporary errors.

Resolution:

We recommend following actions based on the reasons of failure:

1. Duplicate Workflow scheme: Rename the workflow scheme that failed and retry the restore.

2. Workflow scheme name is too long: Rename the workflow scheme by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Workflow scheme

Reason: Creating workflow failed

Resolution: Check restore job logs from job details.

Category: Workflow scheme

Reason: Restoring workflow rule failed

Resolution: Check restore job logs from job details.

Category: Workflow scheme updated but left unpublished as a draft.

Reason: It could fail due to one of the following reasons:

1. The workflow scheme already exists on the destination site and it is active state. Revyz successfully updated the scheme but was unable to publish it.

Step-by-step instructions:

To make your updates live and apply them to your project, you must manually publish the draft workflow scheme by following these steps:

1. Find the affected workflow schemes: Open your restore job CSV report and filter by status code R_16005 to see the list of schemes left in draft mode.

2. Locate the scheme in Jira: Navigate to the workflow schemes page on your destination site using this URL (replace with your actual site name): https://<your-destination-site-name>/secure/admin/ViewWorkflowSchemes.jspa.

3. Find the draft: Search for the workflow scheme name you found in the report. You will see it listed with a Draft status.

4. Publish the changes: Click on the draft workflow scheme and select Publish to make the updates active.

Resolutions

• We recommend following actions based on the reasons of failure:

  1. Publish the workflow scheme: Navigate to your destination site, locate the newly restored/updated workflow scheme, and manually publish the draft. Click the link for detailed instructions.

  2. Any other reason: Reach out to support.

     
     

Category: Failure to create permission scheme

Reason:

It could fail due to one of the following reasons:

1. Duplicate permission scheme: Permission scheme with the same name already exists.

2. Permission scheme name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Permission scheme: Rename the Permission scheme that failed and retry the restore.

2. Permission scheme name is too long: Rename the Permission scheme by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: The permission scheme is created with suffix '_revyz'

Reason:

It could fail due to the following reasons:

1. The permission scheme exists on the destination. Revyz will not update the existing scheme and will instead create a new one with a suffix.

To prevent security risks -such as unauthorized users gaining access if a permission scheme is linked to multiple destination projects- Revyz never overwrites existing permission schemes. Instead, a new permission scheme is always created and appended with a suffix.

Resolution:

We recommend following actions based on the failure reason found in your restore job logs: Click the link for detailed instructions, below:

Note: Your project is already safely migrated. If you are happy with the new name, no action is required. However, if you want to use the original name, follow these steps carefully:

Step 1: Security Check (Crucial)

1. Log in to your destination Jira site.

2. Go to Jira Settings > Issues > Permission Schemes.

3. Open the newly restored scheme (the one ending in _revyz<jobID>).

4. Carefully verify the permissions: Double-check that only the correct users, groups, and roles have access. Ensure no unwanted users have been granted permissions.

Step 2: Clean Up the Old Scheme

1. Locate the old permission scheme (without suffix) on the destination site: https://<your-destination-site-name>/secure/admin/ViewPermissionSchemes.jspa

   
   

2. Either Delete it (if it is no longer linked to any projects) or Rename it to something else (e.g., IN software permission scheme_OLD).

Step 3: Rename the New Scheme

1. Open the new permission scheme (IN software permission scheme_revyz<jobID>).

2. Edit the name to remove the _revyz<jobID> suffix so it matches your original source name.

You're all set! Your permissions are now up-to-date and correctly named.

1. For Space Clones: The newly restored permission scheme (appended with the suffix _revyz<jobID>) is already associated with your new project. If desired, you can manually rename the permission scheme to remove this suffix.

2. For Jira Configuration Clones: The permission scheme was created with the suffix _revyz<jobID>. However, it will not take effect until it is linked to a project. Please manually associate this scheme with your target project.

Category: Failed to restore Space role

Reason:

It could fail due to one of the following reasons:

1. Duplicate Space roles: Space role with the same name already exists.

2. Work type name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Space role name: Rename the space role name that failed and retry the restore.

2. Space role name is too long: Rename the space role name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create Project/Space

Reason: Project creation failed

It could fail due to one of the following reasons:

1. Duplicate Project/Space name OR Project/Space key: Project/Space with the same name or same key already exists.

2. Insufficient Permissions: Specified space owner does not have permissions to create Project/Space.

3. Invalid Project Key Format

4. Licensing Limitations: e.g., trying to create a JSM project without a Jira Service Management license.

5. Atlassian API rate limits, structural constraints or temporary errors

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Project/Space: Rename the failed Project/Space and retry the restore.

2. Insufficient Permissions: Grant the required permissions to the space owner and retry. Alternatively, attempt the restore using a different owner who has project creation permissions on the destination site.

3. Invalid Project Key Format: Update the source project key to a valid format and retry the restore.

4. Licensing Limitations: Add licenses for Jira Service Management (JSM), Jira Work Management (JWM), and Jira Product Discovery (JPD) to your destination site.

5. Any other reason: Reach out to support.

Category: Failed to create Project (Space) Category

Reason:

It could fail due to one of the following reasons:

1. Duplicate Project/Space Category: Project/Space Category with the same name already exists.

2. Project Category is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Project/Space Category name: Rename the Project/Space Category name that failed and retry the restore.

2. Project/Space Category name is too long: Rename the Project/Space Category name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create Project (Space) Feature

Reason: It could fail due to any of the below reasons:

1. Atlassian API failure

2. Revyz internal issue

Resolution: We recommend following actions based on the failure reason found in your restore job logs:

1. Temporary Server Error: This may be due to a temporary server error. Please wait a few moments and try the restore again.

2. Any other reason: Reach out to support.

Category: Failure creating project feature due to Jira restrictions (Project Features).

Reason:

This is expected behavior, as these features cannot be created using Jira REST APIs.

• Jira limitation

Resolution:

• No action required.

• Alternatively, check the app license on the destination site, otherwise contact Revyz support

Category:

1. Failed to create Project as Project Key is longer than allowed limit / Failed to restore project due to project key length limits

Reason:

It could fail due to the following reason:

1. Project Key length limit exceeded: The project could not be created because the project key from the source site exceeds the maximum character limit currently allowed on the destination site.

• Reason of failure: Destination site configuration limit

Detailed instructions

• Step 1: Identify the Failed Spaces

  1. Open your completed restore job inside the Revyz app.

  2. Click Download CSV Report.

  3. Open the CSV file and filter the Status Code column by R_19006 to see the list of failed spaces.

• Step 2: Increase the Key Length Limit in Jira

• Log into your destination Jira site.

  1. Navigate directly to your general settings URL (replace with your actual site name):

     https://<your-destination-site-name>/jira/settings/system/general-configuration

  2. Click Edit Settings (if applicable) and scroll down to the Options section.

  3. Locate the Maximum space key size field and change the value to 255.

  4. Save your changes and retry the restore for the failed space.

Resolution

We recommend following actions based on the failure reason found in your restore job logs:

1. Project Key Limit exceeds: Reduce the length of Project Key and retry the restore. Click the link for detailed instructions.

2. Any other reason: Reach out to support.

Category: Failed to create Project as project name is longer than allowed limit / Failed to restore project due to project name length limits

Reason for Failure: It could fail due to the following reason:

1. Project Name length limit exceeded: Project Name length is more than allowed limit on destination site.

2. Configuration Constraint: Destination site configuration limit.

Detailed Instructions

Step 1: Identify the Failed Spaces

1. Open your completed restore job inside the Revyz app.

2. Click Download CSV Report.

3. Open the CSV file and filter the Status Code column by R_19007 to see the list of failed spaces.

Step 2: Increase the Name Length Limit in Jira

1. Log into your destination Jira site.

2. Navigate directly to your general settings URL (replace with your actual site name):

   https://<your-destination-site-name>/jira/settings/system/general-configuration

3. Scroll down to the Options section.

4. Locate the Maximum space name size field and change the value to 150.

5. Save your changes and retry the restore for the failed space.

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Project Name Limit exceeds: Either increase the maximum allowed limit on the destination site and retry the restore (Recommended) , or rename the project to reduce its length and retry restore of failed project.

Any other reason: Reach out to support.

Category: Failed to update Project (Space) Features

Description / Reason for Failure:

Failed to update project feature due to Jira restrictions. The project feature state could not be restored because Jira has locked this feature, preventing it from being enabled or disabled.

1. Reason of Failure: Jira limitation (Jira has locked the some feature)

2. User Action: No action required

Category: Failed to create Project/Space Component

Reason for Failure: It could fail due to one of the following reasons:

1. Duplicate Project Component: Project Component with the same name already exists.

2. Project component name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Project Component name: Rename the Project Component name that failed and retry the restore.

2. Project component name is too long: Rename the Project Component name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Project/space component creation failed as component lead does not exist.

Reason for Failure:

Component lead does not exist on the destination site. As a result, the project component failed to restore

User action:

We recommend following actions based on the failure reason found in your restore job logs:

1. Add the missing user to the destination site and retry the restore for the failed components.

Category: Project/space component update failed as project not found on destination

Reason for failure: The component could not be updated because the corresponding project/space is not available on the destination site

User action:

We recommend following actions based on the failure reason found in your restore job logs:

1. Create the Project: Create the project on the destination site first and then retry the component restore. Alternatively, use the Space Clone feature to migrate the space along with all of its components simultaneously.

2. Any other reason: Reach out to support.

Category: Failed to create Project Version

Reason for failure:

1. Duplicate Project Version: Project Version with the same name already exists.

2. Project Version name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Project Version name: Rename the Project Version name that failed and retry the restore.

2. Project Version name is too long: Rename the Project Version name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create Board

Reason for Failure: It could fail due to one of the following reasons:

1. Duplicate Boards: Boards with the same name already exists.

2. Board name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

User action:

We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Board name: Rename the Board name that failed and retry the restore.

2. Board name is too long: Rename the Board name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support

Category: Failed to create Sprints

Reason for Failure:

It could fail due to one of the following reasons:

1. Duplicate Sprint: Sprint with the same name already exists.

2. Sprint name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

User action:

We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Sprint name: Rename the Sprint name that failed and retry the restore.

2. Sprint name is too long: Rename the Sprint name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create Filters

Reason for Failure: It could fail due to one of the following reasons:

1. Duplicate Filters: Project component with the same name already exists.

2. Filters name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Filters: Rename the Filters name that failed and retry the restore.

2. Filters is too long: Rename the Filters name by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create filter due to insufficient permissions.

Reason for Failure: The permissions that can cause failure are:

1. Filter edit permission

2. Filter share permission

3. Filter owner

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Insufficient permission: Update the permission and retry the restore.

2. Any other reason: Reach out to support.

Category: Failed to create Request Type

Reason for Failure: It could fail due to one of the following reasons:

1. Duplicate Request type scheme: Request type with the same name already exists.

2. Request type name is too long.

3. Atlassian API rate limits, structural constraints or temporary errors.

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Duplicate Request Type: Rename the Request Type that failed and retry the restore.

2. Request Type name is too long: Rename the Request Type by reducing the text length and retry the restore.

3. Any other reason: Reach out to support.

Category: Failed to create Data connection linked to Form templates

Reason for Failure:

It could fail due to the following reasons:

1. Due to Jira limitations, the form templates restore successfully, but their associated data connections and links do not recreate.

Resolution:

User Action: We recommend following actions based on the failure reason found in your restore job logs:

1. Manually create the connection: Manually create the data connection on the destination site and link it to your restored form templates. See below for detailed instructions.

2. Any other reason: Reach out to support.

If Form Templates status shows a failure, follow these steps to troubleshoot and resolve the issue:

Step 1: Locate the Failed Form Templates

1. Open your completed restore job in the Revyz app and download the CSV Report.

2. Open the CSV report.

3. Filter the Status Code column for R_28001 to see the exact list of Form Templates whose data connection was not created.

Step 2: Recreate the Global Data Connection (Requires Jira Admin Permission)

1. Go to: https://<your-destination-site-name>/jira/settings/forms/data-connections.

2. Click Add connection.

3. Enter the original connection Name, URL, and Authentication details.

4. Click Next to run the connection test.

5. Map your JSON Schema keys (Items, ID, and Label) to match the source setup.

6. Click Create to save the global connection.

Step 3: Link the Connection to the Form Template (Requires Project Admin)

1. Navigate to the project where your form template was restored.

2. Go to Project settings (or Service desk project settings) > Forms.

3. Locate and click on the restored form template to open the editor.

4. Click on the specific form field (Dropdown, Checkbox, or Radio button) that originally used the live data.

Step 4: Map the Fields and Save (Final Validation)

1. Look at the properties panel on the right-hand side of the form editor.

2. Scroll down to the Data connection section.

3. Select your newly recreated data connection from the dropdown menu.

4. Click Save changes at the top right of the form builder.

Category: Excluded Configurations: Dependencies that already exist on the destination site can be deselected if you don't want to overwrite them. These skipped items are tracked under a specific status code.

Reason for Failure: Configuration excluded by user before initiating the restore.

Resolution: No action required.

See detailed instructions below:

How Configuration Dependencies Work During Restore

1. What Happens First?: When you start a restore, Revyz automatically lists all the dependent configurations required to successfully create your selected item.

2. Can You Deselect Dependencies?: Yes, but only if the following two conditions are met:

   1. The dependency already exists on your destination site.

   2. You do not want to overwrite or modify it.

3. What is an "Excluded Configuration"?: If you uncheck a dependency, it becomes an Excluded Configuration. This means Revyz will leave the existing version on your destination site completely untouched.

4. Status Tracking: To keep your logs clear, we assign a specific status code to these items so you know they were skipped intentionally.

Category: Miscellaneous (COMPONENTS 001)

Reason: Creating project component failed

Resolution: Check restore job logs from job details.

Category: Miscellaneous (FILTERS_PARTIAL 008)

Reason: Creating Filter partial failed

Resolution: Check restore job logs from job details.

Category: Miscellaneous (FILTERS_SETTINGS 009)

Reason: Creating filter due to user permissions failed

Resolution: Check restore job logs from job details.

Category: Miscellaneous (FILTERS_SETTINGS 009)

Reason: Creating filter due to user permissions failed

Resolution: Check restore job logs from job details.

Category: Miscellaneous (UNCHECKED_BY_USER 010)

Reason: Excluded by user

Resolution: Check restore job logs from job details.

Category: Object schema

Reason: Object schema creation failed

Resolution: Read only object schema is not supported for restore as they are not editable.

Category: Object Types

Reason: Object type position failed

Resolution: Check restore job logs from job details.

Category: Object Types

Reason: Object type icon is not restored

Resolution: Object type is restored with alternate icon

Category: Statuses

Reason: Creating status failed

Resolution: Check restore job logs from job details.

Category: Statuses

Reason: Status with same name is failed to restore

Resolution: Status with same name was already present hence status is created adding 'revyz<jobId>' as suffix

Category: Reference types

Reason: Reference types with same name is failed to restore

Resolution: Reference types with same name was already present hence reference types is created adding 'revyz<jobId>' as suffix

Category: Attributes

Reason: Attribute with default reference type

Resolution: Attribute is restored with default reference type

Category: Attributes

Reason: Attribute is not updated

Resolution: Could not edit the attribute as it is not editable

Category: Attributes

Reason: Attribute create without attribute type 'Group'

Resolution: Attribute is created without type group

Category: Attribute Label

Reason: Failed to Update label

Resolution: Check restore job logs from job details.

Category: Assets objects

Reason: Object creation failure

Resolution: Check restore job logs from job details.

Category: Assets objects

Reason: Failed to add value to object attribute

Resolution: Check restore job logs from job details.

Category: Failed to create Tempo timesheet worklogs

Reason:

It could fail due to following reasons:

1. The Timesheet app is not installed on the destination site.

2. The Tempo API token added to the destination Revyz app has expired.

3. Both the Original and Default Authors are missing from the destination site.

4. The permissions required to create worklogs are not available on the destination site because:

   • a. Override mode is disabled.

   • b.. The period is closed.

   • c.. The user account associated with the Tempo token on the destination site lacks the required permissions to create worklogs, log work on behalf of others, or set billable hours.

5. A destination Work Attribute is required.

Resolution:

We recommend following actions based on the failure reason found in your restore job logs:

1. Timesheet app missing: Install the Tempo Timesheet app on destination. Create tempo api token. Add it on destination Revyz app and retry the restore again.

2. Tempo API Key expired: Create new API key. Add it on destination Revyz app. And retry the restore.

3. Original and Default Author missing: It might be possible that Original author and Default owner both are missing. It might be possible after trying restore, someone remove the default owner from destination site.

4. Permission not available: Based on the logs appeared, take the action

   • a. Override permission- Enabled

   • b. Period closed- Change the setting to Open for all for the specific dates you want to restore worklogs to.

   • c. Permission not available- Grant the following permission access to the user whose tempo token used on destination.

     • i. Work On Issues

     • ii. Log Work for Others

     • iii. Set Billable Hours

5. Work attribute required on destination: Go to the destination site tempo app, and change the work attribute to optional.

6. Any other reason: Reach out to support.

Step-by-step instructions:

Take the action based on the reason of failure:

I. Missing Tempo Timesheets app

If the logs indicate that the Tempo app is missing:

1. Navigate to the App section > Explore more app

2. Search for the Tempo Timesheet Worklogs

3. Install it

4. Create the tempo token:

   • a. Go to Settings (bottom-left corner) > API Integration.

   • b. Create new token with Full Access.

5. Add it on Revyz app:

   • a. Navigate the destination site revyz app.

   • b. Setting > General Setting > Tempo plugin API token.

   • c. Add it.

6. Retry the restore

Expired Tempo Token

If the logs indicate that the Tempo Token is expired:

1. Create the new tempo token:

   • a. Go to Settings (bottom-left corner) > API Integration.

   • b. Create new token with Full Access.

2. Add it on Revyz app:

   • a. Navigate the destination site revyz app.

   • b. Setting > General Setting > Tempo plugin API token.

   • c. Add it.

3. Retry the restore

Missing Original owner or Default Owner:

Retry the restore and Ensure the selected default owner is active on the destination site, make sure no user accounts are modified or removed during the restore process.

Permissions not Available

Enable Override Mode

If the logs indicate that the override mode disabled:

1. Navigate to the Tempo app.

2. Go to Settings (bottom-left corner) > Override Mode. Turn the toggle ON.

2. Verify Period Management

If the logs indicate that the target period is closed:

1. Navigate to the Tempo app.

2. Go to Settings (bottom-left corner) > Period Management.

3. Make sure the status is set to Open for all for the specific dates you want to restore worklogs to.

3. Manage Worklog Permissions (When the whose token used lacks access)

• Option 1: Grant Global Tempo Permissions (Recommended)

  • Use this instead of changing permissions for each individual project.

  • If you are restoring worklogs for multiple projects -such as a Space Clone (always for both single & multiple space), a multi-project Work Item restore, or a multi-project Tempo Timesheet worklog restore-always update the global settings.

  • a. Navigate to the Tempo app.

  • b. Go to Settings (bottom-left corner) > Permission Roles.

  • c. Add the user whose Tempo token was added to the destination site's Revyz app.

  • d. Assign the Manage Worklogs permission to this user.

• Option 2: Grant Project-Level Permissions (Alternative)

  • If you are only restoring worklogs for a single project (Single Project Work Item/Tempo Timesheet restore), you can update the permissions for that specific project's permission scheme only.

  • a. Navigate to the destination site's Project Settings > Permissions.

  • b. Ensure the user whose token is used has been granted the following four permissions:

    • Work On Issues

    • Log Work for Others

    • Set Billable Hours

    • View All Worklogs (This ensures the user can see and verify all worklogs after they are restored)

V. Work Attribute Required

• Open the Tempo app on your destination site.

• Navigate to Settings (bottom-left corner) > Work Attributes.

• Review your restoration logs to identify which specific required work attribute caused the failure.

• Edit that work attribute and change its status from Required to Optional.

• Retry the restoration job.