Al recente evento TrailblazerDX tenutosi a San Francisco il 6/7 Marzo 2024, Salesforce ha presentato Einstein 1 Studio, una suite completa per l’utilizzo della Generative AI sulle Cloud Salesforce.
Vedremo assieme le principali funzionalità con qualche considerazione personalea contorno.
Mulesoft è stato eletto da poco e per la nona volta Leader del mercato delle piattaforme di integrazione in iPaaS secondo Gartner.
Contestualmente è stato eletto il primo Mulesoft Ambassador italiano, e noi abbiamo l’onore di ospitarlo e raccontarci il suo viaggio che ha inizio da una promessa fatta ad Enrico qualche anno fa.
Unitevi a noi per scoprire di quale promessa si tratta.
Link Utili – Trovate tutti i links in questa Folder 😉
In questo episodio proviamo a raccontare il mondo delle certificazioni Salesforce, cercando di identificare le figure professionali e i percorsi di carriera ed esperienza principali.
Aggiungeremo anche qualche considerazione a latere sull’utilità delle certificazioni ma soprattutto sulle varie tipologie e modalità di esecuzione, e qualche tip per una corretta esecuzione dell’esame.
Perché la community Salesforce è fondamentale per il tuo futuro? Scoprilo insieme a Nino Guarnacci nel nuovo episodio del podcast Salesforce Sidekicks.
Nino Guarnacci, Director per il Team di Solution Engineering dedicato al Public Sector in Italia, si unisce a noi per condividere la sua visione sul mondo IT. Parliamo di sviluppo personale, l’importanza dell’Information Technology per le nuove generazioni, e il ruolo della missione nel lavoro che svolgiamo.
Inoltre, ti diamo un assaggio esclusivo della nostra nuova serie del podcast, Salesforce Shots, e anticipazioni sul futuro Salesforce World Tour.
Risposte e spunti di riflessione in un episodio da non perdere! Ascolta su Spotify e condividi con chi è interessato al mondo Salesforce. Ci vediamo al prossimo episodio!
Volete aiutarci a riattivare la Ohana Community d’Italia? Entrate nel workspace Slack e facciamo community!
In questo episodio, approfittando del ruolo ricoperto da Pietro, facciamo due chiacchiere sul ruolo del Project Manager (in generale e nei progetti Salesforce) con qualche consiglio sui tool utilizzati ma anche su quale sia l’approccio giusto per il successo del progetto e delle persone che compongono l’Ohana del progetto. 🏆
Per qualsiasi consiglio commentate qui o nel podcast stesso 💬
Volete aiutarci a riattivare la Ohana Community d’Italia? Entrate nel workspace Slack e facciamo community!
Link alle risorse:
Testi:
Rivoluzione OKR. Scopri il metodo degli obiettivi e risultati chiave, per misurare quello che conta davvero (John Doerr) – https://amzn.to/3OwidEF
in the next release, currently under testing 🤖, an important update will impact the License Verification procedure that you can achieve from the “Options” page on the “PRO” tab, only if you are on paid tier.
You won’t be required to have a synced user on your browser or use Google Authentication to validate your email address anymore, but you’ll simply be required to input your email address and license key to start the validation process: this is a more reliable and easy way to handle your licenses, making the process absolutely smooth! 😎
🚨⚠ Once the release will be live you’ll be required to remove your current license and validate it again ⚠ 🚨
So don’t panic if you’ll temporary see your ORGanizer unlicensed! 😱
NOTE: this update won’t be available to Firefox users at this moment, sorry guys but Firefox has so many problems that its version will stay behind for a while 🦊
📜 The golden rules 👑
You need to validate your license on each browser or browser’s profile you use the license with (if you use Chrome and Edge, you need to validate both, if you use Chrome with many profiles, you need to validate each profile, more or less the same happens now)
The validation process sends a validation email to your licensed email, so you need to have access to your email address and use the provided code to activate your client (you better check your spam folder)
There is a limit on the number of active clients that you can activate with a license (this number depends on the license type, details will be given shortly), but you can deactivate a client to make room for your new client (that’s why you’ll be able to add a Client Name to each client so to point the right client in deactivation)
There is a cooldown for client deactivation (whose duration depends on license type as well) that prevents you from deactivating clients like a crazy 😵
This is how things will change 🤯
The “PRO” tab in the “Options” page (right click on ORGanizer icon and select “Options”) will show new fields:
Client ID (identifies your client, i.e. each browser and browser’s profile you have ORGanizer installed will have its own ID, you cannot change it and please don’t try to do it, it will simply invalidate your client license) and Client Name (as said, you can update this value to clearly identify a client)
Licensing section where you have to set license key and email address as delivered by Gumroad licensing service (your purchase confirmation email, as usual)
When you start a new validation process, you’ll receive the following message:
This is the email you’ll receive (again, check on your SPAM folder):
Now you need to simply copy/paste this code on the activation code on the “Activation Code” field that pops up:
If you reach the max number of active clients you’ll be shown a popup with the details and the list of currently active clients (you decide which one to deactivate, considering the cooldown period):
If you need more details send me a message using the support form.
I want to thank Pietro Piga for involving me in this new (crazy) initiative. 🤪
We have launched a podcast 🎙 titled “Salesforce Sidekicks” (whose temporary home is this blog, click on PODCAST: Salesforce Sidekicks 🇮🇹) with the goal of sharing our (completely off-the-cuff) conversations about the Salesforce world, in an informal 😎, if possible, humorous 🤡, and above all, in Italian. 💙
We would like to attempt to restart ▶ that fantastic “Italia Ohana Community” 🌈🤙 that we tried to kick off some time ago with Nino Guarnacci and the support of Salesforce ☁, aiming to share our passion 💘 for the Salesforce world and, why not, receive feedback and opinions to be shared in other episodes. 🗣
So, we kick off 2024 with the first episode “Salesforce and AI” 🚀 Happy listening! 👂
ℹ️ Di cosa si tratta? / What’s this all about? Salesforce Sidekicks Facciamo una introspezione sulle 25 puntate della prima stagione del podcast e vediamo insieme cosa è accaduto in 8 mesi e quali sono state le nostre impressioni!
ℹ️ Di cosa si tratta? / What’s this all about? Salesforce Sidekicks In questo breve shot, vediamo assieme le tappe salienti della storia di Salesforce, dalla prima Sales Cloud 📈 fino ad arrivare alle recenti grandi acquisizioni come Mulesoft e Slack 💸 Buon ascolto 👂👂
ℹ️ Di cosa si tratta? / What’s this all about? Salesforce Sidekicks Ragazzi prepariamoci per questo evento pazzesco al MiCo di Milano 💙🌍 Quale sarà l’agenda? 📓 La commentiamo nell’episodio! 🗣 Ci vediamo domani! 👀😍 P.S. Ricordatevi di ascoltarci alla YouTube World Tour Radio il giorno 18/06/2024 alle ore 16!!! 👂👂 📅 Link all’evento 📽… Read more: 🇮🇹 Salesforce Sidekicks EPISODE 21: Salesforce Milano World Tour 2024 – Teaser Salesforce Sidekicks
ℹ️ Di cosa si tratta? / What’s this all about? Salesforce Sidekicks Erano vent’anni che le azioni di Salesforce non subivano un drop di questa entità 📉😱 Cerchiamo di dare un contesto a quello che è accaduto 👨🏫 Buon ascolto!
This is a contributor post. For any question, please contact me for more details.
Salesforce DevOps is the amalgamation of software development and IT operations. It aims to speed up the development cycle, enabling continuous, high-quality software delivery.
In Salesforce DevOps, sandboxes and scratch orgs are essential as they provide isolated environments for development, testing, and staging without disrupting the production environment.
By facilitating continuous integration, delivery, and collaboration, these tools align with the core principles of DevOps, streamlining the application lifecycle from development to deployment.
Understanding Salesforce DevOps
Salesforce DevOps assists in developing and deploying Salesforce applications. It enables organizations to deliver applications and services rapidly and efficiently.
By promoting collaboration between developers and operations teams, DevOps practices help reduce the time to move from code committed to successfully running production.
Critical Components of Salesforce DevOps
Continuous Integration and Delivery (CI/CD): This is a critical aspect of Salesforce DevOps, where developers frequently commit code to a shared repository, and automated builds and tests are run. Continuous delivery extends this by automatically deploying code to production after it passes tests, ensuring that code is always in a deployable state.
Automation: In Salesforce DevOps, automation eliminates manual efforts, reduces errors, and speeds up processes. It is used in testing, deployment, and monitoring to ensure consistent and error-free operations.
Infrastructure as Code (IaC): This practice involves managing and provisioning computing infrastructure through machine-readable scripts rather than manual processes. It promotes consistency and scalability in the infrastructure.
Monitoring: Monitoring tools track application performance, usage, errors, and other metrics. This data is essential for maintaining system health and for making informed decisions.
Cultural Changes: Salesforce DevOps is not just about tools and technologies; it also involves a cultural shift. This includes breaking down silos between development and operations teams, fostering collaboration, promoting ownership, and encouraging continuous learning and improvement.
The Salesforce DevOps process typically involves several stages, each with specific workflows:
Plan: This includes defining the requirements, designing the solution, and planning the work.
Code: Developers use Salesforce’s development tools and environments to code the solution. Code is version-controlled, typically using Git.
Build and Test: Code is built into a release and tested. Automated tests are used to verify that the solution works as expected.
Deploy: The release is deployed to a staging environment for further testing and review. Once approved, it’s deployed to the production environment.
Operate: The application is monitored, and any issues are addressed. User feedback is gathered for future improvements.
Learn and Improve: Data from the operation phase and user feedback are used to learn and improve the application and the development process.
Deep Dive into Salesforce Sandboxes
In Salesforce, a sandbox replicates your production environment for testing and development. It provides a space where developers can safely experiment, build, and test changes without affecting the live application.
4 Types of Sandboxes in Salesforce:
Developer sandboxes: Created explicitly for coding and testing purposes, allowing a single developer to work with a copy of the organization’s configuration without any production data.
Developer Pro: Developer Pro sandboxes are similar to Developer sandboxes but provide more storage. They’re designed to handle more extensive development and testing tasks and accommodate larger teams.
Partial Copy: Contain your organization’s metadata and a sample of your production data. They are used for complex testing and training purposes.
Full: Full sandboxes are a complete copy of your production org, including all data and metadata. They are used for performance testing, load testing, and staging.
How to Use Sandboxes in Salesforce Development
Salesforce Sandboxes are used for development, testing, and training without compromising the data and functionality of the production environment.
Here are the steps to use sandboxes in Salesforce development:
Create or refresh a Sandbox: Based on the requirements, create or refresh a sandbox using (Developer, Developer Pro, Partial Copy, or Full).
Develop and Test: Developers make the necessary changes and additions in the sandbox environment, including creating new features, customizing existing ones, or fixing bugs. Once the changes are made, they can perform unit tests to ensure everything works as expected.
User Acceptance Testing (UAT): After the developer’s testing, the business users or QA team can review and test the changes.
Deploy to Production: After successful UAT, the changes can be deployed to the production environment using change sets, Salesforce CLI, or any third-party CI/CD tool.
There are benefits and limitations to using Sandboxes. Knowing them can help your team utilize them to their full potential:
Benefits
Limitations
Different teams can use multiple sandboxes for simultaneous development and testing.
Keeping Sandboxes synchronized with the production environment can be challenging.
Sandboxes can train users and test real-world scenarios without impacting live data.
The number of available sandboxes depends on your Salesforce edition and the licenses you have.
A safe environment to develop and test changes without affecting the live production environment.
Full and Partial Copy sandboxes have specific refresh intervals (29 days and 5 days, respectively), which can limit their usability in specific scenarios.
In-depth Understanding of Salesforce Scratch Orgs
Salesforce Scratch Orgs are temporary environments that can be fully customized to mirror different Salesforce editions with varying features and preferences. As part of Salesforce DX, Scratch Orgs are source-driven, disposable deployments of Salesforce code and metadata.
Setting up and Configuring Scratch Orgs
Setting up a Scratch Org involves these steps:
Install Salesforce CLI: Salesforce Command Line Interface (CLI) is a powerful tool required to create and manage Scratch Orgs.
Authenticate Dev Hub: You must authenticate with your Dev Hub org before creating a Scratch Org. Dev Hub is the central hub that controls creating and provides services for Scratch Orgs.
Create a Scratch Org: After authentication, you can create a Scratch Org using the “sfdx force:org:create” command.
Push Source to Scratch Org: You then push your source into the Scratch Org using the “sfdx force:source:push” command.
Feature Development and Testing: Scratch Orgs are perfect for developing and testing a new feature or bug fix. Each developer can have their own Scratch Org to work independently.
Continuous Integration and Continuous Delivery: Scratch Orgs can be used in CI/CD pipelines where automated tests are run in a Scratch Org to ensure code quality.
Source-Driven Development: One best practice with Scratch Orgs is to always pull changes from the Scratch Org to keep the version control system current.
Dispose after use: As Scratch Orgs are temporary, dispose of them after developing or testing to effectively manage the available Scratch Orgs.
Benefits and Limitations of Scratch Orgs
There are benefits and drawbacks to Scratch Orgs that developers must be aware of.
Benefits
Limitations
Scratch Orgs provide isolated environments that can be tailored to match specific development needs.
Scratch Orgs are temporary, and keeping track of changes if they’re not correctly pulled into source control can be a challenge.
They support a source-driven development model
The number of active Scratch Orgs you can have depends on your Salesforce DX edition and licenses.
Scratch Orgs are ideal for automated testing and continuous integration, which promotes rapid, reliable releases.
The shift from org-based to source-driven development with Scratch Orgs can be a steep learning curve for some developers.
Relative Analysis of Sandboxes and Scratch Orgs
The following analysis overviews the similarities and differences between Sandboxes and Scratch Orgs.
Environment for Testing and Development: Sandboxes and Scratch Orgs are isolated environments used for development and testing. They allow developers to create, modify, and test features without affecting the production environment.
Replication of Production Environment: Sandboxes and Scratch Orgs replicate your production environment. They can be configured to mimic different Salesforce editions with different features and preferences.
Differences between Sandboxes and Scratch Orgs
Choosing between these tools can be complex, but knowing the difference can help make your decision.
Sandboxes
Scratch Orgs
Include production data (based on the sandbox type.)
Scratch Orgs are empty environments that don’t contain any data from your production org.
No expiration
Limited lifespan (maximum of 30 days)
Used for multiple stages of development, including development, testing, staging, and training.
A source-driven development model where changes are tracked in a version control system.
Use Cases for Each: When to Use Sandbox v.s Scratch Org
The following cases state which tool best suits a specific task.
Sandbox: Use Sandboxes for tasks that require persistence and longer-term stability. Sandboxes are ideal for final-stage testing, performance testing, user training, and for staging environments for quality assurance. They are also helpful when you need a copy of your production data for development and testing.
Scratch Org: Use Scratch Orgs for short-term tasks, such as developing new features or testing the impact of changes. They are best suited for individual developers or teams following a source-driven development model. They are also suitable for automating unit tests and implementing continuous integration/delivery pipelines.
Role of Sandboxes and Scratch Orgs in Salesforce DevOps
Continuous Integration (CI) regularly merges code changes into a central repository. Both Sandboxes and Scratch Orgs play a critical role in CI. Developers can use Sandboxes or
Scratch Orgs to create and test features before integrating them into the main codebase. Scratch Orgs are particularly useful for CI because they’re easily made, disposed of, and can be aligned to specific user stories or tasks, enabling isolated testing and reducing potential conflicts.
Role in Continuous Delivery and Continuous Deployment
Continuous Delivery and Continuous Deployment extend CI by automating the release of changes to staging or production environments. Sandboxes can serve as staging environments for these releases, allowing final testing and review before deployment to production.
On the other hand, Scratch Orgs can be incorporated into delivery pipelines to automate the creation of temporary environments for testing. This ensures that code is always in a deployable state, reduces the risk of deployment failures, and speeds up the delivery process.
How Sandboxes and Scratch Orgs Enhance Collaboration and Efficiency
Sandboxes and Scratch Orgs promote a collaborative approach to development. Multiple developers can work simultaneously in different Sandboxes or Scratch Orgs without affecting each other’s work.
Scratch Orgs are tied to source control, allowing easy tracking of changes and facilitating collaboration across distributed teams. The ability to quickly set up, test, and dispose of Scratch Orgs boosts efficiency. With their persistence, Sandboxes allow for extended collaboration over longer project timelines.
Impact on Testing and Quality Assurance
Testing and quality assurance is integral to the software development lifecycle. Sandboxes enable developers to test new features in an environment closely mirroring production. The ability to copy production data (in Full and Partial Copy sandboxes) allows for realistic and robust testing.
Scratch Orgs, being fully configurable, can mimic very specific testing scenarios, providing an environment for fine-grained, accurate tests. By utilizing these tools, developers can catch and fix issues early, ultimately enhancing the quality of the application.
Conclusion
In conclusion, Salesforce Sandboxes, and Scratch Orgs are critical assets in the Salesforce development environment, enabling safe, flexible, and efficient application creation, testing, and deployment.
The Salesforce DevOps landscape, enriched with the complexities and ever-expanding features of Sandboxes, Scratch Orgs, and the Salesforce DX framework, offers a rewarding journey for novice and experienced developers.
Understanding and mastering these tools is pivotal in delivering robust, high-quality applications and fostering continuous learning, growth, and impactful contributions within your organization.
For the #MadeInItaly series where I want to showcase amazing artisanal Italian products from our incredible Italian Ohana, today’s guest post is delivered by Paolo Carrara, software developer, tech enthusiast, scrum master. After a Master’s degree in Software Engineering, he approached Salesforce ecosystem during his early career in a consulting firm and since then he’s been learning, coding, and thinking about new ways to improve his and his team’s work. A huge fan of the Agile movement and an active collaborator of the Italian agile community. You can visit his page (watch out for a hidden easter egg) here.
Many time things don’t go as we planned; we certainly don’t wish so but we must be prepared in such occasions, and when problems happen, there’s one just key factor: time.
That’s why I developed a tool that could help me get to the core problem quicker than whatever I was previously doing.
And that tool is SFDX Lens, a VS Code Extension available for free on the marketplace.
The typical scenario is this: you are happily developing the next new business logic in Salesforce when suddenly you get 3 different issues from 3 different users in your ticketing system, all marked with high priority. Ugh. Now once you’ve read the ticket to understand what’s the problem you have to switch from your code to your QA environment, go to Setup > Debug Logs > New > compile all the required fields .. oh no! you have just created the 10th trace flag for the same user that was in debug last week. Anyway, now you’re ready and can (if possible) replicate the issue, switch back to VS Code and inspect the log
And you have to do it 2 other times.
Or, you can leverage SFDX Lens’s Command SFDX Lens: Debug user from Org. With this command, the extension lets you pick just 3 options:
An Org from the ones configured in your VS Code
An active user to debug
An amount of time from 15, 30 and 60 minutes
That’s it.
The extension will take care of setting a trace flag for that user with the maximum amount of precision allowed for the trace flag (which is more or less FINEST to everything), a process that usually take 1-2 seconds, and then you’re ready to replicate the issue and get the log in VS Code.
>Can you ask your user to replicate the issue himself?
Even better, “let me just activate the extension”, and 2 seconds after there you go, “go ahead”.
>Are you already connected to the QA environment?
Even better, you can skip point 1. With the command SFDX Lens: Debug user which creates a trace flag in the environment you’re connected to.
>Don’t want to search for the command in VSCode?
There’s a neat button for the command SFDX Lens: Debug user just in the activity bar below your code.
You don’t have to worry about trace flag pollution anymore, the extension ensures there will be just one trace flag per user (which is, the minimum required to set a trace flag)
Here’s a demo:
Right, now you have the log in VSCode and it’s a monolith of 7500 rows so.. what’s exactly happening here?
To address this question I often ask myself, I’ve developed a new command, right now in beta : SFDX Lens: Log Analysis (Beta)
This command helps splitting the log into its components, each displayed visually and proportionally to its duration, so now you can focus on a single execution event at a time
This is particularly useful even for performance tuning, now you can see how many times a trigger fires per execution for example.
