Frequently asked questions (FAQ's)

• Atlassian Account– You must have an active Atlassian Cloud account (e.g., Jira, Confluence).

• Product Access – You need access to the Atlassian Cloud products where the API token will be used.

• Site Access – You must have access to the specific Atlassian Cloud site where the token will be used.

Jira cloud data backed-up is retained for a period of 30days

A backup job automatically runs everyday at 00.00 - 02.00 UTC. You as the administrator do not have to do anything to schedule the backups, they occur automatically. You can also change time frame as per the requirement

The first backup can take long time depending on number of Jira configurations to be backed up. All the subsequent backups after that are forever incremental which means it will always transfer only updated / created Jira configurations since previous successful backup.

Yes we offer a free trial for a minimum of 30 days and a maximum of 59 days. The exact number of days is determined by Atlassian based on your billing cycle.

Once you install the app from the marketplace, the first backup is triggered if you select Run immediate Jira configuration backup while installing and your future alternate days backups are immediately scheduled.

The back end infrastructure we have built is all server less, it takes a minute or so for a new “container” to get spun up to get the job worked on. This is true for both backups and restores.

Revyz backs up your Jira data into Revyz’s Amazon Web Services (AWS) tenant. The supported AWS data centers are:

• us-east-1 (Northern Virginia)

We plan to add support for additional AWS data centers over the course of time.

Data security is paramount at Revyz. We ensure data is encrypted in-motion and at-rest.

Data at-rest is encrypted using industry standard envelope encryption scheme.

1. Transport Layer Security (TLS) 1.2 to protect data in-motion over the internet

2. TLS is terminated in Revyz’s cloud compute process

3. Tenant specific and unique key encryption key (KEK) is created and stored in AWS Key Management System (KMS)

4. A unique data encryption key (DEK) is generated per “n” objects used to encrypt data at-rest stored in S3. Objects references Jira issues, attachments and configuration elements within Jira

5. DEK is further encrypted using KEK and is stored in S3 along with the corresponding objects that where encrypted with that specific DEK

Learn more about envelope encryption here

Customer data backed up within Revyz is encrypted and not accessible or readable by Revyz employees as part of their regular operations. Access to data stored within Revyz is solely subject to policies and authorized user permissions established and managed by the customer.

All activity within the Revyz Configuration Manager for Jira with AI app is logged. Please reference the audit log feature available within the app under the “Settings” menu.

Yes Revyz SOC2 Type II, if you need the SOC2 report, please open support request here.

After the completion of the free trial, if you decide to continue with the Revyz Configuration Manager for Jira with AI app, your data continuous to reside with Revyz, if for some unforeseen reason you decide to not to continue with Revyz, your data will be automatically deleted on the 5^th Saturday after you have un-installed our application.

• Revyz Security & Compliance Overview

To learn more about Revyz’s Security policies, please Revyz’s security documentation available here.

• Main job status will be “Partial success“ for:

  • ScriptRunner backup

  • Automation rules backup

• Only non-scripted JMWE rules are eligible for restoration.

• Limitations for Non-Scripted Rules

  • Shared Actions (JMWE app):

    • Shared Action ID: The Shared Action ID will not be created on the destination site and therefore will not be mapped to the post function.

  • Rules (Conditions, Validators, Post-functions) with Statuses:

    • While the associated statuses are restored on destination, their automatic mapping to post functions cannot be guaranteed. They may or may not be automatically mapped to their respective post functions.

    • The user will need to manually map these statuses after the restoration process.

  • SendSlackMessageFunction:

    • The backup and restoration of this specific post function is not handled by Revyz.Hence restore of this post function is not possible.

    • Workflow containing this post function will be restored, but the Send Slack Message post function itself will be dropped from the workflow.

    • It will need to be manually re-added and configured after restoration.

• ScriptRunner PREMIUM - Some rules require manual actions to be completed. This means that for certain rules conditions or triggers, an automated process won't be sufficient, and you will need to personally intervene to perform specific tasks.

  • Supports backup for:

    • Script Listeners

    • Scheduled Jobs

    • Workflow Scripts

    • Behaviours

    • Escalation Service

    • Scripted Fields

    • Script Variables

    • Script Fragments

    • ScriptRunner settings

• JMWE rules

  • Supports backup for:

    • Scripted JMWE rules

    • Non-scripted JMWE rules

  • Supports restore for:

    • Scripted JMWE rules are not fully restored.

    • While the shell of these rules may be created, the specific configuration objects used within these scripted rules cannot be created and replaced or re-linked automatically during the restoration process.

    • Manual re-configuration of the script content will be required for these rules.

    • Non-scripted rules. There are some limitations.