Creating Salesforce Preview Release Scratch Orgs – Error VR-0003

For a couple of releases now we’ve seen that creating Salesforce Scratch Orgs

on a preview release has been throwing us errors. During this last release window though it now seems we at least no what the issue is.

But first a bit of background. Salesforce provide three major releases a year (Winter, Spring, and Summer), and they provide the ability to get preview access to these for customers and partners so they can test their organisations and implementations prior to the release being rolled out to production. This preview access includes Pre-release sandboxes, and once normal sandoxes rollover (usually ~ 1 month before production) then you can also create scratch orgs on the preview release also.

For our work at Caddify, where we have a no-code tool for building mobile Companion Apps, access to these pre-release and preview orgs is a key part of our process to ensure that our product and apps will work as expected on any upcoming Salesforce release. As I have said though for the last two releases the SFDX CLI commands used to create these preview scratch orgs have been failing, specifically with this error;

ERROR running force:org:create: The request to create a scratch org failed with error code: VR-0003.

I was getting this regardless of whether or not I used a CLI flag to request the org or if I used the config file to define the “Preview” state.

Following on from initial conversations with the folk behind the SFDX CLI it seems that the issue lay somewhere internal to Salesforce processes, and after a helpful dialog with Salesforce support the issue was resolved. It seems that some “internal Instance Mapping table” was missing entries. SF support have now added these and my Preview scratch instances are working.

We have added UMEA instances in Spring’23 to Scratch/Sign-Up routing internally our internal Instance Mapping table

I hope knowledge of this issue, and the cause and cure, will be helpful to others who might run into this.

Ionic ion-accordion with Custom ion-icon

ionic ion-accordion with custom icon

I recently had to re-visit some code for our Caddify no-code Mobile Companion App builder and had the opportunity to incorporate Ionic’s ion-accordion component. My use case required customisation of the icon used against the header of each accordion though, and I could not find an example for this. So here one is.

See the Pen
Ionic ion-accordion with Custom ion-icon
by Todd Halfpenny (@toddhalfpenny)
on CodePen.0

This CodePen example shows an ion-accordion-group with three accordions in. The first uses the OOTB icon, the second shows a working custom icon (still an ionicon) with styling, and the third shows what I was initially doing and getting it wrong.

The key to success is to define an ion-icon but to also give it a class of ion-accordion-toggle-icon, without which the out-of-the-box icon is also shown.

A working ion-accordion with a custom icon would look like this;

<ion-accordion value="second">
 <ion-item slot="header" color="light"> 
   <ion-icon
 class="ion-accordion-toggle-icon custom-icon"
 name="logo-ionic"
 slot="end" >
   </ion-icon>
   <ion-label>Second Accordion with custom icon</ion-label>
 </ion-item>
 <div class="ion-padding" slot="content">
 Second Content
 </div>
</ion-accordion>

In this example the custom-icon class is just used to set the color of the icon.

The Salesforce Feature Release Flow, and Developer Previews

I’ve been recently reading about implementing DataWeave in Apex on the Salesforce platform. At the time of writing the feature was in a stage called Developer Preview and I was interested where this fitted into the standard Salesforce Feature Release Flow, in terms of what the next stage would be after Developer Preview (e.g. Beta or GA).

After some conversations (in the Good Day Sir podcast slack community) it turns out that in the next Salesforce release (Spring 23) that DataWeave will be in Beta, so it seems the flow is as follows;

Pilot ➡️ (optional) Devloper Preview ➡️ Beta ➡️ GA