2

We are German ISV and SI partners and I noticed that at one of our clients Org we received a Sandbox on cs17.

Earlier we had an full copy sandbox for staging and UAT but now we were able to set up a repeatable ETL Process to maintain a sufficient environment on a free developer sandbox which saves quite an significant amount of the clients budget. The full copy boxes usually spun at cs18.

Neither the client nor we as consultants ever requested a prerelease participation. A few days ago I noticed the winter15 logo in the top.

Now there is a significant issue for a staging use case: you can't install managed packages created on summer14 - which is urgently required for the UAT.

So my questions are:

  • Is there any documentation which sandbox-pods are prerelease and which are not?
  • how can it happen that a sandbox has spun on the prerelease org without being requested as such?
  • how to undo this for the current sandbox, with minimal effort? Moving from pod to pod will still be a couple of hours work wasted doing it via the usual deployment and ETL-process run.
  • I know that salesforce is able to move orgs on their end from pod to pod in case an appropriate business justification is provided, but I hardly doubt it will work between pods of different releases, right? So in best case it would work earliest in three weeks? (oct 17 for cs17 vs cs18 which would be way too late)
  • how can I prevent future sandboxes from spinning unrequested on prerelease pods?
  • where exactly is the switch which dictates new sandboxes of being standard or prerelease?
  • did anyone of you had an issue like this before and how did you solve it?
2
  • 1
    Do I misunderstand or is the issue that the org had the winter 15 preview? SF normally provide information on this prior to the release:blogs.salesforce.com/company/2014/07/… – Girbot Sep 24 '14 at 20:13
  • That's exactly the answer. Was simply bad timing and we will migrate the sandbox for free. Post it as an answer and I will accept it. Thanks! – Uwe Heim Sep 24 '14 at 20:18
2

Pre-release is installed on a per-pod basis. What pod your sandbox is built on close to a pre-release will determine whether or not it is receives the pre-release, and that is in turn determined by the date of the sandbox creation/refresh request date. You do not actively select to participate in a prerelease. You passively select participation in a prerelease based on the date that you create/refresh your sandbox.

The dates are announced well in advance of every pre-release window. Here's the blog post with details for Winter '15: http://blogs.salesforce.com/company/2014/07/salesforcecom-winter-15-sandbox-preview-instructions.html

If your sandbox WAS on cs18 and is now on a preview instance, then presumably its last refresh was prior to August 29. That means that you can now, or will be able to by next Monday September 29, request a refresh, and that will go to a non-preview instance.

1
  • That's it! Thanks. Not the best way to distinct it that I can dream of. But plain and crystal clear. – Uwe Heim Sep 24 '14 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.