Sandbox Management Issues

@davebrown2242, it looks like you’re using the SFDC version of Gainsight. Is that correct?

I’ve done SFDC Sandbox refreshes within both Gainsight Nxt and SFDC versions. The challenge with Gainsight is it doesn’t recognize the new SFDC Sandbox.

What happens in the background when you refresh a SFDC Sanbox is SFDC removes the old instance and creates a brand new instance that matches your Prod instance. If you check the SFDC Org ID for the original sandbox and the new one, you’ll notice they are different. I found this post before in a SFDC forum that helps to explain this but I don’t think this information is listed in their support community:

https://salesforce.stackexchange.com/questions/231425/what-exactly-does-refreshing-sandbox-do

During a refresh, what happens is that Salesforce creates a brand new org that contains all of the objects, fields, page layouts, record types, users, and so on that the source org has so that it is visually identical to the source org. This is referred to as the metadata, or simply the "data about data."

All sandbox copies go through this step. Sandboxes that are based on templates, and partial and full copies, also get some or all of the records copied. Records are simply referred to as "data."

As a concrete example, a custom field is metadata; it describes the properties of the field, such as what type of data it can hold, its maximum length, validation rules, and so on. It is data that does not belong to any specific record, but instead describes how specific records are laid out in the database.

In the activation process, Salesforce then takes the brand new org and marks it as the active version of the org, and the old org is flagged for deletion. At some future point in time (usually about 2 days), the old version of the org is permanently deleted from the database.

With Gainsight SFDC, there are a lot of configurations that are not copied over from Production. Which is why you need to spend 2-3 weeks migrating Prod config back to the new GS SFDC Sandbox. You also need to notify GS Support to point the MDA to the new SFDC sandbox instance. This can be a pretty costly endeavour.

With Gainsight Nxt, it’s a little less painful because GS and SFDC are separate apps. And you can refresh your SFDC sandbox without changing your GS sandbox. All you need to do is reconnect the GS to SFDC. It takes a bit of time but not nearly as much time as rebuilding your GS SFDC sandbox. 

What I have found works best with Gainsight SFDC sandboxes is if you maintain a completely separate SFDC sandbox that is just for managing GS. If you are trying to code in the same sandbox or build SFDC configurations, it can become fairly challenging to manage. And ideally, you don’t have to refresh that org. It’s not ideal but it makes it a bit easier to manage. 

Hope this insights help you on your quest. Many large enterprises have to manage releases and fully test in sandboxes before they can migrated changes to Production. This is become more and more a standard as enterprises start to manage GS as a proper business application supported by IT. 

@davebrown2242 did you get a chance to view the comments by @jean.nairon.  @jean.nairon Thanks for your time here.

Hi @davebrown2242 

Sorry for the issues you faced with Sandbox refresh utility

Currently, one SFDC org can be linked to one GS tenant. On Gainsight Sandbox refresh, the initial understanding was that the Salesforce sandbox will also be refreshed creating a new org id. 

We have identified this issue and will allow for existing Salesforce org to be used on Gainsight Sandbox refresh. This fix is planned for the Dec release.

The name is currently a hyperlink, but the link option is only possible for NXT. I see how this is confusing and will see if we can improve the experience.

Are there any other issues you faced with the utility? Do let me know, I work towards improving your experience.

Thank you for your time

Preethi

Hi @jean.nairon 

Thank you for your inputs.

I had one question

With Gainsight SFDC, there are a lot of configurations that are not copied over from Production. Which is why you need to spend 2-3 weeks migrating Prod config back to the new GS SFDC Sandbox. You also need to notify GS Support to point the MDA to the new SFDC sandbox instance. This can be a pretty costly endeavour.

Ideally, we copy everything from the Production instance to the refreshed sandbox. I could check for the configurations that you noticed that are not copied over and I will have a look at it.

Currently, we only reject the schedules on Sandbox refreshes. Otherwise, we do a full copy.

Thank you once again for your time

Preethi