Thousands of people in organizations like yours use Skuid, from the largest enterprises to the smallest non-profits. Each one has different ways to manage its development process and effectively control change. All of them want to minimize the risk of breakage as they introduce change, and ensure effective testing along the way.
This post draws on our firsthand experience in working with customers of all types and shares how Skuid supports Salesforce development processes, regardless of your organization’s size. In most cases, Skuid can even make things better.
1. The smallest org: a single admin
Even the smallest companies depend on Salesforce for critical business information. They might have extremely limited resources, but still want to control risk and ensure changes are well tested.
Companies like this often have just one admin and probably don’t use a separate sandbox environment. All admin configuration work is done in production (I know this isn’t recommended, but lots of firms work this way. You can’t deploy Apex changes this way, but most small companies aren’t writing Apex anyway.).
Admins may create multiple versions of a Lightning app, keeping one version in production while they make changes to the second version.
Skuid pages also have two very different phases; building the page and then deploying it. This allows you to:
- develop new pages and test them with our Page Preview feature.
- use the page assignments feature to roll out new pages to beta users.
- quickly update page assignments so all profiles use new pages after testing is complete.
2. A larger firm: sandbox development
As a firm grows and its need to maintain data integrity increases, it will do more to protect its production environment. Changes must be made and tested in environments completely separated from production data.
Salesforce supports this separation with sandboxes: various copies of your production environment that you can use for development and testing. Change sets are used to move configuration metadata from a sandbox to the production environment.
(By the way, I know the cool kids are all using SFDX and CI/CD tools these days! Be patient—I’ll talk about that in a minute.)
Skuid can integrate with change sets to move material through a sandbox deployment process from development environments to production.
- Pages can be grouped into page packs which can be moved around as static resources.
- Design systems are also static resources.
There are some parts of a Skuid application that do not deploy well using change sets.
- To initially create them, design systems need a custom setting record. These don’t deploy using change sets.
- Data sources cannot be deployed from org to org today.
You’ll need to create these items manually in the new org when you implement them.
3. The enterprise: distributed development and source control
The contemporary software development world is consolidating on some best practices and common tools for managing change. You’ll often hear them referred to as “CI/CD.” At a high level, these practices include:
- Developers each work in isolated local environments.
- The organization maintains a separate repository of source code.
- Version control tools manage branching and merging of local changes to that repository.
- An automated test suite is run every time code is pushed to the repository and must pass before changes can be merged.
- Automation tooling is used to promote approved changes into test and production environments.
Most of the tools used here are not provided directly by Salesforce, so their configuration will differ widely. In the Salesforce ecosystem, these processes will be championed by Application Life Cycle Management vendors like:
- Copado
- Prodly
- OwnBackup
- AutoRabbit
- GearSet
- Flosum
The core tool that Salesforce provides for connecting to these tools and processes is their CLI tool called SFDX. It allows retrieval and promotion of Salesforce metadata from one org to another, among many other things. Skuid offers an SFDX plugin that allows the inclusion of Skuid pages into deployment scripting and source control.
You can include other pieces of Skuid metadata in SFDX scripts (creating new Custom Setting records for design systems or data sources) generally by calling an Apex snippet that creates these pieces of metadata.
For more information read these Skuid Docs:
The bottom line
If you need help delivering modern enterprise UX in a Salesforce application, Skuid SFX is for you. It’s a managed package you can deploy in VisualForce and Lightning, and on Sales Cloud, Service Cloud, Experience Cloud, and Salesforce Platform.
Skuid SFX integrates with all types of development and change management processes, helping you ensure the delivery of amazing Salesforce Lightning application experiences.
