There could be a situation in your project where UI components in your application need to be defined at run time where Salesforce may or may not have control. We can solve this situation in LWC using CSS or template:if directive.
There is another alternative to the above problem statement, which can be an extremely lightweight framework from Microsoft – Adaptive cards.
In nutshell, Adaptive cards take a JSON input and convert it to HTML UI elements. In this blog post, I would be sharing simple source code to depict how it works.
Its been around 3 years that Salesforce has released new tooling set for developers – Salesforce DX. I’ve been working on Salesforce since days of S-Control around 2008 and have seen extreme changes on platform for better.
To be honest, it’s tough to keep yourself up to date on latest changes that Salesforce has been doing , however there are resources like Medium, Trailhead and many other blogs to help you get up to speed.
I’ve seen days and written code on Force.com IDE, Developer Console, many web based IDE and definitely my heart and love at the moment is with VSCode more importantly Scratch Org & unlocked packages.
Purpose of this blog post is to bust some of myths around using Scratch Org in Salesforce DX however before I start, lets agree on below aspects of project development & management
- Most of projects in Salesforce follows Agile and one of most important aspect of Agile is Devops. Your team should spend enough time & energy in planning Devops strategy like branch structure, tools, processes etc. In my experience , Devops is more about process rather than tool.
- On basis of above point, Source of truth for code & configuration should be your Source Code Management , which in most of cases is Git.
What if your project is not following above 2 principles ? Well, you might already able to relate some of problems like why code is overwritten , no track of which class or fields created by who and why ? Your team spending most of time fixing deployment issue instead of working on actual implementation.
Lets not spend more time and directly jump on some of myths about using scratch org
Myth 1 – Scratch Org is only for packaging & ISV partners
Scratch Org can be used for quick POC or actual implementations. I’ve been using scratch org for each user story which normally takes 1-3 weeks of implementation. Every time, scratch org created, I get liberty to choose which Git branch would be source of truth. Can you refresh dev pro sandbox from Full copy or use 10 days old code that was in production ? There are many other considerations while creating sandbox, you don’t have much control on which metadata would be carried over as starting point.
There are tons of useful SFDX commands available to help automate Salesforce deployment. However one of most important aspect of Salesforce DX is capability of spinning org within few minutes with features enabled like Person Account, Communities etc.
There could be times, where these commands might not be sufficient. I recently cam across such scenario where I wanted to install manage package for quick capability check.
Scanned through documentation, Stack Exchange and spent lots of time figuring out on how to automate package installation. There are many commands available to install second generation package but not manage package itself. Then I came across marty chang’s github repository with instruction.