Instead of making us import our Automations, just write over them like you do the rest of the project. Or better yet, give us an option to overwrite the automations, or not.

7/29/24 - adding a comment regarding the  new sandbox refresh process for Specific Projects.  The validation step where it detects the existing project in Sandbox and requires it to be deleted before the process can begin.  This additional step adds a significant amount of time to the refresh process whereas prior, copying production data to sandbox would begin immediately and just overwrite the project in sandbox.  Please consider an alternative to deleting the project and allowing the option to overwrite.

Another issue we ran into with the new copy production data to sandbox is the automation rules that existed in sandbox are not removed so when we finished our copy of production project to sandbox and tried to import the automation rules, it wanted to add them as a copy of the existing rule.  The only work around would be to first delete the automation rules in sandbox that are associated to the project we will be copying and then re-import the rules so we have the most up to date prod version of the rule.  This is very time consuming as we are not able to delete automation rules in bulk, only one by one as well as the newly copied project does not have the same ID associated to it so as we select which automation rules to import, we also have to associate them to the project.  We have 111 automation rules so this is also time consuming.

Due to the issues encountered with copying a specific project vs. all projects, we will continue to copy all projects to avoid.

I agree completely with a feature request to deploy configurations from the Sandbox to Production. I was surprised to see that it was missing when I first used my Jira sandbox.

For anyone interested, I eventually solved that problem in Jira using a tool called Salto (https://www.salto.io/jira).  However, I would still love to see this natively supported, especially since Salto doesn't support Confluence.  (I'm not affiliated with Salto; I'm just a happy customer.)

I don't see a feature request to push configuration from the Sandbox to Production. This is more important to me than data.

https://community.atlassian.com/t5/Jira-Software-questions/Mandatory-field-quot-Sprint-quot-in-Bulk-migration/qaq-p/2684387

Good morning.  Just wondering if the ability to select PROD data to move to a Jira Cloud sandbox environment has been implemented yet.  I understand that, per your Sandbox creation documentation, only members of an EAP were previously enabled to select specific PROD data however wondering if this has now become standard functionality for a Jira Cloud Sandbox.  

Thanks!

Hey Team, 

Quick question, I was wondering if there is a reason why creating a Team in Sandbox appears in Prod. I am trying to test out the functionality for Teams before getting my org to implement it and it is inconvenient to have the Teams show up in Prod without proper transition. 

The sandbox is a great feature. Even in the short time that I have been using the Confluence and Jira sandboxes the usefulness of having an environment that is completely separate from production where testing can be carried out, is clear. They are good for trying out apps too. Thanks Atlassian team!

Hi Max,

Thank you for the reply.  Unfortunately, I do not see that option.  I've already asked Atlassian Support, and they told me the functionality was not supported.  That's what prompted me to submit the feature request. 

Regardless, I appreciate the advice, and I'll submit a new support ticket. Thank you!

Hey 0b00da0e7817,

We allow the capability to create a Jira Service Management Free sandbox provided you have Jira Service Management free AND any other Jira premium product in your production environment.

To create a sandbox please follow these instructions: https://support.atlassian.com/organization-administration/docs/manage-product-sandboxes/#Create-a-sandbox 

You should see an option for Jira Service Management on your site. If not please raise a support request and we can have a look at it!

Thanks,

Max

Feature request:  Ability to install Jira Service Management Free into my sandbox.

Context:  I use Jira Software Premium with Jira Service Management Free in my production site.  But my sandbox environment only contains Jira Software, my only Premium-level subscription.

Problems:  

1. My sandbox environment contains configurations for Jira Service Management (copied from PROD), but I need the JSM software installed to manage them.  For example, JSM's SLA fields exist in my sandbox environment even though I have no JSM installed.
   1. Note:  This is like having JSM half installed.
2. My sandbox environment doesn't match my PROD environment because it's missing JSM.  This, of course, diminishes the value of some of the configuration testing I may do.
   1. Note:  This behavior is inconsistent with Marketplace apps.  Atlassian lets me keep parity between SANDBOX and PROD by allowing me to install the same third-party apps at no additional cost...why not the same Atlassian apps?

Again, I'm only looking for the Free edition of JSM in my sandbox.  Atlassian lets me use JSM free in my PROD site and any developer sites...why not my sandbox?

Otherwise, please make the sandbox builder smart enough to exclude JSM configurations.  That would at least solve the first problem. (I realize how challenging this would be in practice, which is another reason I'm advocating to allow JSM Free.)

// End of rant

Thanks!

Adding Features for "copy only config (i.e. no issue / attachments data)" or "do not copy over attachments" would seem like obvious wins in terms of speed and also processing power required for larger Jira instances. 

https://getsupport.atlassian.com/browse/PCS-171851
The customer on this ticket is upset because Assets and Automation rules cannot be copied to the sandbox environment:

When will it be possible to have at least two sandboxes per site in a premium subscription? We think it is important to have a development and a pre-production environment in addition to the production environment.

About the transfer of configuration between environments, especially from sandbox to production, including the configuration of plugins, this could be a requirement for plugin manufacturers: To have a configuration transfer interface for their plugin. This way you could pass the configuration of Atlassian products between sites and then transfer plugin configurations. This transfer of configuration (including plugins) and data, between environments, is very very necessary. The indicated workarounds are not valid.
When will these facilities be available?

Plugin licenses in sandbox environments should be the same as in production environments as they are in Atlassian.
What solution can we have here?

I have created my first sandbox successfully. Upon creation I did the Production data copy, but noticed that not all projects and their tasks came over. I deleted the sandbox and tried the copy again and still those same projects are missing. The projects that did not come over don't seem to have anything in common and they have similarities to projects that were successfully copied. There were larger and smaller projects that were copied properly. There were both Company Managed and Team Managed projects that were copied,  so I am at a bit of a loss on why the copy didn't work successfully.

It would be a great feature, in my opinion, if we could select specific projects to copy as I don't need the entire Production system copied over.

Once you do a backup (in Jira Cloud), it gives you an option to download. If it's small enough, I just downloaded it and reuploaded it to the sandbox.

Any recommendations about how to manually copy the production insight to sandbox?  Thanks!

It seems that Sandboxes are no longer available for Premium users? The official documentation link: https://support.atlassian.com/organization-administration/docs/manage-product-sandboxes/ is no longer reflective of what admin.Atlassian looks like now.

Where is the customer portal side of the Sandbox for JSM?

Thanks! -AS

We just did our first data copy after the initial.  I noticed 2 things so far I wasn't expecting.  

1:  Group memberships are not being pulled down into the sandbox

2:  It removed all of the automation we had imported into the sandbox, I get not updating them but wasn't expecting them to be removed.

Something I would like to see

on an automation import the ability to remove any webhook information.  We have several automation's that are instantiated with incoming webhooks.  Being able to regenerate those via a checkbox on the import automatically would be super helpful.  Currently, I am editing the JSON before import and replacing the webhook key with generic data.  Not ideal if I miss one.

Hi Matt, 

Thanks for your response to my request re: the access invite link for Sandbox and allowing users to be added when a Sandbox is recreated. I believe your question helped clarify for me how the Sandboxes should be perpetuated. Originally I recreated the Sandboxes to address a data residency issue (we had moved regions for Prod and subsequently wanted the same for the Sandboxes, I was told recreating them would address the residency region to match Prod after that move...note: it did not). 

So that's why they were recreated in this case, but for best practices moving forward – any future Prod refreshes we should only need to "Copy Production Data" from the Sandbox Management console, correct? Would there be any other common reasons for having to recreate the Sandboxes from scratch? Thank you.

I completely agree with Ignacio Pulgar's comments above.  Hopefully we can see this update soon in the Sandbox.  Thanks.

Hi Matt,

In my opinion, the date there should refer to when the sandbox environment data was last overwritten (either last time created or last time production data was copied).

Last updated alone is too vague to understand that, unless it had a question mark icon which displayed a longer explanation on a tooltip, especially because of the meaning of updated in Jira issues, which would mean the last time any Jira issue had any kind of change in the environment. This last meaning is not relevant at all.

Last built __ seem to be more a appropriate column header, as that would be easier to understand without further information.

Of course, this information is useful, as it would allow to know the date when Production data was last copied to the sandbox.

Thanks for adding this!

My guess is it's the last time content in the application was updated.

For me I would prefer if it was the date that the prod data was copied to the sandbox. 

Hi everyone,

We're looking to get some feedback on the sandbox UI.

1. What do you think the Last updated information is?
2. And is this useful for you? Why or why not?

I've seen different slices of this around, but it doesn't seem to be captured anywhere holistically in the "what we're doing" side of things, so want to be explicit in my feature request:

I need to be able to select specific configuration objects or schemes of objects and push them between sandbox and production on a near-immediate basis so that I can make changes to those objects in a safe place but get them into production cleanly.

b3574a68a193, thanks for the feedback. We're going to be adding sandbox events to the audit log in the coming month or so. You can track that here: https://jira.atlassian.com/browse/CLOUD-11245

d46d44ee088d, can you help me better understand what you're trying to accomplish by having separate API access for the sandbox site? You can already have separate user access levels (i.e., you can designate which users and groups have access to your sandbox and/or your production site(s) independently). If I've misunderstood the question, please let me know.

jmueller4, thanks for the feedback and suggestion. We'll take this into consideration. Out of curiosity, can you help me understand why you need to recreate the sandbox from scratch? And how often is this happening?

I would like to suggest another item for the Sandboxes. It would be very helpful to allow admins to add already-verified site users from the Production environment to a newly generated Sandbox. Each time a sandbox is created, its required for users to accept yet another Invite Link to be granted access to the Sandbox. 

Our use case is we have several accounts we've created/delegated as service accounts for running automation/external scripts. Since we can no longer use "locally" created accounts and requires an email address, every time a Sandbox is created we have to spend time finding/setting mail-forwarding for these accounts so we can even access the Invite Link. 

This interrupts/delays all testing from teams needing to work in the new Sandbox.

If we perhaps had an option to add specific accounts for immediate Sandbox access when its created (given they have already been verified in Prod) it would be far easier to manage, thank you.

Can you have separate API access for Sandbox from production? Also confirming you can have separate user access levels. Thanks!

Another feedback that I would like to share is the security audit log who can be viewed by Org Admin.  The audit log does not distinct the changes made in production vs sandbox.  

I found another unexpected behavior on saved filter in sandbox.  While I was trying to play around the columns under a saved filter that is owned by me in production in sandbox, I realized that I cannot edit columns.  See screenshot below.  Is this a bug?

EDIT: I just realized that this information is actually available [here | https://support.atlassian.com/organization-administration/docs/manage-product-sandboxes/,] my apologies!

Hi Matt,

I have some additional feedback regarding Groups within Sandbox. My team experienced some confusion with project access. After some testing, we realized that the members within groups do not copy over from production. We had to manually add members into the existing groups. This information would be beneficial to Jira users that are initially building their sandbox, as well as information on any other components that do not copy from production.

Thanks,

Tiffany

@Matt Tse - I have sent you email with the details. 

Hi e8230a4c25d0,

Thanks for your feedback. We have not considered including automation rules in the copying experience. The automation experience in Jira Cloud has a built-in import/export capability. Would this address your need? 

b3574a68a193, thanks for the feedback! I've taken over for Dave as the PM for this feature. Really appreciate the detailed response. Could I ask that you email me (mtse@atlassian.com) screenshots of the confusion you highlighted in #2? I want to make sure that I've followed the correct steps so we can make this clearer. Thanks!

Hi Dave - I just created a Sandbox today and copied the data over from production.  Looks good so far, but I have 2 feedback here for you.

1) Put a banner on top to show that we are in the Sandbox environment.  Since it looks just like production, user who has access to both site may accidently use the incorrect site to action.

2) Add note on the "Manage Product Sandbox" documentation to guide us on how to add users from production to the sandbox site.  The "user" screen returns different values, depends on how I access it.  Below are the steps that I went through.  It can confuse the admin who is trying to give access.

       As an Org Admin when I go to Products and hover to the 3 dots on the Jira Software Sandbox, I see "manage users".  When I click onto "manage users", I don't see any users except myself after the data is copied from production.  This mislead me to "invite users" who already have access in production but nothing happens after.  I tried multiple times.

       While I continue to stay on this screen called "Users", I realize if I click "users" on the left panel, all users from production will appear now.  This is where I need to hover to the 3 dots for the user which I want to give access and pick "Show details" and then "enable" Jira Software.

Hi, we rely quite heavily on automation so it doesn't make sense for us to get Premium and a sandbox if we can't copy them (vs. having a separate site). Is this on your roadmap?

Thanks in advance.

Matias.

Hi 9b5c714959a4,

Thanks for your interest. That's definitely something we've thought about but we're in the midst of evaluating the feasibility of providing a partial/selective data copying experience. I'd suggest keeping an eye on the subtask here for future updates specific to this ask.

Cheers,

Matt

Hi @Matt Tse,

I like that there is a copy option now, but I'm wondering if this could be with more functionality to choose what data you want to copy, instead of just a full copy?

The option to copy just a single project would help a lot, as I don't want to overwrite all changes or tests I'm currently running in my Sandbox

Hi 2e3dff485ad3,

Apologies for the delayed response! Here's a summary of what data is/is not copied over with our current implementation of data copying:

Data that is copied over:

• All Jira & Confluence configuration data (global permissions, workflows, screens, schemes, custom fields, issue types, etc)
• Jira content, including issue data
• Confluence content, including page data and media files (attachments, avatars, logos)
• Users & groups

 
Data that is not copied over: * Jira media such as attachments (this will be coming in the future)

• Confluence private spaces
• Marketplace app data because this is stored by app developers outside of Atlassian
• Users & groups membership such as product access and admin access (you'll need to reapply these after performing the data copy in the user management UI)

 
Underneath the hood, our data copying essentially functions the same way as if you were to create a backup of your instance and import it into the sandbox yourself. We make a best effort to copy everything Atlassian stores itself with limited exceptions for security, performance, and ease of use.

I'll work with our team to make this more explicit in our documentation as well. Thanks!

Hi @Matt Tse

I can't seem to find this confirmed anywhere so hope you can answer - when we create the sandbox, what is in scope when you talk about data copy?

My assumption is that all the configuration data (e.g. all of our issue types, workflow, screen, fields and associated schemes etc? as well as the user / ticket data).

Otherwise if not, then it means we have to configure everything in sandbox again before we can test on a truly "prod-like" sandbox.

Agreed, Edgar.  That is our primary use-case of a Sandbox too.  We never need any issue data to transfer between the two... just projects, settings, and configurations.

FYI in case it helps you, to achieve that properly today, we make copies of our projects in the same instance so that they can share schemes and diverge when we need to (effectively a PROD and TEST that can be aligned and have pieces of configuration separated when necessary).  But we would potentially want to use a Sandbox as a DEV environment to test new outside integrations properly (might still do that without having the correct configurations).

I would like to have the ability to adjust settings in a project and / or an automation then promote those changes to the production version of the site.  Leaving the data in both projects alone.

@Matt,

Are we able to migrate from Sandbox to Production instance, kind of Promote to the next level?

We are happy to see the sandbox feature.

We do also have the questions about the apps as mentioned in earlier comments.

Also how to easily give existing user access to the sandbox environment, not by inviting them to join. Just granting them access as they already have an account on the current production instance?

Are there options investigated how to move projects between the production and sandbox environment and vice versa? We don't want a full export/import?

Thanks and awaiting your response

Marc

We often use a test environment for large improvement suggestions. Our team requires a proof-of-concept to be approved before the changes can be made in the live instance. It would be very convenient to be able to copy a project from the Sandbox into the live instance once approved. This would eliminate the need to recreate the project in full in our live instance if the proof-of-concept was approved in the Sandbox. 

Hi c045e878e052, could I ask you to send an email to me at mtse@atlassian.com and we'll try to find a time to speak. Apologies for the inconvenience in the timezones! 

What about if Atlassian keeps the sandbox alive for x amount of days (30 for example) and after that it will be cleaned up again...  Extension of that period is possible but only limited amount. And you can only add the amount of people on the sandbox environment as you have on production.

@Matt Tse is there also something more convenient in my timezone? Now I can only book time from 01:00 till 05:00 or 21:00 till 23:00

Thanks c045e878e052 for your feedback. All of the things you've mentioned are things we are looking at. If you'd like to chat about this in detail, feel free to book a time with me here: https://calendly.com/mtse/30min.

Naturally, I'd love to extend this invite to anyone else who may be interested in cloud sandboxes. As mentioned, it is a multistep journey for us and your feedback is critical to ensuring we're informed and prioritizing the right things.

Thanks!

For a sandbox environment there are multiple scenario's that I would like to see.

1. I would expect that its prod like.

With Server we could use a developer licenses to create this. We had a refresh procedure that we had everything synced. (projects, users, apps, data,  etc)

I hope this would be possible when you create a sandbox as well. (so when you own an app you also get that app (for free) on the sandbox)

2. just create a sandbox with a single project with all the data in there to investigate the issues. 

Hi b70783fbfaf4,

Apologies for the delayed update. We made some improvements based on some early feedback so we're expecting to be releasing the sandbox capability to everyone within a week from now. I will post an update on this ticket at the end of this week if that date should change.

And to confirm, yes you will see it in the admin.atlassian.com/o/{organization ID}/products

Cheers,

Matt

Ohai @mtse@atlassian.com - two weeks from Oct 14 was... Oct 28.

Maybe I'm looking in the wrong place, but I don't see a Sandbox option for our instance.

To confirm, I should see it on this page, yes?
https://admin.atlassian.com/o/[OUR INSTANCE ID]/products

Hey charlie.misonne,

Thanks for the question. You can grant non-admins access to a sandbox the same way you would in a regular production site. See https://confluence.atlassian.com/cloud/specify-how-users-get-site-access-744721636.html for more details.

Question: on Managing Sandboxes I read: "You can give site and product admins access to sandboxes the same way you do for products."
Can we also grant users (non-admins) access to a Sandbox?

Hi govindaraju.vayilapalli and 9bf12f312c75,

We have rolled out cloud sandboxes to approximately ~60% of all Premium customers as of today. This will be made available to all Premium customers within the next 2 weeks. 

Cheers,

Matt

When will this be available?

Hi,

When will Sandbox be made available for Jira Premium Customers? Any ETA?

Thanks in advance

Hi David,

When you say Sandbox are you meaning like a test environment? similar to a UAT instance?

Reason I ask is in our organisation we made the choice to create two separate instance - Prod and UAT. Both are identical. The UAT which is a small user access is for me as Admin to test things like config changes, plugins etc. What you mention above is this an extra feature/enviroment included in the one instances being used? In our case eliminate us paying/using a Prod instance and UAT?

Is so that I can see great benefit in this!

Regards,

Anastasia

Hi everyone,

We're actively working on building this capability as part of our Cloud Premium and Cloud Enterprise plans for Jira Software, Jira Service Desk, and Confluence. Thanks for voting and commenting on this issue. Your feedback is incredibly helpful to our team as we work to meet the many different use cases customers have for test environments.

We expect that providing fully capable sandbox environments will be a multi-step journey. We will continue to share updates on this ticket as soon as features are available. Don't hesitate to contact me directly if you have questions at dmeyer@atlassian.com.

Thanks,
Dave Meyer
Group Product Manager, Atlassian