Unleashing the Power of Salesforce Flows: Introducing the Flow Visualiser Extension for VS Code

In the ever-evolving landscape of Salesforce development, efficiency and clarity are key components of success. As developers, we often find ourselves navigating complex flows, seeking ways to enhance our understanding and streamline our workflow. Enter the Salesforce Flow Visualiser extension for Visual Studio Code, a game-changing tool designed to revolutionise the way we interact with and visualise flows right from the heart of our Integrated Development Environment (IDE).

Salesforce Flow Visualiser VS Code Extension

Created by me, this extension provides an intuitive and immersive experience for visualising flows within the familiar environment of Visual Studio Code. Say goodbye to the days of staring blankly at flow XML files, or having to jump into an org, and let’s embark on a journey to discover how the Salesforce Flow Visualiser extension is set to transform your development experience.

A Seamless Integration

Imagine having the ability to gain a holistic view of your Salesforce flows right from your trusted VS Code workspace. The Salesforce Flow Visualiser extension seamlessly integrates into your development environment, providing you with a comprehensive visualisation of your flows without the need for constant context-switching.

With just a few clicks, developers can now unlock a visual representation of their flow logic, making it easier to comprehend complex structures and dependencies. The extension supports a range of flow types, ensuring that whether you are working on screen flows, autolaunched flows, or trigger flows, the Visualiser has you covered.

Understand with Ease

The extension not only offers a visual graphical representation of the Flow logic, but also offers up easy-to-read tabular views of other flow metadata including the defined resources (variable, constants, and formulas) and any start conditions that might have been defined.

The flow diagram can be zoomed in/out (for those rather large flows that we like to pretend we haven’t got) and can be even be saved out to a .png file for inclusion in documentation and even part of our git repository.

Get Started Today!

Ready to elevate your Salesforce development experience? Head over to the Salesforce Flow Visualiser extension on the VS Code Marketplace and embark on a journey of enhanced clarity, efficiency, and productivity. This creation is set to redefine the way we interact with and understand Salesforce flows – don’t miss out on this transformative tool for your development arsenal.

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

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"> 
 class="ion-accordion-toggle-icon custom-icon"
 slot="end" >
   <ion-label>Second Accordion with custom icon</ion-label>
 <div class="ion-padding" slot="content">
 Second Content

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


First Contribution to the SFDX CLI

I’ve been pushing some of the non-technical folk within Caddify to adopt the Salesforce CLI for some time. I find the ability to manage logins to different orgs a huge win and know that others benefit from this greatly also. And it was during one of these conversations with our CEO that he said “now if it could open orgs in different browsers that would be amazing”… and that got me thinking.

See the plugin’s changes in action in this video.

I have created several SFDX CLI plugins that we use internally (mostly managing scratch org creation and setup) and am very familiar with node and TypeScript so saw this as a great opportunity to see if I could implement a change that meant the DX org:open commands could target specific browsers on the user’s computer.

I had read – fairly recently – about the new modularisation of the SFDX CLI project, and was excited by this as I remember hearing from the Salesforce folk years ago when SFDX was initially released, and I asked about whether or not they’d planned to open source it all, and was told that it would be indeed be one of the end goals. Anyway, off I went to find the repository that supported the org namespace. After forking the project and pulling it down to my local development environment I was able to see that made use of the open node package, so in turn I made my way to their npm page to see if anything existed already to support “browser targeting”… and there it was, the project supported optional parameters to achieve just what I was after.

Within less than half an hour I had a working proof of concept on my local machine. I then turned to the Contributing section on the DX repo to see how I could get involved, and from there I created a new issue against the repo, mentioning that I’d love to create a PR to implement the new functionality. Only a short while later I had a response from the team, welcoming my input.

I proceeded to more properly implement the change (you know, with tests and that) and submitted my PR. I was honestly bowled-over by the welcoming, supportive, and helpful responses to my PR from the whole team. I was given guidance on naming, implementation, help messages, and all sorts… and I guarantee that the end code that was merged into the plugin’s repo was many times better than my first iteration. Huge thanks to Shane McLaughlin and the whole team for their support and patience.

This new feature is available in the v1.9.0 release of the plugin-org plugin.

In short, the new functionality is really useful, and I’d love to hear your thoughts on it, and also, if you think that the DX CLI could do with new features or improvements then dive on in and get involved.