#communicate between lwc component

[yadavti]

How to communicate between two lightning web components using Events?

This tutorial describes how to communicate between two lightning web components using events. Events in LWC are built on DOM components. A collection of API’s and objects which is available in every browser. Migrate component events in Aura components to web-standard DOM events in Lightning web components. If you’re familiar with DOM events, you notice the same propagation behavior in Lightning web components. Lightning web components are custom HTML elements built using HTML and modern JavaScript. Lightning web components and Aura components can coexist and interoperate on a page. BISP provide online training for salesforce lightning web components in this training you will learn Why Lightning Web Component, Benefits of Web Component, Communication between Lightning Component and LWC, we are going to learn how we can start working with LWC and all about LWC. In our salesforce training we have adopted Projects based learning in which the candidates engaged with project implementation could be real time and they have to complete by their own along with our expert mentor guidance. In this topic our mentors explain what are lightning component attributes, usage and types. Starting from what is aura attributes and gradually we move towards description. An aura attribute is like a variable that we use in programming language or in Apex class.

[shuvam]

Top Apex Questions in Salesforce Developer Interview for 2023

Salesforce development includes two methods, declarative and programmatic. On the one hand, declarative development includes point-and-click or drag-and-drop features of Salesforce, such as Lightning App Builder, Dynamic Forms and Actions, etc., using which you can create applications without using a single line of code. 

On the other hand, programmatic development includes actual code-based development that includes Apex, Lightning Web Components (LWC), etc. Although most of the Salesforce development can be done using declarative methods, there can be a need for programmatic ones for complex business processes or integration with external apps. So, as a Salesforce Developer, you are expected to have solid knowledge and understanding of both methods. If you are looking forward to becoming one or considering a job change and are curious to find out the kind of questions asked in the interview, then this post is for you. 

Before we dive into the actual questionnaire, it’s worth mentioning that if you are new to Salesforce development, it might be helpful to check out our Salesforce Developer Training. This will give you a strong foundation in the skills and knowledge you need to succeed in this role. Now, let’s take a look at the top Salesforce Developer Interview Questions and Answers:

Use Coupon Code BLOG20 to avail flat 20% discount on saasguru Programs.

What is Salesforce, and what are its key features?

What is the difference between a Salesforce Developer and a Salesforce Administrator?

How does Salesforce use data modeling to manage and organize data?

Elaborate on the various data relationship types in Salesforce and their uses.

How do you use Apex code to create custom functionality in Salesforce?

Can you differentiate between Apex Triggers and Salesforce Flow?

How do you utilize Visualforce to build custom user interfaces in Salesforce?

Can you explain the various types of access controls in Salesforce and the process of their functioning?

How do you use Lightning Web Components to build modern, interactive applications on the Salesforce platform?

Can you provide examples of how you have used Apex code to solve business problems or improve processes in the past?

What is the format of the Salesforce Apex Interview?

The format of an interview for a Salesforce Apex position may vary depending on the employer and the specific job being applied for. However, there are a few elements that are generally included in most developer interviews. These may include technical questions about Apex and other programming languages, problem-solving tasks, and assessments of your overall knowledge and experience. It is important to be prepared for a wide range of questions and to showcase your skills and abilities in order to stand out as a strong candidate.

Here are some of the components that you might encounter in a Salesforce developer interview:

1. Technical Questions 

You can expect to be asked a variety of technical questions about the Apex programming language, including questions about its syntax, data types, and core concepts. You may also be asked to solve coding challenges or write code on a whiteboard or online code editor to demonstrate your skills.

2. Problem-solving Questions 

In addition to technical questions, you can also expect to be asked problem-solving questions that test your ability to think critically and come up with creative solutions to complex challenges. These might involve scenario-based questions asking you to identify and fix problems in existing code or design solutions to meet certain business requirements.

3. Behavioral Questions

These types of questions are meant to gauge your communication skills, teamwork abilities, and your ability to handle difficult situations. Behavioral questions may include prompts about how you have handled challenges in the past, how you work with others, and how you handle stress or difficult situations. It is important to be prepared to answer these types of questions in order to demonstrate your suitability for the role.

4. Questions About Your Experience and Skills

You can also expect to be asked questions about your experience and skills, including any relevant experience you have had with Salesforce or other CRM platforms. When preparing for a Salesforce Apex interview, it is important to be ready to discuss your previous experience and specific projects you have worked on. This may include challenges you faced and successes you achieved in your previous roles. 

The overall goal of the interview is to evaluate your technical skills, problem-solving abilities, and whether you would be a good fit for the company and the role. To succeed in the interview, you should be able to demonstrate your knowledge and skills and convey your passion for the field. By preparing for each of these components, you’ll be well-equipped to handle any questions that come your way and make a strong impression on the interviewer.

World Class Learning Experience from Anywhere

Download the app now and get started with your Cert Prep Journey!

Tips to Prepare for Apex Questions in Salesforce Developer Interview

First and foremost, it’s essential to understand that the interview is not just about testing your technical knowledge of the Salesforce platform. You must demonstrate your problem-solving skills and critical thinking ability during an interview. Here are some steps you can take to prepare:

Familiarize yourself with the company and the role: Prioritizing learning about the company and the position you are interviewing for can help you tailor your questions to the organization’s specific goals and needs.

Review the job description and requirements: Take a careful look at the job description and requirements for the Salesforce Developer role you are interviewing for. 

Review the Apex documentation: The Apex documentation is a comprehensive resource that covers all the key concepts and features of the Apex programming language. Reviewing this documentation will help you better understand the language and be better prepared to answer technical questions.

Practice your coding skills: In addition to having a solid understanding of the Apex language, you’ll also need to demonstrate your coding skills during the interview. Consider practicing your coding skills by working on coding exercises or participating in online coding challenges.

To show your enthusiasm and interest in the company and the role during the interview, consider preparing questions that demonstrate your curiosity and engagement. For example, you might ask about the following:

The company’s culture, values, and mission

The team’s goals and priorities

Any current or upcoming projects you might work on if hired

Opportunities for growth and development within the company

Challenges and successes the team has experienced in the past

Summing Up

Asking questions like these will show the interviewer that you are genuinely interested in the company and the role and that you are eager to be a part of the team. It’s also an excellent opportunity to better understand what it would be like to work at the company and whether it’s the right fit for you.

Use Coupon Code BLOG20 to avail flat 20% discount on saasguru Programs.

By following these steps, you’ll be well-prepared to tackle any questions that come your way during the Salesforce Developer interview and show the interviewer that you’re the right fit for the role.

If you need personal assistance and intense coaching with job assistance, sign up with saasguru now. 

Explore the Salesforce Learning App for Android /Salesforce Learning App for iOS and get certification-ready.

https://www.saasguru.co/salesforce-apex-interview-questions/

[paradisebelieverus]

Salesforce Lightning Services Message is the out-of-the-box functionality that enables the communication between Visualforce and Lightning Components, that including Aura Web Components (AWC) and Lightning Web Components (LWC).

[salesforceblog]

Salesforce LWC, to communicate between components on a single page, we can use the pubsub module. The pubsub service component need to be copied from here  separately before implementing it in our LWC components.

[udemy-gift-coupon-blog]

Introduction - Salesforce Lightning Web Components ##FreeCourse ##UdemyFreeCourses #components #Introduction #Lightning #SalesForce #Web Introduction - Salesforce Lightning Web Components With this practical course, you'll explore the art of working with web components and build a basic layout for the application. You will communicate between components using events, make calls from Lightning components and make components multilingual. This practical course will be your faithful companion and ensure that you make best use of the LWC. Who this course is for: This course is for people interested in learning basic lightning web component concepts by working on small projects 👉 Activate Udemy Coupon 👈 Free Tutorials Udemy Review Real Discount Udemy Free Courses Udemy Coupon Udemy Francais Coupon Udemy gratuit Coursera and Edx ELearningFree Course Free Online Training Udemy Udemy Free Coupons Udemy Free Discount Coupons Udemy Online Course Udemy Online Training 100% FREE Udemy Discount Coupons https://www.couponudemy.com/blog/introduction-salesforce-lightning-web-components/

[wipdeveloper]

LWC - Getting Data with Lightning Data Service

LWC – Getting Data with Lightning Data Service

Hello, I’m Brett with WIPDeveloper.com. So far with our first lightning web component, we have only gotten markup and some communication between the HTML and the JavaScript file and we haven’t done any actual communications with Salesforce. Since we’re building to use our components in Salesforce, we’re going to need to be…

[korshubudemycoursesblog]

Learn Salesforce (Admin + Developer) with LWC Live Project

Introduction: Why Learn Salesforce in 2025?

Salesforce isn't just a buzzword—it's the backbone of CRM systems powering businesses across industries. Whether you’re eyeing a career switch, aiming to boost your tech resume, or already in the ecosystem, learning Salesforce (Admin + Developer) with Lightning Web Components (LWC) and Live Project experience can fast-track your growth.

In today’s digital-first world, companies want Salesforce pros who don’t just know theory—they can build, automate, and solve real business problems. That’s why this course—Learn Salesforce (Admin + Developer) with LWC Live Project—is gaining attention. It offers a perfect mix of foundational concepts, hands-on development, and real-world exposure.

What You’ll Learn in This Course (And Why It Matters)

Let’s break down what makes this course stand out from the crowd.

✅ Salesforce Admin Fundamentals

Before diving into development, you'll master the core essentials:

Creating custom objects, fields, and relationships

Automating processes with Workflow Rules and Flow

Building intuitive Lightning Pages

Managing users, roles, and security

Generating dashboards and reports for decision-making

These are the exact skills Salesforce Admins use daily to help businesses streamline their operations.

✅ Developer Skills You Can Use from Day One

This course bridges the gap between theory and practice. You’ll learn:

Apex programming (triggers, classes, SOQL, and more)

Visualforce basics

Building Lightning Components

Advanced LWC (Lightning Web Components) development

Unlike typical developer tutorials, you won’t just follow along. You’ll build actual components, debug real scenarios, and write scalable code that works.

✅ Lightning Web Components: The Future of Salesforce

If you want to stay relevant, LWC is a must-learn. This course helps you:

Understand how LWC works with core Salesforce data

Build reusable components

Interact with Apex backend using modern JavaScript

Implement events, component communication, and conditional rendering

These are hot skills employers are actively searching for—especially in 2025 and beyond.

The Power of Learning with a Live Project

You can’t call yourself job-ready without hands-on practice.

That’s why this course includes a Live Project, simulating how real-world businesses use Salesforce. You’ll:

Gather requirements like a real consultant

Build a working CRM or service app

Use Git, deployment tools, and testing strategies

Present your work just like in a client meeting

This turns your learning from passive watching to active doing, and makes your resume stand out.

Who Is This Course For?

Here’s the great part: this course is beginner-friendly but powerful enough for intermediates looking to level up.

It’s for:

Freshers or career changers wanting to break into tech

Working professionals looking to pivot into Salesforce roles

Aspiring developers who want to learn Apex + LWC

Admins who want to become full-stack Salesforce professionals

No coding background? You’ll still be able to follow along thanks to the step-by-step breakdowns and real-time guidance.

Why Salesforce Skills Are in Demand in 2025

A few fast facts to show just how hot the Salesforce job market is:

Over 150,000 new job openings expected globally in the Salesforce ecosystem this year

Salesforce Admins and Developers earn $80k–$140k+ USD annually

LWC and Apex skills are now required by 7 out of 10 Salesforce job listings

Remote roles and contract gigs are increasing, giving you flexible career options

With Salesforce constantly evolving, this course gives you an up-to-date skillset that companies are actively hiring for.

Trending Keywords Optimized in This Blog:

Learn Salesforce Admin and Developer

Salesforce LWC project-based course

Salesforce Admin certification training

Apex and Lightning Web Components

Salesforce Live Project training

Hands-on Salesforce course 2025

Real-world Salesforce LWC examples

Salesforce developer job-ready program

Master Salesforce with LWC in 2025

Salesforce for beginners to advanced

These keywords help ensure your blog ranks well for multiple search intents—course seekers, career switchers, and job-hunters.

The Benefits You’ll Walk Away With

Let’s be honest. You’re not here just to learn. You’re here to get results. This course gives you:

🔹 Real Confidence

You’ll go from "I think I get it" to "I know how to build this."

🔹 Portfolio-Ready Projects

Walk away with a live Salesforce app you can show recruiters and hiring managers.

🔹 Practical Experience

Understand how real clients work, think, and change requirements on the fly.

🔹 Certification Preparation

The course aligns with content from:

Salesforce Certified Administrator

Salesforce Platform Developer I

So you can study with purpose and even prep for exams on the side.

🔹 Interview Readiness

You’ll learn to speak confidently about your live project, troubleshoot in real-time, and answer technical questions.

How This Course Is Different from Others

There are tons of Salesforce courses out there. Here’s what makes this one stand out:

Feature

Other Courses

This Course

LWC Training

❌ Often missing or outdated

✅ Fully integrated

Live Project

❌ Simulated only

✅ Real-world use case

Admin + Dev in One

❌ Separate courses

✅ Full-stack in one path

Job Readiness

❌ No practical focus

✅ Build, deploy & present

Support

❌ Pre-recorded only

✅ Guided walkthroughs and community

How to Get Started Today

Whether you're brand new to Salesforce or ready to upskill, you can start learning in minutes:

👉 Sign up for the course: Learn Salesforce (Admin + Developer) with LWC Live Project 👉 Complete each module at your own pace 👉 Practice, build, and test real projects 👉 Join the course community for support 👉 Walk into your next interview with real answers and real skills

Final Thoughts: Your Salesforce Journey Starts Now

At Korshub, we believe that online learning should empower you to take action. This isn’t just another video playlist—it’s a real opportunity to build your skills, your confidence, and your future.

Salesforce is growing. Companies are hiring. And they’re not looking for textbook learners—they’re looking for people who can think, build, and solve problems.

So if you're ready to go from curious to certified, from stuck to skilled, this course is your launchpad.

Start your Salesforce journey with LWC and real-world experience today. You’ve got this. 🚀

[tak4hir0]

Content last updated December 2020. Roadmap corresponds to Summer ’21 projections. Our forward-looking statement applies to roadmap projections. Guide Overview Looking to build forms on the Salesforce Platform? You’ve got multiple options, spanning the entire low-code to pro-code continuum. Representing low-code, Dynamic Forms in Lightning App Builder and Screen Flows in Flow Builder. Hanging out in the middle of the continuum is the ability to extend Screen Flows with LWCs. And representing pro-code is the LWC framework and its ever-growing library of base components. Options are great, but how do you determine which one (or which combination) is the right option? That’s where this doc comes in. Takeaway #1: For basic create/edit forms on a Lightning record page on desktop, use Dynamic Forms. Takeaway #2: Use Flow to build multi-screen forms. If you need to also meet precise UX requirements, layer in LWCs. Takeaway #3: If you need test automation, start with LWC. You can write unit tests for any LWC, regardless of where you plan to embed it. This doc focuses on form-building. You’ll see a similar assessment in Architect’s Guide to Building Record-Triggered Automation on Salesforce. A bit later, we’ll go into depth on these use cases and more, including how to choose between click-based tools and code-based tools (and when to combine them), but here are the major considerations to start with when choosing between these three options. Low Code Pro Code Dynamic Forms1 Screen Flow Screen Flow + LWC LWC Custom Object on Desktop Available Available Available Available Any Object on Desktop Roadmap Available Available Available Dynamic Visibility Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal Cross-Object Not Available Available Available Available Logic or Actions Behind the Form Not Available Available Available Available Dynamic Event Handling Roadmap Not Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Unit Testing Not Available Not Available Available Available 1Dynamic Forms is a feature of Lightning Pages. Lightning Pages are declaratively configured with the Lightning App Builder. As part of Summer ‘20, Dynamic Forms is a non-GA preview feature, and we aim to GA it in Winter ‘21. Available: works fine with basic considerations. Not Ideal: possible but consider an alternative tool Roadmap: estimated to support by Summer ’21 (targeted go-live mid-June 2021). Our forward-looking statement applies to roadmap projections. Not Available: no plans to support in the next twelve months. tl;dr Quickly, let’s elaborate on the takeaways and table above. If Lightning Pages and Dynamic Forms meet your requirements, use them. That means you need a create or edit form for exactly one object on desktop, and you need to control field visibility. Lightning App Builder may be a declarative tool, but this is where it excels. If your requirements aren’t met by those constraints, keep reading. Either Flow or LWC will be a better fit. If you need additional logic or actions behind the form, use Flow or LWC. Both tools offer ways for your solution to do more than create or edit a single record. That “more” might be more advanced logic, such as branching or iteration, and it might be more actions like integrating with external systems, sending emails, or pushing notifications to a user’s mobile app. If you’re building a multi-page form or a wizard, start with Flow. Flow provides a linear navigation framework for orchestrating multiple forms together. You could use LWC to construct your own framework for navigating between forms, but we recommend letting Flow do the hard work for you, so that you can focus on the forms themselves. Got sophisticated UX requirements? Need to dynamically handle more than visibility? Build that stuff in a LWC. If your requirements can be achieved with simple theming and column-based layouts, you can build your forms directly in a low-code builder. For more fine-grained control over your form’s style, you’ll need the ultimate flexibility of LWC. Keep in mind, your choice doesn’t have to be an either/or – you can combine the power of multiple options. For example, if you need both Flow’s built-in navigation system and the full styling flexibility that LWC offers, use them together. What About Page Layouts? You may notice that Page Layouts are missing from our comparison in this document. Moving forward, the recommended way to configure record detail pages is Dynamic Forms in Lightning App Builder using Lightning Pages. It’s been a long time since we enhanced page layouts, and that trend will continue. Here’s why. Dynamic Forms are more flexible – you can place fields and sections wherever you want directly in Lightning App Builder, where you can take advantage of sections, tabs, and accordions. And just like you can do with components on the Lightning page, you can control the visibility of your fields and sections without defining multiple page layouts or record types. With Accordion and Tab components, you can restrict the amount of fields that are displayed initially. Guess what that means? Faster page load times. Layout management is simpler with Lightning Pages, since you can manage everything about your pages from Lightning App Builder – whether that’s the contents of the page or which users have access to the page. It’s no longer necessary to make updates in your page layout to make a change happen in your Lightning page. Not to mention, with the power of component visibility rules, you no longer have to create multiple pages (or page layouts) to control who sees which fields when. And that also means you only need to assign users a Lightning page rather than doing that and also assigning the page layout. As of this non-GA preview, Dynamic Forms has a handful of limitations. We recommend using Dynamic Forms wherever possible, and falling back to Page Layouts only when necessary. For reference, here are the high-level gaps we’re aware of and when we plan to fill them. Timeline for Lightning Pages & Dynamic Forms Support for standard objects Spring '21 Support on the Salesforce mobile app Summer '21 Support in Community record pages Far Future Configure tab visibility Summer '21 Show, hide, and collapse section headers Spring '21 Conditional formatting of fields Summer '21 Conditionally make a field required Summer '21 Conditionally make a field read-only Summer '21 What About Performance? Any performance considerations related to Dynamic Forms, screen flows, and LWC center on what framework those technologies themselves sit on. The ones that are based in LWC (besides, of course, an LWC) are going to outperform ones that are based in Aura. The LWC framework offers better performance because core features are implemented natively in web engines instead of in JavaScript via framework abstractions. If you’re not familiar give this blog post a read. Back in 2019, we did a case study comparing the performance of the same functionality in Aura vs. in LWC. As a result of converting DreamHouse from Aura to LWC, not only was the development experience far more aligned with current web front-end development standards and patterns, but the performance gains are significant. Lab measurements showed gains in the range of 2.4 percent to 24.7 percent for cold cache and gains in the range of 31.83 percent to 63.32 percent for warm cache on the same two pages. Now, which framework are our form technologies using? In other words, which form technologies benefit from this superior performance? Dynamic Forms, which is integrated in the Lightning pages metadata, are built on a brand new foundation that uses the LWC stack, which will enable us to implement some long-requested features. Building everything from ground up takes time, which is why Dynamic Forms currently has some limitations – like standard object and mobile experience support. Screen flows are built on a mixed stack. Today, the flow runtime client uses an Aura container application, and most of the individual components you can display in a flow screen are Aura. A few have been converted to LWC so far: Text, Checkbox, Date, and DateTime. The Flow team is committed to converting the flow runtime client to use 100% LWC components instead of Aura, with the exception of customer-created (that’s you!) Aura components. We can’t convert those for you, but there is an excellent Trailhead module that explains how to do so: Lightning Web Components for Aura Developers. It goes without saying: if you’re thinking about building a custom component for a screen flow or any other container, always go LWC. LWC is built on ... LWC of course. This is a freebie. 🤓 Navigating the Low-Code to Pro-Code Continuum Most of this doc focuses on helping you understand what functionality and level of customization is possible with Dynamic Forms, screen flows, and LWC. LWC is the most customizable and robust option for building a form, but it has the fewest guardrails in place. It’s up to you to build a component in a way that ensures security and scalability. Dynamic Forms is the least flexible, but there are far fewer opportunities for missteps. Flow sits somewhere in the middle – more powerful than Dynamic Forms but not quite at the level of LWC. By the same token, it has fewer guardrails than Dynamic Forms but is harder to break than custom code. If multiple tools fit the bill, the decision comes down to which tool is the right one for your team. Introducing the Salesforce Architect Decision Guides on the Salesforce Architects blog introduces some aspects to consider when making that decision. We won’t go into the details of each of those aspects here, but what we will do is interpret them for the specific tools this doc is assessing. Specialized Skills: What percentage of your team is already an expert in the tools you’re comparing? How many makers are well-versed and familiar with LWC or Javascript? How about makers who are experts in Flow Builder or have expressed an interest in dipping their toes? Generally speaking, Dynamic Forms and Flow are more attainable for a broader population of makers. Dynamic Forms is the most declarative form-building tool and will always be easier to learn than Flow. That said, the Flow team is committed to getting that bar as low as possible. Delegation of Delivery: Just because part of your requirements require LWC doesn’t mean the entire solution needs to be built with LWC. Consider how you can build your solution modularly, such that the bits that require LWC are coded, and the bits that don’t are built in a low-code solution. Doing so maximizes the impact of a diverse team and ensures that makers are solving problems appropriate for their specialization. Maintainability & Long-Term Ownership: If you anticipate this form will be maintained in the future by pro-code makers and your current team is highly familiar with Javascript frameworks, it makes sense to choose LWC as your solution of choice. If, on the other hand, low-code makers will be responsible for maintaining the form, consider how you can make the solution as configurable as possible for that audience. Diving Deeper As promised, we’re diving deep into a variety of comparison points and functional differences between Dynamic Forms, Screen Flows, Screen Flows with embedded LWCs, and the LWC framework itself. Available: works fine with basic considerations. Not Ideal: possible but consider an alternative tool. Requires ...: possible with help, such as from Apex. Roadmap: estimated to support by Summer ’21 (targeted go-live mid-June 2021). Our forward-looking statement applies to roadmap projections. Not Available: no plans to support in the next twelve months. Low Code Pro Code Dynamic Forms1 Screen Flow Screen Flow + LWC LWC Object Scope Single Object Available (Custom Objects) Available Available Available Cross-Object Not Available Available Available Available Object-Agnostic Not Available Available Available Available Form Scope Single-Screen Form Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal Location Lightning Record Page Available Available Available Available Lightning Home or App Page Not Available Available Available Available Communities Not Available Available Available Available Embedded Snap-Ins Not Available Available Available Available Utility Bar Not Available Available Available Available Object-Specific Action Not Available Available Available Roadmap Global Action Not Available Not Available Not Available Roadmap Salesforce Mobile App Not Available Available Available Available Field Service Mobile Not Available Available (Object-specific action) Not Available Roadmap Mobile SDK Not Available Not Available Not Available Roadmap External Sites & Apps Not Available Available Available Available Custom LWC Not Available Not Available Not Available Available Controller Logic & Actions Not Available Available Available Available Operation Within One Transaction Not Available Available Available Requires Apex Operate Across Multiple Transactions Not Available Available Available Available Integration Not Available Available Available Requires Apex Modular Design & Reuse Not Available Available Available Available Validation Respect System-Level Validation Available Available Available Available Custom Field Validation Specific to this Form Available Available Available Available Custom Form-Level Validation Not Available Not Available Available Available Security Elevate User Permissions Not Available Available Available Requires Apex Restrict Who Can Access Available Available Available Available Restrict Allowed Locations Not Available Not Available Not Available Available Interaction Design Conditional Visibility Available Available Available Available Conditional Requiredness Roadmap Not Available Available Available Conditional Formatting Roadmap Not Available Available Available Conditional Read-Only State Roadmap Not Available Available Available Standard Event Handling (such as onblur, onfocus) Not Available Not Available Available Available Custom Event Handling Not Available Not Available Available Available Styling Org and Community Themes Available Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Layout 2 Columns Available Available Available Available 4 Columns Roadmap Roadmap Available Available Beyond 4 Columns Roadmap Not Available Available Available Tab and Accordian Containers Available Not Available Available Available Translation Labels Entered in the Builder Roadmap Available Available* Not Available Labels in the Code Not Available Not Available Available Available UI Test Automation Unit Tests Not Available Not Available Available Available End-to-End Automation Requires Code Requires Code Requires Code Available Metrics Page Views Available Available Available Available* Time Spent on Form Not Available Not Available Available Requires Apex Time Form Completion Not Available Not Available Available Requires Apex Track Success Rate Not Available Not Available Available Requires Apex 1Dynamic Forms is a feature of Lightning Pages. Lightning Pages are declaratively configured with the Lightning App Builder. As part of Summer ‘20, Dynamic Forms is a non-GA preview feature, and we aim to GA it in Winter ‘21. Object Impact What objects will the form operate against? Just one object? Multiple objects? Dynamic Forms Screen Flow Screen Flow + LWC LWC Single Object Available (Custom Objects) Available Available Available Cross-Object Not Available Available Available Available Object-Agnostic Not Available Available Available Available If your form operates against a single Salesforce object, any of the tools we’re comparing will work. Things get a little more complicated with cross-object or object-agnostic forms. By object-agnostic, we mean inputs that don’t map to any Salesforce object. Perhaps your form represents a data structure that you’ll send to an external service, like Stripe or Docusign. Or perhaps you’re using several inputs in your form to calculate a value, and then committing that value to the database. For both cross-object and object-agnostic forms, Flow is a solid option. The components available in flow screens are agnostic by nature, so you can choose what to do with that data behind the scenes. For example, use the data entered in one form to create multiple records behind the scenes, or use the data to perform other actions like generating Chatter posts, sending emails, or connecting to external services. For simple cases, using existing LWC components like lightning-record-form can be a simple way to lower code needed to provide a robust solution. However, for scenarios where multiple objects are involved, Flow provides cohesive control for all objects and removes complexities of developers having to traverse complex relationships and dependencies. Form Scope Do you need a single screen, or will the user need to navigate between multiple screens to complete a task? Dynamic Forms Screen Flow Screen Flow + LWC LWC Single-Screen Form Available Available Available Available Multi-Screen Form Not Available Available Available Not Ideal If you can get all of your user’s inputs from a single-screen form, start with Dynamic Forms. If you need more functionality than what Dynamic Forms offers, the choice between Flow and LWC depends on a few other questions. What skills does your team have? For a more admin-heavy organization, we recommend starting with Flow. For a more developer-heavy organization, start with LWC. Is it OK to display a navigation bar at the bottom of your form? If the flow navigation bar is undesirable UX, swing towards LWC. What needs to happen behind the form? If you need the behavior to be configurable by an admin, build a flow. Otherwise, build a LWC. If you choose Flow, you may need to build a LWC anyway to achieve the right UX. If you’re already building a LWC to style your form correctly, consider whether embedding that component in a flow is overkill. If, on the other hand, your solution looks like a wizard, where the user navigates between multiple screens, think Flow. Flows come with a built-in navigation model, so you don’t have to build and maintain that yourself. The navigation is linear in nature, with forward-moving actions (Next and Finish), backward-moving actions (Previous), and a mechanism for saving the form for later (Pause). You can also build a form with non-linear navigation if it suits your purposes. For a great example of that, check out this Salesforce Labs package: Digital Store Audit. Location Where do you want to embed the form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Lightning Record Page Available (Desktop) Available Available Available Lightning Home or App Page Not Available Available Available Available Communities Not Available Available Available Available Embedded Snap-Ins Not Available Available Available Available Utility Bar Not Available Available Available Available Object-Specific Action Not Available Available Available Roadmap Global Action Not Available Not Available Not Available Roadmap Salesforce Mobile App1 Not Available Available Available Available Field Service Mobile Not Available Available (Object-Specific Action) Not Available Roadmap Mobile SDK Not Available Not Available Not Available Roadmap External Sites & Apps Not Available Available Available Available Custom LWC Not Available Not Available Not Available Available 1 Flows and LWCs are supported in the Salesforce mobile app, but the Salesforce mobile app doesn’t support all the ways you can embed flows and LWCs. For example, object-specific actions are supported in mobile, but utility bar items are not. Since they require a record context, Dynamic Forms are supported only in Lightning Record pages. However, Dynamic Forms aren’t supported in Lightning Community pages. This limitation is in place because Lightning communities don’t use the underlying framework that Dynamic Forms depends on: Lightning Pages. We are definitely evaluating this as we do often hear feedback of wanting Dynamic Forms in Communities. Roadmap! Today, Dynamic Forms are supported only for custom objects on desktop, but Salesforce is actively working on supporting them for standard objects and the Salesforce mobile app as well. You can build flows that require a record context or flows that work globally. As such, you can embed flows in a variety of locations. For the record-contextual flows, that might be a Lightning record page, a Community record page, an object-specific action, or an Actions & Recommendations deployment. For the global flow, that might be the utility bar, other Lightning or Community pages, a snap-in, or an external application. Flows aren’t currently supported as global actions, but as a workaround you can wrap the flow in an Aura component. LWC supports a high degree of reusability, since you are creating components and able to associate with targets via metadata across Salesforce, Communities, and even in Open Source Projects. LWC components can also be embedded inside of your own website via Lightning Out. LWCs aren’t currently supported as quick actions (object-specific or global), but – much like you can with flows – as a workaround you can wrap the LWC in an Aura component. None of the form technologies covered in this doc are officially supported in Mobile SDK templates today. If Mobile SDK is paramount to your use case, you’re better off building your form in natively in your mobile application or building a Visualforce page. Roadmap! The Mobile SDK team is actively working on supporting LWCs within Visualforce pages. Controller What actions or logic do you want to be performed behind the scenes? Dynamic Forms Screen Flow Screen Flow + LWC LWC Logic & Actions Not Available Available Available Available Operate Within One Transaction Not Available Available Available Requires Apex Operate Across Multiple Transactions Not Available Available Available Available Integration Not Available Available Available Requires Apex Modular Design & Reuse Not Available Available Available Available Dynamic Forms is perfect if you need to use the values in your form to create or update a record. For anything beyond that capability, you’ll need to leverage Flow or LWC. That might be a layer of decisioning or iteration, or you might generate Chatter posts or emails using the inputs from the form. Flow offers standard actions for posting to Chatter, sending email, and interacting with Quip documents, so you don’t have to write code for the same operations. LWC offers rich interactions with single records and related objects through the use of wire adapters that interact with UI API. LWC can also interact with multiple records when using the wire for getListUi. Both Flow and LWC integrate with Apex, so you can easily close the gaps in whichever solution you choose. For example, if you require filtering records from an LWC you can always use the wire adapter for Apex to create complex SOQL queries. If you’re swayed by the click-based story, consider Flow as a viable alternative to an Apex controller for your server-side needs. A secondary question to answer here about the actions is whether you want to immediately commit them, or defer them to a particular part of your form. This is especially relevant if you’re in a multi-page form. Flow makes it easy to combine inputs from multiple forms (flow screens) and use them much later in the wizard (flow) to perform some operations. In fact, we recommend designing flows in just that way – perform actions at the end – in case the user bounces back and forth between screens, thereby changing their answers. Do you need to control which operations occur in which transaction? Transactions and governor limits are a way of life on the Salesforce Platform. If your use case is fairly simple, it may not be as important to control what transaction a particular operation occurs in. However, there are a few use cases where you might want to combine multiple operations into a single transaction rather than performing those across multiple transactions. Some examples: To Rollback Or Not to Rollback: That is the question. Let’s say your form creates multiple records behind the scenes. If the third record fails to be created, should the first two records be rolled back? If each of your actions are independent of each other, feel free to execute them in separate transactions. If they’re dependent, however, and you want the failure of one to also rollback the others, implement them in a single transaction. Downstream Impact on Governor Limits: Especially when your form creates or updates a record, consider what the downstream implications of that operation are. What processes, workflow rules, flow triggers, Apex triggers, or other items in the save order are going to fire based on this record change? And how do those collective changes impact the governor limits being consumed in that transaction? If a particular record change will result in a lot of downstream changes that impact your limits, consider isolating that record change into its own transaction. Batch Processing: Even in a UI context, you may need to batch multiple updates together. Let’s say your multi-screen form iterates over a large group of records. Rather than committing a record update after each screen, wait until you’ve collected the updates for all of the records and then submit one request to update all the records. When you use a Dynamic Form to create or edit a record, you’re only ever performing one operation, and that operation is always the start of a net-new transaction. When building a screen flow, you have significant control over what happens in a given transaction. Screens and Local Actions act as boundaries between transactions. Here’s a high-level summary of how transactions are managed in the screen flow architecture. The end user interacts with a screen, and then clicks Next. The client posts a request to the API with the inputs. The API receives the request, and a transaction and database connection are opened. The API then then calls the Flow engine to invoke the request. The Flow engine takes over and follows the appropriate path in the flow definition – until it hits a Screen or Local Action node. The engine then returns information about that node to the API. The API creates a response object that contains the details of the next screen to render, and returns that object to the client. At this point, database changes are committed (cue the save order execution), and the database connection and transaction are closed. The client uses the API response to render the next screen for the user to interact with. Rinse and repeat. In other words, screens “break” transactions. When that happens, any pending actions or DML are committed, the prior transaction is closed, and a new transaction is started. The right design – which operations you group into a given transaction – is your call. On the left, you can see a flow that collects inputs across multiple screens, and then performs several actions in one transaction. The flow on the right performs each operation in a separate transaction. For more details, check out these resources on Salesforce Help: Flows in Transactions and Flow Bulkification in Transactions. Your ability to control the transaction from an LWC comes down to the underlying services that LWC is using to perform its operations. If you’re using the lightning-record-form base component, the underlying operation (creating or updating the record) happen in a standalone transaction as soon as the form is submitted. In general, these rules apply: Each UI API call is isolated into its own transaction. If you need to perform multiple operations within a single transaction, send the inputs off to a server-side technology like an Apex controller or a flow. The regular transaction rules for that technology apply. Do you need to integrate with external systems? Both Flow and LWC support API integrations with an assist from Apex. Additionally, Flow supports External Services – which enables you to declaratively generate process integration building blocks. Anyone can integrate with legacy systems or web apps, as long as those services can be described with an OpenAPI-compliant schema. For example, you can generate actions for integrating with Slack or Google Sheets, and then configure your flow to post to a Slack channel or add a row to a particular Google Sheet. The end-to-end solution involves touching zero lines of code. Regardless of whether you do so with custom Apex or an External Service, a callout is a callout. Here’s what you need to know. A callout can take a long time. When a callout is executed synchronously, it's performed while a database transaction is open. Salesforce doesn't let you keep a database transaction open if you've got pending database operations. The main limitation to keep in mind is the danger of what we call a dirty transaction, where you perform a create, update, or delete operation and then, in the same transaction, execute a callout. This pattern isn’t allowed because of consideration #3, which of course exists because of considerations #1 and #2. You can work around this limitation by breaking the transaction. As we mentioned above, screens and local actions both reintroduce the browser context, which breaks the transaction. Use a Screen to break a transaction if it makes sense to display a new form to the user prior to making the external callout. If it doesn’t, we recommend a no-op local action, like this one available to install from UnofficialSF. Not familiar with local actions? They’re Aura components with no markup; the flow executes the invoke() method in the component’s Javascript controller. They’re the only actions available in Flow that aren’t performed server-side. In addition to being useful for breaking transactions, local actions are great for performing browser-level actions like firing toasts or force navigating the user. On the left is a flow that updates a record, then uses a callout to request a list of Slack channels. This flow fails at runtime, because the callout occurs in the same transaction after a pending database operation (the record update). To the right is a flow that updates a record, executes a no-op local action, and then uses a callout to request a list of Slack channels. This flow succeeds at runtime, because the callout is performed in a separate transaction from the record update. The impact of callouts on the transaction is less complicated with LWC. Generally speaking, you’ll perform your data operations using the Lightning Data Service, and then use an Apex controller to make the external callout. This design protects you from dirty transactions, since the LDS call is isolated in its own transaction separate from the Apex callout. What are your requirements for reusability and modularity? Dynamic Forms doesn’t support reuse. Each Dynamic Form is tied to a specific Lightning record page for a specific object. Though you can assign that Lightning record page to multiple apps, profiles, and so on. Much like you can write libraries, utilities, and components that are intended to be used across multiple other components, you can apply similar design patterns when creating flows with the power of subflows. Save your flows in smaller, more modular buckets, and then call them from other flows by using the Subflow element. If your design calls for it, you can build a flow that both stands on its own and is useful as a subflow of another one. Flow and LWCs can both be built for reuse, such that you can embed them in a variety of locations including external sites and Lightning Out applications. Validation What are your validation requirements? Dynamic Forms Screen Flow Screen Flow + LWC LWC Respect System-Level Validation Available Available Available Available All technologies that attempt to create or update a record adhere to system-level validation – whether those are classic validation rules or custom validation built into an Apex trigger. No matter what technology you use to perform a record change, every change goes through the save order. That means in addition to validation rules, the record change is processed by any number of before- or after-save flows, before or after triggers, escalation rules, assignment rules, and more. If you haven’t already, now’s a good time to bookmark and familiarize yourself with the Order of Execution. Inputs on a flow screen are by nature unbound, so the screen itself doesn’t natively adhere to system-level validation associated with a particular object. Whatever values you use to Create or Update records, however, are processed by the save order, which means they pass through the object’s system-level validation. Dynamic Forms Screen Flow Screen Flow + LWC LWC Custom Field-Level Validation Specific to this Form Available* Available Available Available Custom Form-Level Validation Not Available Not Available Available Available Just like page layouts, Dynamic Forms let you set requiredness and read-only state at the page level. However, you can’t override system-level settings. Flow provides flexibility for customizing validation on a form’s inputs. While some checks are performed in the client (like flagging missing required fields or incompatible values), none of the client-side validation blocks the user from trying to navigate. The real stuff happens on the server. When a user clicks Next, Flow sends the inputs to the server for validation. If any inputs are returned as invalid, navigation is blocked and the appropriate error is displayed. The server validates the inputs by checking: The input’s requiredness setting, or whether the entered value is compatible with the underlying data type. Custom validation on that input: Several standard components (Checkbox, Currency, Date, Date/Time, Long Text Area, Number, Password, and Text) support custom validation on a per-screen basis. Supply a Boolean formula expression and an error message to display when the formula expression isn’t met. Custom validation on the underlying component: If you’re building a custom LWC for a flow, add your own validation code to the validate() method. On the LWC side, most base components perform their own client-side validations. For example, lightning-record-form respects system-level requiredness, but not page-level requiredness. For your custom components, you can build your own validation mechanisms. Security What are your security requirements? Should the form check the user’s access before performing certain operations? (Especially important when building for guest users) Dynamic Forms Screen Flow Screen Flow + LWC LWC Elevate User Permissions Not Available Available* Available Requires Apex Do your users have field-level security to see this field? Do they have permission to create records for this object? What about access to this specific record, based on your org’s sharing rules? When something runs in user context, we enforce those access checks. Users can run a case update form only if they have the ability to update cases, the appropriate field-level security, and access to the record in question. But what if you don’t want to grant users a particular permission? What if you want users to be able to perform a particular operation when they're using your form, but not through any other form or interaction? That’s where system context comes in. System context is a way to elevate the running user’s permissions for the duration of the session, so that the user doesn’t need Update access to the Case object to successfully complete your case update form. This is especially useful for unauthenticated communities. Instead of granting guest users dangerous abilities, set your form to run in system context. Of course, system context is a double-edged sword and you should use it only when necessary. When a form runs in system context, every single CRUD operation bypasses object- and field-level security & sharing – not just the specific operation you care about. Note that system context has no bearing on who Salesforce considers the actor – the name you see in the Last Modified By field. For each operation that your form performs, such as the case update, the actor is the running user even if the form runs in a different context. Dynamic Forms always run in user context, and there’s no way to override this behavior. Screen flows run in user context by default, but you can set them to run in system context. It’s your choice whether the flow should grant access to all data or if it should still enforce record-level access like sharing. If you embed a Lightning component in a flow that runs in system context, the flow doesn’t override the component’s context. If you need to bypass user access checks, we recommend using the flow to perform those operations and pass the appropriate data into or out of the Lightning component. If your flow calls Apex actions, there are some more nuances to understand. If the Apex class is set to inherited sharing, it runs in system context with sharing no matter what the flow is set to. If the class has no explicit sharing declaration, it runs in system context without sharing no matter what the flow is set to. If the class is set to with sharing or without sharing, it does so and overrides the flow's context. Best practices: Leave the flow to run in its default context unless you need to elevate the running user’s access for a specific operation. If the flow performs a variety of operations and not all of them require elevated access, use a subflow to isolate the operations that should run in system context. LWCs run in user context by default, but you can override that in an Apex controller. Operations performed through the UI API are run in user context. Operations performed through an Apex controller depend on that class. To perform those operations in system mode, set the Apex class to with sharing or without sharing. Do you want to control who can access the form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Restrict Who Can Access Available Available Available Available To address this requirement, often you can look to the container you’re embedding your form in. For example, you can assign Lightning pages to be available for particular apps, record types, or profiles. If particular inputs in your form are sensitive, use visibility rules to further control what is displayed to who – this feature applies to both Dynamic Forms and screen flows. You can restrict a flow to particular profiles or permission sets, much like you can an Apex class or Visualforce page. By default, flows are unrestricted, which means that any user with the Run Flows user permission can run it. Best Practices: If you’re exposing a flow to guest users, grant the guest user profile access to only the flows they need. You can add Run Flows to the guest user profile but we consider that a dangerous practice. Be especially careful with flows that operate in system context. We highly recommend you restrict those flows to a particular set of users, since they have fewer checks and balances in place to protect your data. For LWCs, you can check the running user’s permission assignments to confirm if they have a particular standard or custom permission. Directly from Javascript, you can import Salesforce permissions from the @salesforce/userPermission and @salesforce/customPermission scoped modules. Or you can use Apex to check the same. Do you want to control where the form can be embedded? Dynamic Forms Screen Flow Screen Flow + LWC LWC Restrict Allowed Locations Not Available Not Available Not Available Available Once a screen flow is activated, it’s available in all the locations that screen flows are supported, regardless of whether you intended it to be available everywhere or not. That said, Flow Builder supports multiple types of flows that have screens. The bread-and-butter type is Screen Flow, but there are a few other specialized types that are restricted to specific locations. For example, only Field Service Mobile Flows are supported in ... you guessed it, the Field Service mobile app. The same story goes for Contact Request Flows, which are supported only in communities. Regardless of the flow type, the individual making the flow has no control over where the flow can be embedded. The flow will be available in every location supported for that flow type. LWCs, on the other hand, are available in a given location only when it’s been added as a valid target. So you can make a component available on Record pages and not available as a utility bar item. Interaction Design Should your form react dynamically to interactions or conditions? Static forms are a thing of the past. Today, it’s all about dynamically updating the form with the right properties and values for this user, this time, this place. Let’s talk about what’s possible in this vein for Salesforce’s form-building tools. Dynamic Forms Screen Flow Screen Flow + LWC LWC Conditional Visibility Available Available Available Available Conditional Requiredness Roadmap Not Available Available Available Conditional Formatting Roadmap Not Available Available Available Conditional Read-only State Roadmap Not Available Available Available Visibility can be dynamically controlled in all three tools. Both Dynamic Forms and Flow Builder address this with features called Component Visibility. With this, you can declaratively show or hide fields based on other values on the form or whether the user is on a mobile device or not. With Dynamic Forms, you’re limited to fields on the associated object and there are some limitations on the supported field types and operators. With Flow, you can base a visibility rule on other inputs on the screen, as well as other resources populated earlier in the flow like formulas or values from other records. Device-based Rules: It’s not obvious from the get-go, but you can use a formula to show or hide a particular field when the user is on a mobile device. Write a flow formula that checks the value of the $User.UIThemeDisplayed global variable. If the value is Theme4t, the user is on the Salesforce mobile app. Evaluating Other Resources: Manual variable and formula references are evaluated only on the server. So whatever value that resource has when the screen first renders is the value it will have until you navigate to another screen. On navigation, the flow runtime submits a request to the flow engine (the server) and gets back the latest values of the manual variables and formulas. If you expect your visibility rule to update as the user passes through a single screen (aka onblur), make sure that you’re referencing only values from the other components on the screen. If you need to dynamically control any other properties, such as whether a field is required or read-only, your best bet in the short term is LWC, where you get full control. That’s especially true if you have bespoke requirements for what to do onblur or onclick. Roadmap! For Lightning Pages, which includes Dynamic Forms, we anticipate enabling conditional requiredness, conditional formatting, and conditionally setting an input to read-only in the next 12 months. Dynamic Forms Screen Flow Screen Flow + LWC LWC Standard Event Handling (such as `onblur`, `onfocus`) Not Available Not Available Available Available Custom Event Handling Not Available Not Available Available Available Now for custom events. If some of your inputs or the entire form need to communicate with something else in the page, LWC is your only option. For more details, check out Communicate with Events and Communicate Across the DOM in the Lightning Components Dev Guide. Styling How sophisticated is your desired styling and CSS? Dynamic Forms Screen Flow Screen Flow + LWC LWC Org and Community Themes Available Available Available Available Pixel-Perfect Styling Not Available Not Available Available Available Both Dynamic Forms and flows respect declarative theming features. If you need control beyond what Salesforce Themes or Community Branding Sets support, you need the wide open spaces of LWC. Reminder: You can embed Lightning components in flows. So if you need pixel-perfect control over the look-and-feel of your form but want to use the other benefits of flows, like the navigation model, you can have the best of both worlds. Layout What are the layout requirements for your form? Dynamic Forms Screen Flow Screen Flow + LWC LWC 2 Columns Available Available Available Available 4 Columns Roadmap Roadmap Available Available Beyond 4 Columns Roadmap Not Available Available Available Tab and Accordion Containers Available Not Available Available Available Dynamic Forms supports two-column layouts. Dynamic Forms can be broken up into individual sections with fields. These sections can be placed in components such as tabs and accordions to create easy to use and organized layouts. Flows can be rendered using a two-column layout. This feature is supported only when you add a flow to a Lightning or Community page, or when you use a direct flow URL, such as for a custom button. Due to our near-term roadmap, we recommend not using this feature. Roadmap! Salesforce is actively working on multi-column screens for Flow Builder. When this feature ships, you’ll be able to declarative configure screens with up to 4 columns. With LWC, you can use lightning-record-[edit|view]-form and the supporting lightning-[input|output]-field to control layout. The only layout restrictions are those from HTML/CSS. lightning-record-form respects the section configuration in the associated page layout – if a section is two-column in the page layout, it’s two-column in this component. Translation Does your form need to be localized to other languages? Dynamic Forms Screen Flow Screen Flow + LWC LWC Labels Entered in the Builder Roadmap Available Available* Not Available Labels in the Code Not Available Not Available Available Available If you’ve localized your custom fields, those translated labels are respected on Dynamic Forms. However, localization isn’t supported for labels that you add to components in the same Lightning page. For example, the label for a tab in the Tabs component. Roadmap! Salesforce is actively working on filling this gap. Soon, you’ll be able to reference Custom Labels for any string or rich text property in Lightning App Builder, such as to localize a custom Tab or Accordion label or the title you added to a Report component. With the power of Translation Workbench, Flow supports translation of user-facing labels for some, but not all, of the available screen components. For the following screen components, you can localize the label, help text, and error message: Text, Long Text Area, Number, Currency, Checkbox, Radio Buttons, Picklist, Multi-Select Picklist, Checkbox Group, Password, Date, and Date/Time. The other components don’t yet support translation, because they’re Lightning components under the hood and we don’t have a way of identifying which Lightning component attribute should map to label vs. help text vs. error message. The same issue applies for our out-of-the-box actions, like Send Email or Post to Chatter. However, there is a workaround! If you define the translated labels with a Custom Label, you can reference that custom label in the action or component when you configure it in Flow Builder. Create a flow formula that references the custom label, and reference that formula in the appropriate places in your flow. Now for LWC. Certain base components automatically inherit translations of the associated object’s fields, help text, and validation messages if they’ve been configured in Translation Workbench. For example lightning-record-form . If you need to introduce novel translatable labels in your code, Custom Labels are still the unsung hero. Declare the custom label you need, and then import it into your component from the @salesforce/label scoped module. UI Test Automation Do you need automated testing? Dynamic Forms Screen Flow Screen Flow + LWC LWC Unit Tests Not Available Not Available Requires Code Available End-to-End Automation Requires Code Requires Code Requires Code Available Consider your requirements for UI test automation. Unit tests enable more granular automation and validation that works with industry standard CI/CD systems and tools, which can test the components business logic, its Javascript controller, and its outputs. Going exclusively with low-code you will not be able to self author tests, but Salesforce rigorously tests our end-to-end offerings. If your component’s methods are complex enough that you want them to be tested individually, put the methods into dedicated JS files. That way you can import them into a LWC and into a Jest test with something like import { sort } from 'c/utils';. With end-to-end (Selenium) automation, you can simulate how the user interacts with your form. However, these tests can't verify the outputs of each method being performed. You can write these tests for any standard or custom UI – Lightning pages and screen flows inclusive. This recent blog post UI Test Automation on Salesforce compares the various options you have for building end-to-end automation on Salesforce. Included are considerations for when to use a no-code solution from an ISV, build your own custom test automation solution, or use an open source test framework like Selenium WebDriver or WebdriverIO. These solutions are valid for any UI interaction in Salesforce, whether that’s a Dynamic Form in a Lightning page, a screen flow in a utility bar, or an LWC in a flow in a quick action. Metrics Do you need to track usage of your form? Dynamic Forms Screen Flow Screen Flow + LWC LWC Page Views Available Available Available Available* Time Spent on Form Not Available Available Available Available Track Form Completion Not Available Available Available Available Track Success Rate Not Available Available Available Available If you need to track overall usage and adoption of your form, start with the low-code tools. Both Dynamic Forms and Screen Flows are trackable using out-of-the-box custom report types, though you’ll get more granularity from the Screen Flow tracking reports. If you need to track usage of a LWC, out-of-the-box availability depends on where you’re using that LWC. If it’s on a Lightning page, whatever is available for tracking Lightning page usage applies to your LWC. The same story goes for LWCs that are embedded in flows. Dynamic Forms themselves aren’t trackable out-of-the-box, though you can track the usage of the parent Lightning page through Lightning usage objects. To track the standard Lightning pages, use the Users with Lightning Usage by Page Metrics custom report type. For the same on custom Lightning pages, use the Users with Lightning Usage by FlexiPage Metrics custom report type. For tracking adoption of your specific form (not just the page it lives in), Flow’s got you covered. Use the “Sample Flow Report: Screen Flows” to answer questions like: What’s the completion rate for this form? Is it being well-adopted? How long does it take users to complete this form? Which screen do users spend the most time on? How often do users navigate backwards? How often do errors occur? If the standard report doesn’t meet your needs, clone it to make your own changes or build your own from scratch by using the Screen Flows report type. To track the same for an LWC that isn’t embedded in a screen flow or Lightning page, there’s no out-of-the-box option. You can build a DIY solution by using Apex. Closing Remarks Hello, and welcome to the end of this guide! 🏁 Kudos for making it through the equivalent of 9 double-sided pages. Have a good day and thanks for the read. Hope you learned something. Tell us what you think Help us make sure we're publishing what is most relevant to you: take our survey to provide feedback on this content and tell us what you’d like to see next.

[tak4hir0]

When you’re composing custom web components, you need to understand how events bubble up through the DOM because that’s how children and parents communicate—props down, events up. When an event bubbles, it becomes part of your component’s API and every consumer along the event’s path must understand the event. Whether you’re composing a simple or complex component, it’s important to understand how bubbling works, so you can choose the most restrictive bubbling configuration that works for your component. This article covers two composition patterns: static and dynamic, which uses slots. In each pattern, a child component that sits at the bottom of the composition sends a custom event up through the component tree. I’ll look at how the event bubbles for every configuration of bubbles and composed, so you deeply understand how to configure events in your compositions. NOTE: This article applies to working with Lightning Web Components on Lightning Platform and Open Source. Because Salesforce supports older browser versions that don’t fully support native shadow DOM, Lightning Web Components on Lightning Platform uses a synthetic version of shadow DOM. On open source, you can choose to use synthetic or native shadow DOM. When there is a behavior difference between the two, we call it out. Due to the synthetic shadow, when you use Dev Tools to look at markup in a browser, you don’t see the #shadow-root tag. Shadow DOM If you’re already familiar with shadow DOM and slots, skip to the first pattern: Static Composition. Web components create and dispatch DOM events, but there are two things about web components that make working with events a little different: shadow DOM and slots. First I’ll explain shadow DOM and then slots. Every web component’s DOM is encapsulated in a shadow DOM that other components can’t see. When an event bubbles (bubbles = true), it doesn’t cross a shadow boundary unless you configure it to (composed = true). Shadow DOM enables component encapsulation. It allows a component to have its own shadow tree of DOM nodes that can’t be accidentally accessed from the main document and can have local style rules. The shadow root is the top-most node in a shadow tree. This node is attached to a regular DOM node called a host element. The shadow boundary is the line between the shadow root and the host element. It’s where the shadow DOM ends and the regular DOM begins. DOM queries and CSS rules can’t cross the shadow boundary, which creates encapsulation. The regular DOM is also called the light DOM to distinguish it from the shadow DOM. Whether a DOM is a light DOM or shadow DOM depends on the point of view. From the point of view of a component’s JavaScript class, the elements in its template belong to the light DOM. The component owns them; they’re regular DOM elements. From the point of view of the outside world, those same elements are part of the component’s shadow DOM. The outside world can’t see them or access them. I'm just a regular paragraph element, I'm part of the light DOM <!-- The c-child element is part of the light DOM. But everything below #shadow-root is hidden, because it's part of c-child's shadow DOM. #shadow-root In c-child, I'm light DOM. To everyone else, I'm shadow DOM. Slots A web component can contain elements. Other components can pass elements into a slot, which allows you to compose components dynamically. When a component has a , a container component can pass light DOM elements into the slot. I can host other elements via slots Passing you some Light DOM content. The browser renders the flattened tree, which is what you see on the page. The important thing to understand is that the DOM passed into the slot doesn’t become part of the child’s shadow DOM; it’s part of the container’s shadow DOM. #shadow-root #shadow-root I can host other elements via slots // To the outside world, // I'm not part of c-child-slot shadow DOM // I'm part of c-container shadow DOM To c-container, I'm light DOM. When we use slots, even though the content appears to be rendered inside the slot element, the actual element doesn’t get moved around. Rather, a “pointer” to the original content gets inserted into the slot. This is an important concept to understand in order to make sense of what’s happening with our events. Events To create events in a Lightning Web Component, use the CustomEvent interface, which inherits from Event. In Lightning Web Components, CustomEvent provides a more consistent experience across browsers, including Internet Explorer. When you create an event, define event bubbling behavior using two properties: bubbles and composed. bubbles A Boolean value indicating whether the event bubbles up through the DOM or not. Defaults to false. composed A Boolean value indicating whether the event can pass through the shadow boundary. Defaults to false. import { LightningElement } from 'lwc'; export default class MyComponent extends LightningElement { renderedCallback(){ this.dispatchEvent( new CustomEvent('notify', { bubbles:true, composed:true }) ); } } Important Events become part of your component’s API, so it’s best to use the least disruptive, most restrictive configuration that works for your use case. To get information about an event, use the Event API. event.target — A reference to the element that dispatched the event. As it bubbles up the tree, the value of target changes to represent an element in the same scope as the listening element. This event retargeting preserves component encapsulation. We’ll see how this works later on. event.currentTarget — A reference to the element that the event handler is attached to. event.composedPath() — Interface that returns the event’s path, which is an array of the objects on which listeners will be invoked, depending on the configuration used.d. Static Composition A static composition doesn’t use slots. Here we have the simplest example: c-app composes component c-parent, which in turn composes c-child. We fire an event, buttonclick, from c-child whenever a click action happens on its button element. We have attached event listeners for that custom event on the following elements: body c-app host c-parent host div.wrapper c-child host The flattened tree looks like this: Here is a visual representation: Now we’ll look at how the event bubbles with each event configuration. {bubbles: false, composed: false} With this configuration, only c-child gets to react to the buttonclick event fired from c-child. The event doesn’t bubble past the host. This is the recommended configuration because it provides the best encapsulation for your component. This is where you start, then from here you can start incorporating other more permissive configurations, as the ones we’re about to explore in the next few sections, to fit your requirements. If we inspect c-child handler’s we find these values on the event object: event.currentTarget = c-child event.target = c-child { bubbles: true, composed: false } With this configuration, the buttonclick event from c-child event travels from bottom to top until it finds a shadow root or the event gets canceled. The result, in addition to c-child, div.wrapper can also react to the event. Use this configuration to bubble up an event inside the component’s template, creating an internal event. You can also use this configuration to handle an event in a component’s grandparent. And again, here are what the events are telling us for each handler: c-child handler: event.currentTarget = c-child event.target = c-child div.childWrapper handler: event.currentTarget = div.childWrapper event.target = c-child { bubbles : false, composed : true } This configuration is supported for native shadow DOM, which means it isn’t supported on Lightning Platform. Even for LWC open source, this configuration isn’t suggested, but it’s helpful for understanding how events bubble in a shadow DOM context. Composed events can break shadow boundaries and bounce from host to host along their path. They don’t continue to bubble beyond that unless they also set bubbles:true. In this case, c-child, c-parent, and c-app can react to the event. It’s interesting to note that div.wrapper can’t handle the event, because the event doesn’t bubble in the shadow itself. Let’s see what the handler’s have to say about the event: c-child handler: event.currentTarget = c-child event.target = c-child c-parent handler: event.currentTarget = c-parent event.target = c-parent c-app handler: event.currentTarget = c-app event.target = c-app It’s interesting to note that div.wrapper can’t handle the event because even if the event propagates from shadow to shadow, it doesn’t bubble in the shadow itself. Let’s pause here and notice that even though the event was fired from c-child, when it gets to c-parent and c-app , it shows the host as both target and currentTarget. What’s happening? Event retargeting at its finest. As the buttonclick event leaves c-child‘s shadow, the event gets treated as an implementation detail and its target is changed to match the scope of the listener. This is one of the reasons why composed:true flags should be used with caution, since the semantics of c-child‘s event and its receiver don’t match. c-child fired the event, but to c-app, it looks like c-app fired it. Using the { bubbles:false, composed:true } configuration is an anti-pattern. The correct pattern is for receivers that are able to understand buttonclick to repack and send the event with the proper semantics. For example, c-parent could receive the event from c-child and expose a new custom event, so that elements on c-app‘s light tree could understand. { bubbles : true, composed : true } This configuration isn’t suggested because it creates an event that crosses every boundary. Every element gets the event, even the regular DOM elements that aren’t part of any shadow. The event can bubble all the way up to the body element. When firing events this way, you can pollute the event space, leak information, and create confusing semantics. Events are considered part of your component’s API, so make sure that anyone on the event path is able to understand and handle the event’s payload if it has one. Finally, let’s explore the event’s values: c-child handler: event.currentTarget = c-child event.target = c-child div.wrapper handler: event.currentTarget = div.wraper event.target = c-child c-parent handler: event.currentTarget = c-parent event.target = c-parent c-app handler: event.currentTarget = c-app event.target = c-app body handler: event.currentTarget = body event.target = c-app Dynamic Composition with Slots Now we’ll explore how events bubble in compositions that use slots. We have a c-parent element that accepts any content via the special element. Using c-app, we compose c-parent and we pass c-child as its child. The code fires an event from c-child named buttonclick : handleClick() { const buttonclicked = new CustomEvent('buttonclick', { // event options }); this.dispatchEvent(buttonclicked); } The code attaches event listeners on the following elements: c-child host slot c-parent host div.wrapper c-app host body This is the flattened tree as it looks in the browser’s Developer Tools. Remember that when we use slots, even though the content appears to be rendered inside the slot element, the actual element doesn’t get moved around. Rather, a “pointer” to the original content gets inserted into the slot. This is an important concept to understand in order to make sense of what’s happening with our events. This view of the flattened tree shows you where the content passed into the slot really sits in the DOM. c-child is part of c-app`’s shadow DOM. It isn’t part of c-parent’s shadow DOM. With that in mind, let’s look at the results we get with all the different configurations. {bubbles : false, composed : false} As with the previous composition example, the event doesn’t move past c-child, which is where it was fired. This is also the recommended configuration for dynamic compositions because it provides the best encapsulation for your component. c-child handler: event.currentTarget = c-child event.target = c-child {bubbles : true, composed : false} NOTE: This configuration behaves differently when you’re using native shadow DOM with Lightning Web Components: Open Source. With native shadow DOM, the event doesn’t pass out of the slot unless composed is also true. With this configuration, the connectedchild event fired from c-child event travels from bottom to top until it finds a shadow root or the event gets canceled. In our static example, we mention how an event with this configuration bubbles until it travels from bottom to top until it finds a shadow root or the event gets canceled. Let’s explore what event.composedPath() has to say about this use case: 0: my-child 1: slot 2: document-fragment // my-parent shadow root 3: my-parent 4: div.wrapper 5: document-fragment // my-app shadow root As you see, it looks as if the event would be able to break out of my-parent‘s #shadow-root and bubble up outside, even though, composed is set to false. Confused? You should be. Let’s look closer. There is a “double-bubble” effect here. Because slotted content doesn’t really move things around but rather creates pointers from the light DOM and into a particular slot, when we fire the buttonclick event, the event gets to travel from both places, which creates a composedPath like the one we just saw. Finally here is what our event handlers tell us about targets: c-child handler: event.currentTarget = c-child event.target = c-child c-parent handler: event.currentTarget = c-parent event.target = c-child div.wrapper handler: event.currentTarget = div event.target = c-child Notice how div.wrapper‘s target is still c-child, since the event technically never crossed c-parent‘s shadow root. {bubbles : false, composed : true} Like simple composition, this configuration is an anti-pattern and it isn’t supported on Lightning Platform, but it’s helpful for understanding how events bubble in a shadow DOM context. The event bounces from one host to another host as long as they’re in different shadows. In this case, c-child isn’t part of c-parent‘s shadow, but instead part of c-app’s shadow, so it jumps directly to c-app. The event.composedPath() results also throws some interesting results: 0: my-child 1: slot 2: document-fragment 3: my-parent 4: div.wrapper 5: document-fragment 6: my-test 7: body 8: html 9: document 10: Window It’s showing that when we set composed:true, the event can break out of every shadow root. In this case, it doesn’t, since the bubbles property is set to true. Instead, it jumps from host to host. Targets: c-child handler: event.currentTarget = c-child event.target = c-child c-app handler: event.currentTarget = c-app event.target = c-child Again, it’s helpful to look at this view of the flattened tree to remember that c-child in the slot is just a pointer. {bubbles : true, composed : true} This is the “brute force” scenario, and like our static composition example, the event bubbles everywhere, which is an anti-pattern. Every element on the event’s composed path can handle the event. c-child handler: event.currentTarget = c-child event.target = c-child c-parent handler: event.currentTarget = c-parent event.target = c-child div.wrapper handler: event.currentTarget = div event.target = c-child c-app handler: event.currentTarget = c-app event.target = c-app body handler: event.currentTarget = body event.target = c-app Conclusion Events are part of your API. Be mindful of the API’s consumers. Every consumer along the event’s path must understand the event and how to handle its payload. Be mindful when setting the composed and bubbles flags, since they can have undesired results. Use the least disruptive settings that work for your use case, with the least disruptive being (bubbles: false, composed: false). And finally, remember that dynamic compositions using slots introduce an extra level of complexity since you have to deal with assigned nodes inside your slot elements. About the author Gonzalo Cordero works as a software engineer at Salesforce. Github: @gonzalocordero

[tak4hir0]

Find out how you can easily refresh view of record page. Understand Promises and use it in your LWC component. Post contains introduction to promises, code examples and use cases. Ready-to-use Lightning Component with Lightning Datatable, Pagination and Search logic on the client-side. Step by Step Email Reminders configuration by Process  Builder and Workflow Rule. A Short guide through Salesforce DX Create custom type for your LWC lightning datatable Learn how to use Custom Metadata to control invoking different contexts of Apex Triggers. Create simple form with LWC divided into sections Easy way to save, update, publish and unpublish knowledge articles by Apex. How we can display files in the Salesforce Community and allows community users to download it. Check how can your protect your forms from being filled by bots. Create Single Page Application with Lightning Web Components. Check out how to enable self-register for your users in Salesforce Community Salesforce to Salesforce Single Sign-On (SAML) Add a Single Sign-On possibility to your Salesforce environment. Salesforce to Salesforce REST API connection Connect your Salesforce org with another Salesforce org or do connection within the same enviroment. Use REST API callouts and Apex code. Salesforce to Google REST API Integration Connect your Salesforce org with Google. Use REST API callouts and Apex code. Learn how to dynamically assign multiple approvers in Approval Process using Apex, when you’re not able to use Queue or static assignments. How to navigate to created record Learn how to navigate to record created with quick action Custom validation with lightning:recordEditForm Let’s learn how to make custom validation with great tool lightning:recordEditForm Design Patterns in Apex – Abstract Factory Abstract factory provided an interface, which is responsible for creation related objects without specifying their class. Using Hierarchy Custom Setting to bypass Validation Rules for profiles or users. It’s usefull, easy to configure and manage. This is a work-around that helps you get Dependent Picklist values that correspond to a particular Controlling Field value. Design Patterns in Apex – Builder The Builder is a design pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. Ant Migration Tool - Full Guide Ant Migration is a tool provided by Salesforce. It’s used to migrating metadata between local files and Salesforce environment (org). How to detect “Log in to Community as User” in Apex? The question is “How we can detect that current user is log in to the community on behalf of contact?”

[tak4hir0]

This weekend, all of the remaining Spring ’20 Orgs will be automatically upgraded to the Summer ’20 release. Along with that update, the developer evangelism team will also update the Sample Gallery. In this post we’ll do a quick recap of the Summer ’20 features highlighted in the sample apps and go over some other updates that the team has been working on, namely: a tooling update that lets us track code coverage and a Lightning Web Component test blitz. Summer ’20 feature highlights Here’s a recap of the top Summer ’20 features that we’ve added to the sample apps: Cross UI technology communication with Lightning Message Service CSS sharing among Lightning Web Components Lightning page metadata update Checking user permissions within a Lightning Web Component Check out LWC Recipes for an overview of these new features. We’ve added new dedicated recipes to illustrate them. Here’s an example for the Lightning Message Service. You can see it in action with our three UI technologies (Visualforce, Aura and Lightning Web Components).   Check out this blog post to learn more about these new features and don’t forget to refer to the release notes to get more info about all the other new features that aren’t included in the sample apps. Tooling update: Code coverage tracking Along with our efforts to update our sample apps for Summer ’20, we’ve deployed Codecov on all sample app repositories. This tool lets us track code coverage for each app. Each time our CI workflows run, we run tests and generate code coverage reports for Apex and Lightning Web Components. During the workflow execution, we upload the two coverage reports to Codecov. Codecov aggregates the reports and provides a consolidated view of the project’s code coverage. The outcome of this work is directly visible in each project’s readme: you’ll notice a new badge with the current code coverage. Note that there’s more to this than meets the eye. Click on that badge and you’ll see for yourself: Codecov generates a number of graphs, statistics and visualizations that let you track the evolution of coverage over time. Not only that, but we’ve also enabled automated comments on Pull Requests (PR). These comments report code coverage changes introduced by the PRs. This lets us easily determine how a contribution affects code coverage without having to explore the source code. For example, you can see in the screenshot below that this PR would increase code coverage by 0.68%. Lighting Web Components test blitz Our work on code coverage tracking was preliminary to this week’s effort. The entire developer evangelism team worked hard on closing the sample app code coverage gaps for Lightning Web Components. Prior to this week, some sample apps had no LWC tests at all. By the end of the week, we brought all apps to a minimum of 70% code coverage. Here’s how we worked: We requested all volunteers to perform some prerequisite work to get up to speed on Lightning Web Components testing basics (Lightning Web Components Tests Trailhead module,Testing Lightning Web Components Trailhead Live session and so on). We started the week with some enablement sessions to bring everyone up to speed on advanced testing, best practices, and aligning on common goals. We distributed the 77 untested components between our 9 volunteers. Each volunteer worked on testing their assigned components and created one PR per component. We then conducted code reviews. By the end of the week, everyone had learned a lot and we’d met our objectives. This took some effort but this kind of collaborative exercise is great for developer teams. It’s a time investment that we highly recommend. Summary You now have a good idea of what to expect from the Summer ’20 sample app updates — new features, code coverage tracking and a lot of LWC tests. Make sure to visit the Sample Gallery to discover the different sample apps and check out the latest app versions from GitHub starting on Monday, July 20. About the Author Philippe Ozil is a Principal Developer Evangelist at Salesforce where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full stack developer and enjoys working on robotics and VR projects. Follow him on Twitter @PhilippeOzil or check his GitHub projects @pozil.

[tak4hir0]

Special thanks to my co-author Naren Somisetty. The last few months have affected every business in profound ways. Previously, the rollout of a new Salesforce release was a highly anticipated time. However, in light of the state of the world, we’ve taken a more tempered approach to the rollout of this new release. Salesforce has prioritized business continuity above all by delaying the GA of the Summer ’20 Release to production staggered rollouts starting on June 12, July 10, and July 17 and 18. Despite the release being pushed out, ISVs can still get ahead of the curve by learning and trying out the newest features of Summer ’20 in Sandbox Preview orgs. Tip: More information about the timing of the Summer ’20 rollout can be found in this Knowledge Article. As always, we’re committed and here for our AppExchange partners by helping them prepare and learn about the newest features that they should take advantage of in Salesforce Summer ’20. Keep on reading to learn more. Gone is the cumbersome way of building complex try-catch statements in order to ensure that your SOQL queries conform to Object and Field Level Security permissions. The new WITH SECURITY_ENFORCED clause now enables you to write elegant SOQL SELECT queries that only displays records and fields that the currently logged-in user has access to. In order to pass AppExchange Security Review, apps that use this feature must be coded with API version 48.0 or later as previous versions of this feature in beta or pilot are unsupported. Additional Resources: Enable Field- and Object-Level Permissions Checking Using WITH SECURITY_ENFORCED in SOQL Queries (Generally Available) Developers can now customize the behavior of Aura and Lightning Web Components based on the profile of the currently logged in user in addition to referencing boolean values controlled by Profile-based Custom Permissions. By importing a static reference to a standard User Permission or Custom Permission module defined within a namespaced package, boolean statements can be used to determine whether onscreen elements are shown or control the logical behavior JavaScript controllers. An example use case would be choosing to display or hide a button, text field or screen element based on the permission assigned to a specific user’s profile. Additional Resources: Custom Permissions Overview Feature Management Check User Permissions for Lightning Web Components Introducing Lightning Message Service; a Salesforce technology designed to enable seamless communication across the DOM between Visualforce Pages, Aura Components, and Lightning Web Components. LMS provides a simple to use API to publish and subscribe to messages originating from anywhere throughout Lightning Experience. By using Lightning Message Channel, a front-end service, messages can be sent to components residing anywhere on a Lightning Page, including a popped out utility bar item windows and Visualforce iFrame windows through a pub-sub development model. Keep in mind that all interactions must originate from the same Lightning Experience application instance. Additional Resources: Communicate Across Salesforce UI Technologies with Lightning Message Service Lightning Message Service Documentation Lightning Message Service Developer Preview The process to create a Flow initiated by record changes, Platform Events, and Scheduled Flows has now been streamlined! The start elements of the Flow Builder are now listed more clearly making it easier than ever for Admins to start building their first Flows. Additionally, Flow Templates in Salesforce orgs are now accessible through the Templates tab, meaning that any flows that ISVs include in their Managed Packages will be more prominently displayed. With this enhancement, feature parity is replicated between Workflows, Processes, and Flows, making it more the reason for ISVs to adopt the new Flow technology. Admins can now build powerful Flows that run onscreen with embedded text and Lightning Components, or entirely behind the scenes triggered in a multitude of ways. Flow started by a Record-ChangeAdditional Resources: Create and Edit Flows More Easily with the Improved New Flow Window and Start Element — Release Notes Trigger a Flow That Performs Actions After a Record Is Saved — Release Notes Flow Builder: Platform Event–Triggered Flows, Record-Triggered Flows That Run After Save, More Debug Options, and System Context for Running Flows- Release Notes Lightning Flow: Trigger On Record Changes And Events — 2min Demo Lightning Flow: Invocable Actions Enhancements — 2min Demo Want to get a sneak peek into the upcoming migration tooling used to transition from First Generation Managed Packages to the new Second Generation Packaging technology? Join the Managed Packages Chatter Group in the Partner Community to tune into details on how to participate in the upcoming Developer Preview! To make the transition a smooth process, the PackagePushRequest SOAP API object has been expanded to enable push upgrades to Unlocked and Second-Generation Managed Packages. ISVs can choose which orgs receive a package upgrade, which version the package is upgraded to, and when the upgrade occurs. This feature is useful because it allows ISVs to push package hot fixes and upgrades without burdening their customer subscribers with an step. However, keep in mind although the 2GP technology is in GA, the push upgrade feature is still in Beta. Additional Resources: Schedule and Push Upgrades to Unlocked and Second-Generation Managed Packages (Beta) New for Salesforce Summer ‘20 is the ability to delete obsolete or unwanted Lightning components from Managed Packages even after it has been released. First, remove codeline references to your legacy Lightning Components inside of your package and push the changed code classes to your customers. Then continue with the removal of the component by going to the Package Manager and clicking on the Delete Action next to your Aura or Lightning Web Components contained inside of a package and then push the second package upgrade. Keep in mind that the component still remains in a current subscribers’ org even after installing the second step package upgrade until the Admin of the subscriber org manually removes the component from their org. Additional Resources: Delete Lightning Components from Managed Packages Lightning Platform Mobile developers can now utilize the Notification Builder Platform to send Platform Event notifications to users’ mobile devices with Salesforce Mobile push notifications when business events occur within Subscriber Orgs. To package your custom notifications, go to setup and enter Package in the Quick Find box, then select Package Manager to bundle the connected app and associated Apex triggers into your Managed Package. Hourly limits on the number of Push Notifications sent through the Salesforce Mobile app, the Field Service Lightning mobile app, the Einstein Analytics mobile app, and mobile apps created with Mobile Publisher have been increased. To send notifications via non-Salesforce provided Mobile Apps, ISVs will also need to register with Apple/Google in order to obtain a Push Notification Key. Additional Resources: Send Custom Notifications to External Apps with Notification Builder Platform Send More Push Notifications with Increased Limits Salesforce Mobile Push Notifications Implementation Guide Building intuitive prompts and walkthroughs for your customer users has never been easier! The new In-App Guidance Builder uses a familiar Lightning App Builder-like builder for authoring app guidance prompts. This new tool makes it easier than ever to build Floating and Docked Prompts that help guide your new and existing customers in order to promote adoption of your application. Additional Resources: Meet the In-App Guidance Builder Create Multi-Step Walkthroughs for In-App Training Lightning Experience: In-App Walkthroughs — 3min Demo Service Cloud and Industries ISVs can benefit from faster time to value in Einstein Bot integrations by providing a simplified bot creation process using pre-built templates. The improvements to Bots in Salesforce Summer ’20 have expanded their avenues by allowing subscribers to support and connect to new customers via the new Facebook Messenger Integration and in 8 different languages with the addition of Chinese and Japanese. Skills-based routing has also been introduced to Bots; streamlining the process of matching your customers with the optimal agent who has the skills required to complete the task. Skills let you define attributes that are important to your business, such as language ability, certifications, or product knowledge. ISVs are able to package and develop fully configured bots via the Einstein Bots Console in addition to an Einstein Intents only package that are consumable by Bots. Additional Resources: Say “Bonjour” to Multi-Language Bots Increase Customer Satisfaction with Skills-Based Routing for Bots Expand Your Audience with Facebook Messenger Speed up Lightning Web Component development with the Local Web Development Server available as an Open Beta. Configuring the Salesforce CLI plug-in will allow developers to create a Lightning Web Components-enabled server on their computer and allowing them to create Lightning web components quickly and efficiently by seeing live changes without needing to publish the components to an org. Lightning Local Web Development in actionAdditional Resources: Develop Lightning Web Components Locally LWC Local Development Feature Overview Curious about what’s coming out in the future? This section of resources outlines Beta and Pilot features that have yet to be marked as Generally Available, so please do not include any components that make use of these features in Managed Packages. Break Up Your Record Details with Dynamic Forms (Non-GA Preview) Schedule and Push Upgrades to Unlocked and Second-Generation Managed Packages (Beta) Can’t Untangle Your Metadata? Try Org-Dependent Unlocked Packages (Beta) Get Ready for Unlocked Package Code Coverage EnforcementAlert! Object Access and Permission Changes in Summer ’20 Release

[tak4hir0]

Salesforce’s Summer ’20 release has a number of awesome, new Lightning features. I’m excited to highlight and demonstrate some of my favorite Lightning features using a sample app. You can find the demo app with all the features covered in this article in this repo. Dynamic Forms is the evolution of Lightning Record Pages which lets you break up the page within the Lightning App builder so you can place fields, sections in multiple tabs and apply rules to show and hide fields and sections. This reduces the need for multiple page layouts. More information here. Dynamic Actions provide a highly configurable component that supports actions that can be configured right in the Lightning App Builder. As with dynamic forms, you can show and hide individual actions based on rules. More information here. Lightning Messaging Service is designed to enable communication between Visualforce, Aura, and Lightning Components anywhere on a Lightning Page. LMS provides a simple API to publish and subscribe to messages throughout Lightning Experience on the page. More information here. With new updates, Lightning Flow can now be Triggered from any record change or platform event which means that there is now less dependency on the Process Builder. More information here. Consider a customer applying for a loan with a financial institution. As part of the application process, the loan officer has to upload documents with customer information, forward them to a third-party and await confirmation of receipt. That process might take some time before the application could move forward to the next stage. Once the third party confirms receipt of the documents, the application stage in the UI is automatically updated which notifies the loan officer. The update also triggers a refresh of the dynamic forms/action. Here are the key components on the Loan record page. Path: Loan officer updates this to advance the loan application to the next stage Action bar: This dynamic action bar is configured to expose selected actions based on filter criteria.For example, the “Submit For Approval” action is configured to be visible only when the loan application advances to the “Sent to third party” stage. This makes it easier for the Loan officer to focus only on select sections/fields. Dynamic form: Different sections/fields of dynamic form are configured for a set filter criteria e.g. House Loan section is displayed only when Loan record type is “House”. This makes it easier for the Loan officer to focus only on select sections/fields. Custom LWC: This custom component “objectFieldUpdate” subscribes to a platform event using emp api raised by the “HandleDocumentUpload” flow. On receiving the event it calls refreshApex method which causes Path, Dynamic Forms and Actions to refresh & reflect changes in the Loan status. It also publishes a Lighting Message Service message to indicate status refresh. Custom VF: This Visualforce page subscribes to the Lighting Message Service to update itself on refresh message sent by the Custom LWC. The video shows how the loan officer marks the stage as “Documents Uploaded” and waits for the headless Lightning Flow to send a Platform Event indicating completion of the document Dynamic Forms is currently in pilot and Dynamics Action is in beta. Both features currently work only with custom objects and can be self-enabled by your org administrator. For ISVs partners, Dynamic Forms and Dynamic Actions will be package-able once the features are generally available (GA).The limit of active Platform Event subscribers is 2000. So in this case, if emp-api receives an error on subscribe, make sure to build exception handling to relay the error to the user in a way that allows them to continue to work effectively.In summary, Salesforce Summer ’20 has lots of cool new declarative and programmatic Lightning features, and I hope this blog post helped you learn or get interested in some of those features. Happy coding!

[tak4hir0]

Work can be stressful and we all need a break from time to time. What if you could take that break while having loads of fun and learn a few things at the same time? Well, here’s your chance: we’re excited to release the first multiplayer quiz app built entirely on Salesforce technology! In this blog post, we introduce the Quiz App and share highlights about the app architecture and its deployment. Introducing the Quiz App The quiz app is inspired by the popular Kahoot game. Here’s how it works: First, a game host presents questions from a shared screen or a video projector. Then, players compete by answering those questions in real-time using a mobile web app. The fastest player to give the correct answer scores the most points. As the game progresses, leaderboards are displayed so that players can keep track of scores and ranks. The quiz app was initially launched during Developer Game Night at Dreamforce 2019 with close to a hundred players. Now it’s open source and we’re promoting it during Dreamforce Global Gatherings. That’s right, you can install it for free, inspect the code, and customize it to your liking! Architecture Overview The quiz is divided in two applications: a host app and a player app. The host app is a Lightning Web Component (LWC) app running on a Salesforce Org. The org holds all of the quiz data in custom objects (players, questions, answers…). This means that you can easily import extra questions and customize them. It’s as simple as editing records—zero code change required! The player app is a mobile app built with Lightning Web Components Open Source (LWC OSS). It runs on Node.js deployed on Heroku. There are a few reasons to have the player app on Heroku for our specific use case. First, the Heroku app scales well and can accommodate a large number of users as Heroku limits are based on processing power (dynos) rather than strict governor limits. Secondly, we can easily provide unauthenticated access to our custom app. Unlike Salesforce orgs, there are no user license considerations on Heroku. These advantages do come at a cost: it’s up to us to build the app from the ground up. We use that to our advantage in the quiz player by implementing a lightweight mobile app. Cross-App Communication The two applications communicate with bidirectional REST calls. The player app uses the JSforce library (a JavaScript Salesforce client) to authenticates on the Salesforce org with a username/password flow. The client calls the standard REST APIs as well as a couple of custom Apex REST endpoints. The host app also sends REST requests to the Node.js server of the player app to signal game phase changes (eg: a question becomes available or game results are being displayed). These calls are secured with a shared secret API key that is configured on the two apps during setup. This technique ensures a lightweight and minimal level of security by preventing third parties from accessing the player app REST endpoints. Client-Server Communication on the Player App The player app consists of a client (the LWC OSS app running on a mobile device) and a server (the Node.js backend). The client calls REST APIs on the server to retrieve information like the player’s score. We also establish a WebSocket connection between the client and the server. This allows us to push real-time updates like game phase changes to the mobile app. For example, when a new question can be answered, the Node.js backend broadcasts an WebSocket message to all mobile clients. With that, all players can see game updates at the same time on their mobile devices. While powerful, WebSockets have an important limitation when working on mobile. WebSockets rely on a lasting network connection between the client and the server. On mobile, this connection can easily be broken when the device screen is locked or when the user switches to another app. This means that we must implement some non trivial code to handle reconnection on the client side and a keep alive mechanism to detect and eliminate broken connections on the server side. App Deployment One of the most challenging parts of this project is making sure that the quiz app can be easily deployed by a large number of users with different degrees of technical skill. Given the complexity of the environment (two different technology stacks), we needed to ensure that the deployment is as automated as possible. We rely on two things to achieve that: an org deployment script for the host app and a Heroku deploy button for the player app. Note: the app setup is extensively documented and we even provide a video guide (see link at the end of this post). Org Deployment Script The quiz host app is deployed on a Scratch org with Salesforce DX. This allows us to create a temporary Salesforce org with a lifespan of up to 30 days with a set of commands. These commands are grouped and chained together in a deployment script that you can run with a single command in a terminal. The deployment scripts automates the following tasks: Creating a scratch org Pushing sources to the org Assigning permissions Importing question data Generating a user password Automating the setup process greatly reduces the risk of configuration errors and saves a lot of time. Here’s a simplified version of the deployment script running on MacOs (there’s also an equivalent script for Windows): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 echo "1. Creating scratch org..." && \ sfdx force:org:create -s -f config/project-scratch-def.json -a $ORG_ALIAS -d 30 && \ echo "" && \ echo "2. Pushing source..." && \ sfdx force:source:push -f -u $ORG_ALIAS && \ echo "" && \ echo "3. Assigning permissions..." && \ sfdx force:user:permset:assign -n Quiz_Host -u $ORG_ALIAS && \ echo "" && \ echo "4. Importing data..." && \ sfdx force:data:tree:import -p data/$DATA/plan.json -u $ORG_ALIAS && \ echo "" && \ echo "5. Generating user password..." && \ sfdx force:user:password:generate -u $ORG_ALIAS && \ echo "" EXIT_CODE="$?" # Check exit code echo "" if [ "$EXIT_CODE" -eq 0 ]; then echo "Installation completed." echo "" sfdx force:org:open -p /lightning/setup/SecurityRemoteProxy/home -u $ORG_ALIAS else echo "Installation failed." fi exit $EXIT_CODE Notice how commands are chained together with the && operator. This executes them one after the other as long as there are no errors. The \ character at the end of the line lets us introduce line breaks for readability. At the end of the script we’re checking for the last command’s exit code with EXIT_CODE="$?". This lets us report the deployment status with a message and open the org if everything went well. Heroku Deploy Button The player app is even easier to install with a Heroku deploy button. The deploy button is an image with a link that the user can click to deploy a Heroku app without leaving the browser. The link URL holds a reference to the GitHub repository that contains the app source code and a deployment configuration file. With the deploy button the user only has to enter a few configuration variables before confirming the deployment. Summary Now that you’ve learned about the Quiz App features and architecture, how about giving it a try? Sign up for a Dreamforce Global Gathering near you to find worthy opponents. Or, explore the code, install the apps, and customize questions by simply editing records. Don’t hesitate to let us know how much fun you had on social media! Resources Quiz app installation instructions

[tak4hir0]

Discover Summer ’20 Release features! We are sharing five release highlights for Developers and Admins, curated and published by our evangelists as part of Learn MOAR. Complete the trailmix by July 31, 2020 to get a special community badge, and unlock a $10 contribution to Libraries Without Borders (Bibliothèques Sans Frontières). Salesforce releases three major updates a year and it’s time for Summer ’20. While waiting for the release, developers, admins and architects refer to the release notes to figure out what new features can best serve their business. We in the Developer Evangelism team are no stranger to this process and we’ve been busy updating the Sample Gallery to give you some developer highlights for Summer ’20. We’re only a month away from the release date, and here’s your opportunity to get a sneak peak of upcoming new features. About the Sample Gallery The Sample Gallery is a set of reference apps that showcase a range of low-code to pro-code developer features of the Salesforce platform. Each sample app takes an idea and implements it on the Salesforce platform along with other related apps. It features mobile apps, external-facing web apps, integrations and more. You can read about all the apps on the Sample Gallery homepage which also contains links to source repositories for each app.   Sample app release process Just before the Salesforce release becomes generally available, the Developer Evangelist team starts working on sample app updates. We start by going through the release notes and collaborating with Product Managers to build a list of new features and updates. We then sort that list into three categories: “Must have” for all apps (updating version numbers, replacing workarounds…) “Should have“ features for demonstration purposes in specific apps Other items that are either not a priority for a developer audience or that cannot be adapted into use case examples We then distribute the work between people who maintain the sample apps. We use a unified branching strategy across all of our sample apps. We begin by creating a prerelease/summer20 branch out of the master branch. We then work with Pull Requests (PRs) on those prerelease branches to incorporate the various features. Finally, when we are ready to release the sample app, we merge the prerelease branch back into the master.     Since all sample apps are Open Source, you can see our progress at any time by checking out the content of the prerelease/summer20 branches. You can see upcoming changes and if you have access to a prerelease org like a sandbox, you can even deploy the apps (but keep in mind that these are a work in progress at this stage). Now that you’re familiar with the process, let’s take a look at the Summer ’20 Release highlights. Sample app update highlights for Summer ’20 Cross UI technology communication with Lightning Message Service As of Summer ’20, Lightning Message Service (LMS) is now Generally Available (release notes, documentation). This feature is by far the one that had the biggest impact across all sample apps for this release. LMS is a client-side technology that allows for communication between Visualforce, Aura and Lightning Web Components. It also allows for communication between sibling components.     Bye bye custom pubsub implementation, hello standard Lightning Message Service! Deploying LMS allowed us to remove pubsub, a custom JavaScript implementation that was copied in all sample apps. pubsub was originally intended as a temporary workaround while waiting for a standard implementation (LMS), and now we can now safely discard it. Note: If you have copied pubsub in any of your projects, make sure to replace it with LMS. Let’s take a practical example with one of our sample apps: the E-Bikes’ Product Explorer page below. This page lets you search for bikes and look at product details. There are three components: productFilters, productList and productCard.     We use LMS to communicate across the components. Each component sends and/or receives messages that are triggered when the user interacts with the components in the following ways: When product filters change, productFilter sends a ProductsFiltered message that updates the product list accordingly. When a product from the list is selected, productTileList sends a ProductSelected message that updates the product card with the product detail information. We won’t dive into the code details here for the sake of brevity, but you can take a look at the source code in the GitHub repository and refer to this blog post to learn more about Lightning Messaging Service. CSS sharing among Lightning Web Components In LWC, you can easily share JavaScript among components (see this example in LWC Recipes). With Summer ’20 you can now also share CSS among components. This lets you easily create a consistent look and feel by using a common CSS module. In other words, no more CSS copy/pasting! We used this feature in LWC Recipes to reduce the amount of duplicated CSS. For example, the compositionIteration and compositionBasics components had identical CSS files. In order to fix that, we created a new “component” with just a CSS file and a metadata file like this: cssLibrary ├──cssLibrary.css └──cssLibrary.js-meta.xml We placed the duplicated CSS content from our two components into cssLibrary.css. Then, we simply replaced the content of our two components’ CSS files with this import statement to finish. @import 'c/cssLibrary'; Lightning page metadata update With the introduction of Dynamic Forms (non-GA preview), the metadata structure of FlexiPages (commonly known as Lightning pages) is updated to accommodate both fields and components. This update is completely transparent in orgs but it requires some manual XML transformation if you work with a project in source format. In short, these are the instructions for updating the XML to the new format: componentInstances tags are renamed to componentInstance (note the use of singular). componentInstance tags needs to be nested under a itemInstances parent tag. For example, this was the structure of the Hello FlexiPage from LWC Recipes prior to Summer ’20: In Summer ’20, the FlexiPage is now updated to the following structure: Tip: Speed up the update process by using search and replace on all .flexipage-meta.xml files in your IDE: Replace all instances of with Replace all instances of with Optionally, use a tool to reformat the documents. Application Lifecycle Management and tooling updates On top of the Summer ’20 updates, we’ve also been working on some Application Lifecycle Management (ALM) and tooling updates to help us automate certain tasks. We’ve migrated Easy Space Continuous Integration (CI) from CircleCI to GitHub Actions in an effort to standardize all CI workflows for the sample apps. We’ve also deployed a number of GitHub Actions across all repositories such as an automated welcome message for new issues, an issue auto assignment rule, and some scheduled actions around stale issues and pull requests. What’s next Summer ’20 brings many other great features (Einstein OCR, new Flow triggers, user permission checks in Lightning Web Components just to name a few) that we haven’t integrated yet. We’ll continue to add new features to the prerelease branches. We also plan to improve packaging, add more tests and improve code coverage for all repositories. Additionally, two new sample apps will be released in the near future, but details will remain a secret for now Make sure to visit the Sample Gallery to discover the different apps and check out the latest app version from GitHub. About the Author Philippe Ozil is a Principal Developer Evangelist at Salesforce where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full stack developer and enjoys working on robotics and VR projects. Follow him on Twitter @PhilippeOzil or check his GitHub projects @pozil.

[tak4hir0]

As usual, Spring arrives early for the Salesforce world, and with it, our latest release. During this prerelease cycle, the developer evangelist team has been busy updating our gallery of sample apps with the latest and greatest features. Here’s a list of items that you can find if you pull down the latest from GitHub. What is the Sample Gallery? The sample gallery is a set of reference apps that showcase a range of low-code to pro-code developer features of the Salesforce platform. Each sample app takes an idea and implements it in the Salesforce platform along with other related apps and features e.g. mobile apps, external-facing web apps, integrations, etc. You can read about all the apps on the Sample Gallery landing page, which also contains links to source repos for each app. LWC Properties Are Automatically Reactive In Spring ‘20, the Lightning Web Component core framework has an added feature that makes all properties reactive without the need to be explicitly decorated as such. In the past, where you would have seen @track used to trigger a DOM refresh in LWC, this becomes no longer necessary. To address this, we’ve removed the @track decorator. The code below from the todoList component in the LWC Recipes app shows one instance of how this looks in our sample apps. Previously, the filteredTodos array property was decorated with @track. @track filteredTodos = []; Again, with the new “all properties are reactive” feature, this is no longer necessary; with one important exception. You must use @track to observe changes in the properties of an object or elements of an array. In other words, if you mutate an object or array in place and you want to update the DOM based on that, @track is required. Understanding array or object mutation in JavaScript is not always straightforward. However, every instance of our sample apps follows the practice of not mutating objects or arrays in place, but rather reassigning them when we need to change their state. In the filteredTodos example above, we have removed @track. todo.priority === true ); } else { this.filteredTodos = this._todos; } } ... } When the filterTodos() function is invoked, we use the Array.prototype.filter() higher order function on the “master” list of todo items in the private _todos array. The filter function always returns a new array instance, meaning the line this.filteredTodos = this._todos.filter... will always cause a new object to be assigned to this.filteredTodos and trigger the now implicit reactivity of that property. But be careful, some higher-order array functions (like Array.prototype.sort()) modify an array in place. If you find yourself using one of these, you might want to look into explicitly creating a new array or alternatively, actually use the @track decorator on that array. For more on the implementation of reactive data types in LWC, we recommend reading the documentation on that topic from the LWC open source project. Lightning Pages on Desktop and Mobile Prior to Spring ‘20, there was no easy way to bring Lightning Pages to mobile. Now, you can design your Lightning Pages for mobile as well as desktop. This includes some of the standard templates, but you can also raise the bar by creating your own custom templates. To bring this to life, we updated the custom Lightning page template in the Dreamhouse app. Custom page templates are implemented in Aura today. Above you can see the markup used to define whether the template will use a layout that supports desktop or mobile, based on information provided by the browser. We reviewed components and modified any we needed to in order for them to work in a small form factor. In addition to ensuring the components themselves were responsive, we also needed to configure the metadata file to indicate which form factors a given component supports. Finally, we configured the app as well as several record pages to be available for mobile, and we were now all set for our pages to work in both mobile and desktop. Check In Your Community For developers working with Communities, the Communities Experience Bundle is a long awaited improvement to your application lifecycle management. This new way to store your community configuration creates a bundle of files which allows you to build, configure, and customize your community as well as check the entire configuration in version control, in a JSON-based format. No more binary .site file! This change also now makes it possible to create and test your community in a scratch org and manage its deployment from the Salesforce CLI. The experience bundle feature has been in closed pilot… until now. In moving to being generally available, the experience bundle feature adds support for unlocked packages, as well as support for additional Communities configurations that weren’t in the pilot. You can see this in use and test it out in the e-bikes sample app. Please note that the effort to migrate an existing community to the experience bundle format varies greatly between orgs. If you decide to make the transition, be sure to budget time to investigate how this change will impact you. If you would like to read more about using the experience bundle, be sure to check out the Communities developer guide, or read about the implementation specs in the Metadata API developer guide. You can also watch this segment on experience bundles from the release readiness live webinar. SOQL SECURITY_ENFORCED Queries Apex has been introducing some exciting new features, and nothing is more exciting to you (and your compliance team) than more secure data access. While some of these are still in beta, we’re pleased to include the new SOQL WITH SECURITY_ENFORCED clause in most Apex classes that use SOQL (where the SOQL fits the restrictions of that feature) Here’s an example: findContacts(String searchKey) { String key = '%' + searchKey + '%'; return [ SELECT Id, Name, Title, Phone, Email, Picture__c FROM Contact WHERE Name LIKE :key AND Picture__c != null WITH SECURITY_ENFORCED LIMIT 10 ]; } The WITH SECURITY_ENFORCED clause allows you to bring object and field security into your Apex SOQL queries with one simple statement. There are a few rules around using it correctly, so be sure to check out the documentation and the release notes for implementation details. A segment from the release readiness webinar that covers the new Apex security features can be seen here. Navigating to New Records with Default Values The term “url hack” has long been fabled in the annals of Salesforce developer lore as a by-the-seat-of-your-pants “pattern”. Well, hack no longer! In Lightning, both Aura and LWC components support the ability to navigate to a new record with default values. We’ve implemented this in its own recipe in the LWC Recipes app. import { LightningElement } from 'lwc'; import { NavigationMixin } from 'lightning/navigation'; import { encodeDefaultFieldValues } from 'lightning/pageReferenceUtils'; export default class NavToNewRecord extends NavigationMixin(LightningElement) { navigateToNewContactWithDefaults() { // get encoded default values const defaultValues = encodeDefaultFieldValues({ FirstName: 'Morag', LastName: 'de Fault', LeadSource: 'Other', AccountId: '011xxxxxxxxxxxxXXX' }); console.log(defaultValues); this[NavigationMixin.Navigate]({ type: 'standard__objectPage', attributes: { objectApiName: 'Contact', actionName: 'new' }, state: { // assign default values for nav pageReference defaultFieldValues: defaultValues } }); } } Note that for the time being, sfdx-lwc-jest framework does not support the lightning/pageReferenceUtils package, so we’ve implemented a dummy test. We will however be updating this once a better solution appears.   When initiating navigation, the PageReference supports a state value to set default values, and the lightning/pageReferenceUtils utility has been added to correctly encode and decode default values. In Aura, this utility is referenced in markup as a component called Other Items of Note Coming Changes to the sample apps We’re constantly working to improve our sample apps for you. Some great things are planned to ship throughout this year. If you want to get a sneak peak of one of these you should check out Trailhead Live, where developer evangelist Kevin Poorman codes live on…drumroll…Apex Recipes! Stay tuned! You too can contribute If you have an idea for a feature to add to a sample app, or see a bug or potential improvement, we welcome your contributions to the sample apps! Details for how to contribute are located in each sample app repo. So if you see something, file an issue and we can discuss it with you; if you can write the solution, we welcome the PRs. Summing It Up As always, releases are a bit like a birthday present that comes three times a year. We hope you enjoy exploring these features in our gallery of sample apps as we all welcome Spring ‘20 to our orgs.