#salesforcetutorial — Public Fediverse posts

Choices, Choices: What Are Radio Button Groups Best Used For

Salesforce’s Summer ’26 release is packing some serious automation upgrades. Whether you are managing multi-stakeholder approvals, scaling orchestration across your org, or building complex integrations without code, the platform is steadily removing friction points for admins. Among the most anticipated and highly visible improvements are the user interface enhancements coming to Screen Flows.

If you have ever built a screen flow and felt like you just couldn’t find the exact picker component you really needed, you are not alone. For years, Salesforce admins have relied on a standard set of inputs, but sometimes those options don’t quite fit the modern, streamlined aesthetic required for consumer-facing or high-efficiency internal apps. With the Salesforce Summer ’26 release, we are finally getting a massive UI upgrade to solve this: the Radio Button Group component.

The Problem with Traditional Inputs

Historically, when admins wanted to present users with a single-select choice, they relied heavily on traditional radio buttons, checkboxes, or picklists. While highly functional, these standard inputs can take up significant screen real estate. In complex flows, vertically listed radio buttons or extraordinarily long picklists often force users to scroll excessively, leading to a clunky and outdated user experience.

The Solution: Compact, Responsive Radio Button Groups

The new Radio Button Group component solves this real estate problem by offering a more compact and easily scannable alternative. It retains the core functionality of traditional radio buttons, meaning users can still only select a single option at runtime, but it completely overhauls the visual layout.

Visually, these actually look like “proper buttons” rather than old-school radio circles, giving your users a completely different interface experience than what we previously had inside Flow Builder. This component is fully responsive and adapts intelligently to the user’s device:

On Desktop: Choices are presented as horizontally stacked options, making excellent use of wider screens and drastically reducing vertical scrolling.

On Mobile: Choices automatically shift to a vertically stacked layout to accommodate narrower touch screens

Example Use Cases and Pro-Tips

Because these look like actual buttons, they are perfect for making quick, high-level decisions obvious to the user.

Action Selection: Give your users a clear, button-driven choice to “Create,” “Update,” or “Delete” a record

Shipping & Checkout: Instead of burying delivery speeds in a dropdown, present horizontal, button-like choices for “Standard,” “Express,” and “Overnight” shipping.

Adding this to your flows is incredibly simple. Inside Flow Builder, you just drag the Radio Button Group component from the left panel directly onto your screen, and configure it by adding your desired choices.

A Pro-Tip on Customization (Icons vs. Emojis): If you are looking to make these buttons even more visual, there is one important design limitation to keep in mind. If you select a standard Salesforce icon for your choice, it is not going to display inside the Radio Button Group.

If you absolutely need native Salesforce icons, you will still want to use the Visual Picker component. However, there is a fun and easy workaround: you can use emojis directly in your choice text labels. Many Trailblazers have already started using emojis while demoing this new functionality to add a pop of color and visual context to these new button groups.

A Comprehensive Review of Choice Components in Salesforce Flows

While the new Radio Button Group is exciting, Salesforce Flows offer a wide variety of choice components, each suited for specific scenarios. Here is a short review of all the choice components currently available to help you build the best user experience.

Standard Radio Buttons

What it is: The classic vertical list of circular clickable options.

When to use it: Use this when you have a small number of mutually exclusive choices (usually 2 to 5) and you want all options to be immediately visible to the user without requiring them to click a dropdown.

Drawbacks: As noted in the Summer ’26 updates, standard radio buttons stack vertically and can take up too much vertical screen space, causing excessive scrolling on longer forms

Picklists (Dropdowns)

What it is: A standard dropdown menu that reveals a list of choices when clicked.

When to use it: Picklists are ideal when you have a long list of mutually exclusive options (e.g., a list of 50 US States) and you need to conserve screen real estate.

Drawbacks: They require an extra click to view the options, which hides information from the user until they interact with the component.

Dependent Picklists

What it is: A set of picklists where the choices available in the second (dependent) picklist are dynamically filtered based on the value selected in the first (controlling) picklist.

When to use it: Perfect for hierarchical data, such as selecting a “Country” and then selecting a “State/Province” within that specific country.

Summer ’26 Update: As of Summer ’26, Dependent Picklists are one of the expanded components that now support styling overrides. You can customize their look and feel to override your org’s default theme, giving you more branding control.

Checkboxes (and Checkbox Groups)

What it is: Square selection boxes that allow for multiple selections.

When to use it: Use checkboxes when the user is allowed to select more than one option at a time (“Select all that apply”), or as a standalone boolean (True/False) toggle.

Drawbacks: Like standard radio buttons, long lists of checkboxes can clutter the screen and force scrolling.

Visual Picker

What it is: A highly visual, tile-based selection component that supports the inclusion of native Salesforce icons and rich text.

When to use it: Use the Visual Picker when you want to create a visually engaging, card-like selection experience. As mentioned previously, if you need to display standard Salesforce icons alongside your choices, the Visual Picker is the component you must use, as the new Radio Button Group does not support them.

Choice Lookup

What it is: A search-based input field that allows users to type and dynamically filter through a massive list of choices or records.

When to use it: Use this when your list of choices is too large for a standard picklist, and you want to provide a “search-as-you-type” experience to help the user find their desired option quickly.

Summer ’26 Update: Just like Dependent Picklists, the Choice Lookup component has been upgraded in the Summer ’26 release to support full styling overrides. You can now customize its style and layout to perfectly match your Experience Cloud site or custom Lightning app.

Ready to Build Better Screen Flows? Start With Summer ’26

With the addition of the new Radio Button Group component, admins now have more flexibility than ever to design intuitive, low-friction screen flows. By understanding the strengths and limitations of each choice component, from the visual flair of the Visual Picker to the space-saving utility of Picklists and the modern layout of the Radio Button Group, you can ensure your Salesforce automations look just as good as they function.

The best part? These are not just cosmetic upgrades. When users can scan choices faster, make decisions with fewer clicks, and navigate flows without excessive scrolling, you see real downstream impact: higher completion rates, fewer errors, and less admin rework. Whether you are building a customer-facing Experience Cloud app or an internal ops tool used by your sales team every day, thoughtful component selection is what separates a flow that users tolerate from one they actually enjoy. Take some time in a sandbox this release cycle to swap out those legacy radio button stacks and long picklists for their Summer ’26 counterparts. The difference will be immediately obvious.

Explore related content:

Summer ’26: What the New Accessibility Release Updates Mean for Your Org

Warn and Inform with Native Toast Messages in Salesforce Flow

Field Access Summary

Summer ’26: What the New Accessibility Release Updates Mean for Your Org

How Salesforce Will Secure Your Org Against Hackers

Security and convenience are almost always inversely correlated. Making something more secure inherently makes it harder to access, which creates real friction for everyday users. This tension is nothing new. Hackers have always sought unauthorized access to systems, but historically, the barriers were high: computers were expensive and internet access was scarce. This is no longer true.

This battle front has always favored attackers. Security teams must successfully defend against every single intrusion attempt, while hackers only need to succeed once. A single breach can cause significant damage.

What’s changed is the scale and speed of attacks. AI has dramatically lowered the barrier to entry, enabling hackers to probe far more systems, far more frequently than ever before.

Recently, several Salesforce customers experienced significant system breaches involving their Salesforce instances, most notably those tied to the ShinyHunters cybercriminal group. What made these incidents particularly damaging was that the compromised accounts belonged to users with elevated access, including admins and developers. Salesforce denied responsibility and took limited action, largely confining its response to informing and educating the ecosystem about the risks of phishing and vishing attacks.

It seems like that is about to change. Big time.

Salesforce decided to enforce multiple security controls starting June-August 2026 to prevent credential theft, data exfiltration, and account takeovers. IP range restrictions originally planned are no longer being mandated, but MFA for all employee users, phishing-resistant MFA for admins, auto-containment for high-risk connections, and step-up authentication for reports will be enforced.

This means your life is about to get more difficult, especially if you have elevated access typically used by admins, developers and architects.

The New Security Direction by Salesforce

• MFA exemption permission restricted: The “Waive Multifactor Authentication for Exempt Users” permission will be removed except for justified cases (automation/testing users) requiring support approval. 
• New permission set required: “Modify Transaction Security Policy” permission set introduced. Users need both the new “Modify Transaction Security Policy” permission AND the existing “Customize Application” permission to manage TSPs. Users with only the Customize Application permission will be downgraded to read-only access for TSPs.
• IP range restriction enforcement removed: The requirement to use IP ranges on profiles and the “enforce login ranges on every request” setting will not be mandated, though strongly recommended for customers who can implement them.
• Staggered rollout approach: Enforcement timelines extended and staggered by instance to minimize customer disruption.

Security Controls Being Enforced

Auto-Containment Measures

High-risk IP blocking was expanded April 24th to include all connected app and API traffic from anonymizing VPNs, proxies, and high-risk IP addresses; users are contained automatically with admin notifications. Extended login anomaly containment applies to all internal user login behavior (excluding external/community users) and focuses on detecting suspicious login patterns. There is no allow-list override, meaning even allow-listed IP addresses will be contained if classified as high-risk at connection time. There are also AWS integration issues under active investigation, with some AWS IP addresses being incorrectly flagged and the issue currently being resolved.

MFA Requirements

All Employee Users: 

MFA is required for all employee license users, excluding Experience Cloud and external users. Enforcement is handled via locked settings, so admins cannot disable it. API-only logins are exempt, as the requirement applies exclusively to UI logins. For SSO, providers must pass AMR/ACR signals indicating strong or phishing-resistant MFA.

Timeline: Sandboxes June 22-29; Production July 20-August 17 

Admins and Privileged Users: 

Phishing-resistant MFA is required for users with elevated privileges, specifically those on the default Sys Admin profile or holding Modify All Data, View All Data, Customize Application, or Author Apex permissions. This standard is stricter than standard MFA, and mobile authenticator apps do not meet the threshold. Only security keys and built-in authenticators or passkeys qualify.

Timeline: Sandboxes June 22-29; Production July 1-27 

Email Domain Verification

DKIM or authorized email domain verification is required for all email sending domains (this was previously announced). Enforcement is being rolled out on a staggered timeline; check the timeline knowledge article for the latest dates. A tool is also available to verify compliance status.

Step-Up Authentication for Reports

Time-Based Session Policy:

• Additional authentication required when users spend considerable time on reports.
• Admins can configure the “Require step-up authentication within cool-down period” session-level policy to an exact cadence between 2 and 120 minutes (with 120 minutes being the default); logging in with MFA does not reset timer.
• Verification methods: Users can use any supported MFA method, including Passkeys, Security Keys, Salesforce Authenticator, and third-party TOTP apps. The email and SMS One-Time Password (OTP) options are specifically fallback challenges for Single Sign-On (SSO) users who do not have a Salesforce MFA method registered.
• Report access blocked if authentication fails (UI only, not API).
• Timeline: Available May 27 (sandbox/production); Enforced June 3 (sandbox), June 10-July 4 (production). 

Anomalous Behavior Detection: 

• ML-based detection triggers authentication when unusual report viewing/downloading behavior detected.
• Users must configure at least one verification method (authenticator app, phone, email) or report access blocked. 
• Timeline: Enforced June 22 (sandbox), July 13 (production). 

Transaction Security Policy Enhancements (Shield/Event Monitoring customers only): 

• Step-up authentication required when downloading >10,000 records from reports.
• Required for any create/update/delete/enable/disable operations on transaction security policies.
• Timeline: Available June 1 (sandbox), June 15 (production); Enforced June 22 (sandbox), July 13 (production). 

Additional Considerations

Mobile SDK Lockout Risk for Admins: Warning for admins using the Salesforce Mobile App or custom Mobile SDK apps. Mobile SDK version 13.2.0 and earlier does not support phishing-resistant MFA. Admins using these older versions will be blocked from logging in unless their org pre-configures advanced authentication in My Domain, or until they utilize the new “Login for Admins” browser-based flow arriving in Mobile SDK 13.2.1

Impact on “Waive MFA” Permission: Please note the exact behavior of the “Waive Multi-Factor Authentication for Exempt Users” permission. After enforcement, this permission will no longer automatically waive the MFA requirement; users with this permission will actually be prompted to enroll in MFA in the UI. To restore this exemption for valid testing/automation tools, admins must proactively contact Salesforce Support for approval.

Passwordless Login Recommendation: Please note the best-practice recommendation of enabling “Allow passwordless login with passkeys”. This allows users (especially privileged admins) to meet the strict phishing-resistant MFA requirement by simply logging in with their username and a biometric passkey or security key, bypassing the need for a password and streamlining their experience.

Trial Org Grace Period: Note that Trial Orgs converted to a paid subscription will no longer receive a 30-day grace period to comply with the MFA requirement.

MFA Edge Cases and Exceptions

Experience Cloud and Community users are completely exempt from this specific MFA login mandate. API-only users with the API-only permission assigned are exempt from MFA, as the requirement applies exclusively to UI logins. For Windows SSO, check the AMR field in login history for OIDC, or use the SAML Validator tool for SAML; ignore the strong/weak classification and only verify that the signal is present. Free scratch orgs are not in scope, as MFA enforcement applies only to paid sandbox orgs. When it comes to device activation, MFA takes precedence, and completing MFA exempts users from device activation prompts. Finally, custom IDPs must follow SAML/OIDC industry standards for passing AMR/ACR signals; contact your account team or support for provider-specific nuances.

Customer Communication Plan

Knowledge articles were published, you will find the links in this post. System administrators and security contacts received email notifications on the 6th of May, 2026. Product managers will be hosting webinars on Wednesday, May 13th, with both early and late US time slots available. For the early webinar time, click here. For the later time, click here.

Action Items

• Partners: Review client orgs for current VPN usage and MFA exemption permission assignments; prepare clients for June-August enforcement timelines. 
• Admins: Test MFA configurations in sandboxes starting June 22; ensure users have at least one verification method configured (email/SMS/authenticator). 
• SSO administrators: Verify AMR/ACR signals are being passed correctly using login history (OIDC) or SAML Validator tool (SAML). 
• Shield customers: Review transaction security policies and prepare for step-up authentication on report downloads >10,000 records and policy modifications. 
• All customers: Set up DKIM keys or authorized email domains; use in-app verification tool to check compliance. 

Don’t Wait for Enforcement to Find Your Gaps

Salesforce’s upcoming security enforcement represents a meaningful shift in how the platform approaches user protection. For years, the responsibility fell almost entirely on customers to configure and maintain their own security posture. That’s changing. Whether you’re an admin, developer, architect, or partner, the June through August enforcement windows are closer than they appear. Audit your orgs, test your configurations in sandbox, and make sure your users are set up with the right verification methods before enforcement kicks in. The friction is real, but so is the risk it’s designed to address. See the official Salesforce documentation here.

Explore related content:

Setup with Agentforce: What Salesforce Admins Need to Know

The Salesforce DKIM Sandbox Problem, and How to Fix It

Clean Data, Smart Flows: Automating Data Cleanup in Salesforce Nonprofit Cloud

Salesforce Is Tightening Security Across Every Org

How Salesforce Will Secure Your Org Against Hackers

Security and convenience are almost always inversely correlated. Making something more secure inherently makes it harder to access, which creates real friction for everyday users. This tension is nothing new. Hackers have always sought unauthorized access to systems, but historically, the barriers were high: computers were expensive and internet access was scarce. This is no longer true.

This battle front has always favored attackers. Security teams must successfully defend against every single intrusion attempt, while hackers only need to succeed once. A single breach can cause significant damage.

What’s changed is the scale and speed of attacks. AI has dramatically lowered the barrier to entry, enabling hackers to probe far more systems, far more frequently than ever before.

Recently, several Salesforce customers experienced significant system breaches involving their Salesforce instances, most notably those tied to the ShinyHunters cybercriminal group. What made these incidents particularly damaging was that the compromised accounts belonged to users with elevated access, including admins and developers. Salesforce denied responsibility and took limited action, largely confining its response to informing and educating the ecosystem about the risks of phishing and vishing attacks.

It seems like that is about to change. Big time.

Salesforce decided to enforce multiple security controls starting June-August 2026 to prevent credential theft, data exfiltration, and account takeovers. IP range restrictions originally planned are no longer being mandated, but MFA for all employee users, phishing-resistant MFA for admins, auto-containment for high-risk connections, and step-up authentication for reports will be enforced.

This means your life is about to get more difficult, especially if you have elevated access typically used by admins, developers and architects.

The New Security Direction by Salesforce

• MFA exemption permission restricted: The “Waive Multifactor Authentication for Exempt Users” permission will be removed except for justified cases (automation/testing users) requiring support approval. 
• New permission set required: “Modify Transaction Security Policy” permission set introduced. Users need both the new “Modify Transaction Security Policy” permission AND the existing “Customize Application” permission to manage TSPs. Users with only the Customize Application permission will be downgraded to read-only access for TSPs.
• IP range restriction enforcement removed: The requirement to use IP ranges on profiles and the “enforce login ranges on every request” setting will not be mandated, though strongly recommended for customers who can implement them.
• Staggered rollout approach: Enforcement timelines extended and staggered by instance to minimize customer disruption.

Security Controls Being Enforced

Auto-Containment Measures

High-risk IP blocking was expanded April 24th to include all connected app and API traffic from anonymizing VPNs, proxies, and high-risk IP addresses; users are contained automatically with admin notifications. Extended login anomaly containment applies to all internal user login behavior (excluding external/community users) and focuses on detecting suspicious login patterns. There is no allow-list override, meaning even allow-listed IP addresses will be contained if classified as high-risk at connection time. There are also AWS integration issues under active investigation, with some AWS IP addresses being incorrectly flagged and the issue currently being resolved.

MFA Requirements

All Employee Users: 

MFA is required for all employee license users, excluding Experience Cloud and external users. Enforcement is handled via locked settings, so admins cannot disable it. API-only logins are exempt, as the requirement applies exclusively to UI logins. For SSO, providers must pass AMR/ACR signals indicating strong or phishing-resistant MFA.

Timeline: Sandboxes June 22-29; Production July 20-August 17 

Admins and Privileged Users: 

Phishing-resistant MFA is required for users with elevated privileges, specifically those on the default Sys Admin profile or holding Modify All Data, View All Data, Customize Application, or Author Apex permissions. This standard is stricter than standard MFA, and mobile authenticator apps do not meet the threshold. Only security keys and built-in authenticators or passkeys qualify.

Timeline: Sandboxes June 22-29; Production July 1-27 

Email Domain Verification

DKIM or authorized email domain verification is required for all email sending domains (this was previously announced). Enforcement is being rolled out on a staggered timeline; check the timeline knowledge article for the latest dates. A tool is also available to verify compliance status.

Step-Up Authentication for Reports

Time-Based Session Policy:

• Additional authentication required when users spend considerable time on reports.
• Admins can configure the “Require step-up authentication within cool-down period” session-level policy to an exact cadence between 2 and 120 minutes (with 120 minutes being the default); logging in with MFA does not reset timer.
• Verification methods: Users can use any supported MFA method, including Passkeys, Security Keys, Salesforce Authenticator, and third-party TOTP apps. The email and SMS One-Time Password (OTP) options are specifically fallback challenges for Single Sign-On (SSO) users who do not have a Salesforce MFA method registered.
• Report access blocked if authentication fails (UI only, not API).
• Timeline: Available May 27 (sandbox/production); Enforced June 3 (sandbox), June 10-July 4 (production). 

Anomalous Behavior Detection: 

• ML-based detection triggers authentication when unusual report viewing/downloading behavior detected.
• Users must configure at least one verification method (authenticator app, phone, email) or report access blocked. 
• Timeline: Enforced June 22 (sandbox), July 13 (production). 

Transaction Security Policy Enhancements (Shield/Event Monitoring customers only): 

• Step-up authentication required when downloading >10,000 records from reports.
• Required for any create/update/delete/enable/disable operations on transaction security policies.
• Timeline: Available June 1 (sandbox), June 15 (production); Enforced June 22 (sandbox), July 13 (production). 

Additional Considerations

Mobile SDK Lockout Risk for Admins: Warning for admins using the Salesforce Mobile App or custom Mobile SDK apps. Mobile SDK version 13.2.0 and earlier does not support phishing-resistant MFA. Admins using these older versions will be blocked from logging in unless their org pre-configures advanced authentication in My Domain, or until they utilize the new “Login for Admins” browser-based flow arriving in Mobile SDK 13.2.1

Impact on “Waive MFA” Permission: Please note the exact behavior of the “Waive Multi-Factor Authentication for Exempt Users” permission. After enforcement, this permission will no longer automatically waive the MFA requirement; users with this permission will actually be prompted to enroll in MFA in the UI. To restore this exemption for valid testing/automation tools, admins must proactively contact Salesforce Support for approval.

Passwordless Login Recommendation: Please note the best-practice recommendation of enabling “Allow passwordless login with passkeys”. This allows users (especially privileged admins) to meet the strict phishing-resistant MFA requirement by simply logging in with their username and a biometric passkey or security key, bypassing the need for a password and streamlining their experience.

Trial Org Grace Period: Note that Trial Orgs converted to a paid subscription will no longer receive a 30-day grace period to comply with the MFA requirement.

MFA Edge Cases and Exceptions

Experience Cloud and Community users are completely exempt from this specific MFA login mandate. API-only users with the API-only permission assigned are exempt from MFA, as the requirement applies exclusively to UI logins. For Windows SSO, check the AMR field in login history for OIDC, or use the SAML Validator tool for SAML; ignore the strong/weak classification and only verify that the signal is present. Free scratch orgs are not in scope, as MFA enforcement applies only to paid sandbox orgs. When it comes to device activation, MFA takes precedence, and completing MFA exempts users from device activation prompts. Finally, custom IDPs must follow SAML/OIDC industry standards for passing AMR/ACR signals; contact your account team or support for provider-specific nuances.

Customer Communication Plan

Knowledge articles were published, you will find the links in this post. System administrators and security contacts received email notifications on the 6th of May, 2026. Product managers will be hosting webinars on Wednesday, May 13th, with both early and late US time slots available. For the early webinar time, click here. For the later time, click here.

Action Items

• Partners: Review client orgs for current VPN usage and MFA exemption permission assignments; prepare clients for June-August enforcement timelines. 
• Admins: Test MFA configurations in sandboxes starting June 22; ensure users have at least one verification method configured (email/SMS/authenticator). 
• SSO administrators: Verify AMR/ACR signals are being passed correctly using login history (OIDC) or SAML Validator tool (SAML). 
• Shield customers: Review transaction security policies and prepare for step-up authentication on report downloads >10,000 records and policy modifications. 
• All customers: Set up DKIM keys or authorized email domains; use in-app verification tool to check compliance. 

Don’t Wait for Enforcement to Find Your Gaps

Salesforce’s upcoming security enforcement represents a meaningful shift in how the platform approaches user protection. For years, the responsibility fell almost entirely on customers to configure and maintain their own security posture. That’s changing. Whether you’re an admin, developer, architect, or partner, the June through August enforcement windows are closer than they appear. Audit your orgs, test your configurations in sandbox, and make sure your users are set up with the right verification methods before enforcement kicks in. The friction is real, but so is the risk it’s designed to address. See the official Salesforce documentation here.

Explore related content:

Setup with Agentforce: What Salesforce Admins Need to Know

The Salesforce DKIM Sandbox Problem, and How to Fix It

Clean Data, Smart Flows: Automating Data Cleanup in Salesforce Nonprofit Cloud

Salesforce Is Tightening Security Across Every Org

How Salesforce Will Secure Your Org Against Hackers

Security and convenience are almost always inversely correlated. Making something more secure inherently makes it harder to access, which creates real friction for everyday users. This tension is nothing new. Hackers have always sought unauthorized access to systems, but historically, the barriers were high: computers were expensive and internet access was scarce. This is no longer true.

This battle front has always favored attackers. Security teams must successfully defend against every single intrusion attempt, while hackers only need to succeed once. A single breach can cause significant damage.

What’s changed is the scale and speed of attacks. AI has dramatically lowered the barrier to entry, enabling hackers to probe far more systems, far more frequently than ever before.

Recently, several Salesforce customers experienced significant system breaches involving their Salesforce instances, most notably those tied to the ShinyHunters cybercriminal group. What made these incidents particularly damaging was that the compromised accounts belonged to users with elevated access, including admins and developers. Salesforce denied responsibility and took limited action, largely confining its response to informing and educating the ecosystem about the risks of phishing and vishing attacks.

It seems like that is about to change. Big time.

Salesforce decided to enforce multiple security controls starting June-August 2026 to prevent credential theft, data exfiltration, and account takeovers. IP range restrictions originally planned are no longer being mandated, but MFA for all employee users, phishing-resistant MFA for admins, auto-containment for high-risk connections, and step-up authentication for reports will be enforced.

This means your life is about to get more difficult, especially if you have elevated access typically used by admins, developers and architects.

The New Security Direction by Salesforce

• MFA exemption permission restricted: The “Waive Multifactor Authentication for Exempt Users” permission will be removed except for justified cases (automation/testing users) requiring support approval. 
• New permission set required: “Modify Transaction Security Policy” permission set introduced. Users need both the new “Modify Transaction Security Policy” permission AND the existing “Customize Application” permission to manage TSPs. Users with only the Customize Application permission will be downgraded to read-only access for TSPs.
• IP range restriction enforcement removed: The requirement to use IP ranges on profiles and the “enforce login ranges on every request” setting will not be mandated, though strongly recommended for customers who can implement them.
• Staggered rollout approach: Enforcement timelines extended and staggered by instance to minimize customer disruption.

Security Controls Being Enforced

Auto-Containment Measures

High-risk IP blocking was expanded April 24th to include all connected app and API traffic from anonymizing VPNs, proxies, and high-risk IP addresses; users are contained automatically with admin notifications. Extended login anomaly containment applies to all internal user login behavior (excluding external/community users) and focuses on detecting suspicious login patterns. There is no allow-list override, meaning even allow-listed IP addresses will be contained if classified as high-risk at connection time. There are also AWS integration issues under active investigation, with some AWS IP addresses being incorrectly flagged and the issue currently being resolved.

MFA Requirements

All Employee Users: 

MFA is required for all employee license users, excluding Experience Cloud and external users. Enforcement is handled via locked settings, so admins cannot disable it. API-only logins are exempt, as the requirement applies exclusively to UI logins. For SSO, providers must pass AMR/ACR signals indicating strong or phishing-resistant MFA.

Timeline: Sandboxes June 22-29; Production July 20-August 17 

Admins and Privileged Users: 

Phishing-resistant MFA is required for users with elevated privileges, specifically those on the default Sys Admin profile or holding Modify All Data, View All Data, Customize Application, or Author Apex permissions. This standard is stricter than standard MFA, and mobile authenticator apps do not meet the threshold. Only security keys and built-in authenticators or passkeys qualify.

Timeline: Sandboxes June 22-29; Production July 1-27 

Email Domain Verification

DKIM or authorized email domain verification is required for all email sending domains (this was previously announced). Enforcement is being rolled out on a staggered timeline; check the timeline knowledge article for the latest dates. A tool is also available to verify compliance status.

Step-Up Authentication for Reports

Time-Based Session Policy:

• Additional authentication required when users spend considerable time on reports.
• Admins can configure the “Require step-up authentication within cool-down period” session-level policy to an exact cadence between 2 and 120 minutes (with 120 minutes being the default); logging in with MFA does not reset timer.
• Verification methods: Users can use any supported MFA method, including Passkeys, Security Keys, Salesforce Authenticator, and third-party TOTP apps. The email and SMS One-Time Password (OTP) options are specifically fallback challenges for Single Sign-On (SSO) users who do not have a Salesforce MFA method registered.
• Report access blocked if authentication fails (UI only, not API).
• Timeline: Available May 27 (sandbox/production); Enforced June 3 (sandbox), June 10-July 4 (production). 

Anomalous Behavior Detection: 

• ML-based detection triggers authentication when unusual report viewing/downloading behavior detected.
• Users must configure at least one verification method (authenticator app, phone, email) or report access blocked. 
• Timeline: Enforced June 22 (sandbox), July 13 (production). 

Transaction Security Policy Enhancements (Shield/Event Monitoring customers only): 

• Step-up authentication required when downloading >10,000 records from reports.
• Required for any create/update/delete/enable/disable operations on transaction security policies.
• Timeline: Available June 1 (sandbox), June 15 (production); Enforced June 22 (sandbox), July 13 (production). 

Additional Considerations

Mobile SDK Lockout Risk for Admins: Warning for admins using the Salesforce Mobile App or custom Mobile SDK apps. Mobile SDK version 13.2.0 and earlier does not support phishing-resistant MFA. Admins using these older versions will be blocked from logging in unless their org pre-configures advanced authentication in My Domain, or until they utilize the new “Login for Admins” browser-based flow arriving in Mobile SDK 13.2.1

Impact on “Waive MFA” Permission: Please note the exact behavior of the “Waive Multi-Factor Authentication for Exempt Users” permission. After enforcement, this permission will no longer automatically waive the MFA requirement; users with this permission will actually be prompted to enroll in MFA in the UI. To restore this exemption for valid testing/automation tools, admins must proactively contact Salesforce Support for approval.

Passwordless Login Recommendation: Please note the best-practice recommendation of enabling “Allow passwordless login with passkeys”. This allows users (especially privileged admins) to meet the strict phishing-resistant MFA requirement by simply logging in with their username and a biometric passkey or security key, bypassing the need for a password and streamlining their experience.

Trial Org Grace Period: Note that Trial Orgs converted to a paid subscription will no longer receive a 30-day grace period to comply with the MFA requirement.

MFA Edge Cases and Exceptions

Experience Cloud and Community users are completely exempt from this specific MFA login mandate. API-only users with the API-only permission assigned are exempt from MFA, as the requirement applies exclusively to UI logins. For Windows SSO, check the AMR field in login history for OIDC, or use the SAML Validator tool for SAML; ignore the strong/weak classification and only verify that the signal is present. Free scratch orgs are not in scope, as MFA enforcement applies only to paid sandbox orgs. When it comes to device activation, MFA takes precedence, and completing MFA exempts users from device activation prompts. Finally, custom IDPs must follow SAML/OIDC industry standards for passing AMR/ACR signals; contact your account team or support for provider-specific nuances.

Customer Communication Plan

Knowledge articles were published, you will find the links in this post. System administrators and security contacts received email notifications on the 6th of May, 2026. Product managers will be hosting webinars on Wednesday, May 13th, with both early and late US time slots available. For the early webinar time, click here. For the later time, click here.

Action Items

• Partners: Review client orgs for current VPN usage and MFA exemption permission assignments; prepare clients for June-August enforcement timelines. 
• Admins: Test MFA configurations in sandboxes starting June 22; ensure users have at least one verification method configured (email/SMS/authenticator). 
• SSO administrators: Verify AMR/ACR signals are being passed correctly using login history (OIDC) or SAML Validator tool (SAML). 
• Shield customers: Review transaction security policies and prepare for step-up authentication on report downloads >10,000 records and policy modifications. 
• All customers: Set up DKIM keys or authorized email domains; use in-app verification tool to check compliance. 

Don’t Wait for Enforcement to Find Your Gaps

Salesforce’s upcoming security enforcement represents a meaningful shift in how the platform approaches user protection. For years, the responsibility fell almost entirely on customers to configure and maintain their own security posture. That’s changing. Whether you’re an admin, developer, architect, or partner, the June through August enforcement windows are closer than they appear. Audit your orgs, test your configurations in sandbox, and make sure your users are set up with the right verification methods before enforcement kicks in. The friction is real, but so is the risk it’s designed to address. See the official Salesforce documentation here.

Explore related content:

Setup with Agentforce: What Salesforce Admins Need to Know

The Salesforce DKIM Sandbox Problem, and How to Fix It

Clean Data, Smart Flows: Automating Data Cleanup in Salesforce Nonprofit Cloud

Salesforce Is Tightening Security Across Every Org

Beyond the URL Button: The Salesforce Request Approval Lightning Component

Are you finding that as your company grows, the complexity of your approval workflows grows along with it? What once might have been a simple sign-off from a single manager can quickly transform into a multi-step process involving input from multiple departments, stakeholders, and even external partners. This complexity often leads to delays, inefficiencies, and frustration as approvals get stuck in bottlenecks or lost in email chains.

Salesforce’s free Flow Approval Processes, built on Flow Orchestrator, automate even the most intricate workflows. A previous post explored launching these Autolaunched Approval Orchestrations via a custom URL button. Today, we are taking that functionality a massive step forward. We will explore the new Request Approval Lightning component and its tie-in to autolaunched flow functionality. This component expands automation by allowing dynamic user inputs directly from the record page.

The Foundation: Autolaunched Flow Approvals

Before diving into the new component, let’s quickly recap how autolaunched flow approvals function. When you build an autolaunched approval process, you are essentially building an autolaunched automation that can be executed on demand, very similar to an autolaunched Orchestration or flow. However, the traditional method of launching Salesforce automations (the quick action button) has strict limitations. Quick actions can only be used to add an active screen flow to the page layout; orchestrations are simply not supported. Furthermore, quick actions do not allow you to pass additional input parameter values into your automation beyond the standard recordId.

Because of these limitations, the standard workaround has been to build an autolaunched Approval Orchestration and assign it to a custom URL button on the page layout. For example, a common use case is to escalate a case to a queue of level 2 experts when a second opinion is required. By appending variables to the custom URL, such as ?recordId={!Case.Id}&submitter={!$User.Id}&retURL={!Case.Id}, administrators could successfully pass the necessary parameters to kick off the orchestration. While highly effective, this URL button method is a bit rigid. It automatically submits the record based on predefined flow logic without giving the submitter much runtime flexibility.

Enter the Request Approval Lightning Component

This is where the new Request Approval component completely changes the game. Instead of relying on a custom URL button to trigger your background orchestration, you can now add a native, user-friendly interface directly to your Lightning record pages. This component bridges the gap between the UI of a screen flow and the processing power of an autolaunched orchestration.

To utilize this feature, you must first design, test, and activate an autolaunched flow approval process. Once your flow is ready, you can simply open the record page where you want to place the component. Click the gear icon on the navigation bar, and select Edit Page to open the Lightning App Builder. From the Components tab, search for “Request” and drag the Request Approval component directly onto the layout.

Straightforward Setup

You can customize the title of the component to display user-friendly text at run time. Then search for and select your active, autolaunched flow approval process to run whenever the user clicks the “Start” button. You can also assign a specific label to identify the associated flow approval process to your users.

Expanding the Use Case: What Can Be Added?

So, how exactly does this new component expand the capabilities of your autolaunched flow use cases? The true power of the Request Approval component lies in its ability to gather critical, dynamic inputs directly from the submitter at the exact moment of submission. When using the old custom URL button method, the approver destination (such as the Level 2 expert queue) was hardcoded into the flow steps. With the new component, you can dramatically increase the flexibility of your processes through two main enhancements:

Dynamic Approver Selection

The component allows you to require submitters to actively select an approver before the flow runs. To enable this, you must configure your underlying autolaunched flow approval process to assign one or more approval steps to a specific resource named firstApprover. In the Lightning App Builder, you then select the Require submitter to select an approver setting.

It is critical to ensure your flow is properly configured to accept this input. Consider whether the flow approval process you selected assigns one or more steps to the firstApprover resource. If it does, you must select this requirement on the component to prevent the flow approval process from failing when a submitter attempts to use it. This means a single autolaunched flow can now be routed to entirely different managers, departments, or external stakeholders on the fly.

Submission Comments

Another massive expansion of your use case is the ability to capture submission comments. Often, an approver needs context as to why a record is being submitted. The Request Approval component shows an Approval Request Comments field by default. This exposes optional submitter comments directly to the approvers via the submissionComments resource.

If your business process dictates that comments are unnecessary, or if you want to streamline the UI to prevent the submitter from adding comments about a submission, you easily have the option to select Hide submitter comments within the component configuration. These comments are stored cleanly in the new data model under the Approval Submissions object, specifically within the Comments field, making them accessible via queries if you wish to display them in custom approver screen flows.

The Impact on Your Org’s Architecture

By tying the Request Approval component to your autolaunched orchestrations, you unlock a highly scalable and flexible architecture. You no longer need to build dozens of slightly different flows for different queues or approvers. Instead, you can rely on a single autolaunched flow that dynamically adapts based on the firstApprover and submissionComments variables passed from the component.

This ties seamlessly into the broader Flow Approval Process ecosystem. Once submitted, the process still leverages the brand-new UI and audit trail, including the Approvals Lightning app, Approval Submissions, and Approval Work Items. The orchestration sequences stages and steps behind the scenes. It potentially triggers automated background steps like updating records or sending notifications without requiring further user interaction. Approvers still receive their email notifications with links to the Work Guide, and they can still reply directly to the emails with keywords like “Approve” or “Reject” to complete their action. Furthermore, administrators must still remember to add the Flow Orchestration Work Guide component to the record page. It approvers have a centralized interface to actually interact with the assigned approval step.

It is important no note that this component allows the user to recall the approval process once it is started.

Conclusion

The Request Approval component takes the Autolaunched Flow Approval Process and makes it more dynamic and user-centric. By moving away from static URL buttons and embracing this native Lightning component, administrators can empower their users to select appropriate approvers and provide vital context through comments. All while leveraging the free, robust automation engine of Salesforce Flow Orchestrator.

Whether you are routing cases to level 2 experts or managing multi-million dollar contracts, this functionality ensures your approval workflows are as efficient, user-friendly as possible. Save and activate your record page layout, exit the Lightning App Builder, and watch your new approval processes in action.

[youtube https://www.youtube.com/watch?v=8AlAsH7qb68?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent&w=640&h=360]

Explore related content:

How to Build Custom Flow Approval Submission Related Lists

Start Autolaunched Flow Approvals From A Button

Supercharge Your Approvals with Salesforce Flow Approval Processes

Beyond the URL Button: The Salesforce Request Approval Lightning Component

Are you finding that as your company grows, the complexity of your approval workflows grows along with it? What once might have been a simple sign-off from a single manager can quickly transform into a multi-step process involving input from multiple departments, stakeholders, and even external partners. This complexity often leads to delays, inefficiencies, and frustration as approvals get stuck in bottlenecks or lost in email chains.

Salesforce’s free Flow Approval Processes, built on Flow Orchestrator, automate even the most intricate workflows. A previous post explored launching these Autolaunched Approval Orchestrations via a custom URL button. Today, we are taking that functionality a massive step forward. We will explore the new Request Approval Lightning component and its tie-in to autolaunched flow functionality. This component expands automation by allowing dynamic user inputs directly from the record page.

The Foundation: Autolaunched Flow Approvals

Before diving into the new component, let’s quickly recap how autolaunched flow approvals function. When you build an autolaunched approval process, you are essentially building an autolaunched automation that can be executed on demand, very similar to an autolaunched Orchestration or flow. However, the traditional method of launching Salesforce automations (the quick action button) has strict limitations. Quick actions can only be used to add an active screen flow to the page layout; orchestrations are simply not supported. Furthermore, quick actions do not allow you to pass additional input parameter values into your automation beyond the standard recordId.

Because of these limitations, the standard workaround has been to build an autolaunched Approval Orchestration and assign it to a custom URL button on the page layout. For example, a common use case is to escalate a case to a queue of level 2 experts when a second opinion is required. By appending variables to the custom URL, such as ?recordId={!Case.Id}&submitter={!$User.Id}&retURL={!Case.Id}, administrators could successfully pass the necessary parameters to kick off the orchestration. While highly effective, this URL button method is a bit rigid. It automatically submits the record based on predefined flow logic without giving the submitter much runtime flexibility.

Enter the Request Approval Lightning Component

This is where the new Request Approval component completely changes the game. Instead of relying on a custom URL button to trigger your background orchestration, you can now add a native, user-friendly interface directly to your Lightning record pages. This component bridges the gap between the UI of a screen flow and the processing power of an autolaunched orchestration.

To utilize this feature, you must first design, test, and activate an autolaunched flow approval process. Once your flow is ready, you can simply open the record page where you want to place the component. Click the gear icon on the navigation bar, and select Edit Page to open the Lightning App Builder. From the Components tab, search for “Request” and drag the Request Approval component directly onto the layout.

Straightforward Setup

You can customize the title of the component to display user-friendly text at run time. Then search for and select your active, autolaunched flow approval process to run whenever the user clicks the “Start” button. You can also assign a specific label to identify the associated flow approval process to your users.

Expanding the Use Case: What Can Be Added?

So, how exactly does this new component expand the capabilities of your autolaunched flow use cases? The true power of the Request Approval component lies in its ability to gather critical, dynamic inputs directly from the submitter at the exact moment of submission. When using the old custom URL button method, the approver destination (such as the Level 2 expert queue) was hardcoded into the flow steps. With the new component, you can dramatically increase the flexibility of your processes through two main enhancements:

Dynamic Approver Selection

The component allows you to require submitters to actively select an approver before the flow runs. To enable this, you must configure your underlying autolaunched flow approval process to assign one or more approval steps to a specific resource named firstApprover. In the Lightning App Builder, you then select the Require submitter to select an approver setting.

It is critical to ensure your flow is properly configured to accept this input. Consider whether the flow approval process you selected assigns one or more steps to the firstApprover resource. If it does, you must select this requirement on the component to prevent the flow approval process from failing when a submitter attempts to use it. This means a single autolaunched flow can now be routed to entirely different managers, departments, or external stakeholders on the fly.

Submission Comments

Another massive expansion of your use case is the ability to capture submission comments. Often, an approver needs context as to why a record is being submitted. The Request Approval component shows an Approval Request Comments field by default. This exposes optional submitter comments directly to the approvers via the submissionComments resource.

If your business process dictates that comments are unnecessary, or if you want to streamline the UI to prevent the submitter from adding comments about a submission, you easily have the option to select Hide submitter comments within the component configuration. These comments are stored cleanly in the new data model under the Approval Submissions object, specifically within the Comments field, making them accessible via queries if you wish to display them in custom approver screen flows.

The Impact on Your Org’s Architecture

By tying the Request Approval component to your autolaunched orchestrations, you unlock a highly scalable and flexible architecture. You no longer need to build dozens of slightly different flows for different queues or approvers. Instead, you can rely on a single autolaunched flow that dynamically adapts based on the firstApprover and submissionComments variables passed from the component.

This ties seamlessly into the broader Flow Approval Process ecosystem. Once submitted, the process still leverages the brand-new UI and audit trail, including the Approvals Lightning app, Approval Submissions, and Approval Work Items. The orchestration sequences stages and steps behind the scenes. It potentially triggers automated background steps like updating records or sending notifications without requiring further user interaction. Approvers still receive their email notifications with links to the Work Guide, and they can still reply directly to the emails with keywords like “Approve” or “Reject” to complete their action. Furthermore, administrators must still remember to add the Flow Orchestration Work Guide component to the record page. It approvers have a centralized interface to actually interact with the assigned approval step.

It is important no note that this component allows the user to recall the approval process once it is started.

Conclusion

The Request Approval component takes the Autolaunched Flow Approval Process and makes it more dynamic and user-centric. By moving away from static URL buttons and embracing this native Lightning component, administrators can empower their users to select appropriate approvers and provide vital context through comments. All while leveraging the free, robust automation engine of Salesforce Flow Orchestrator.

Whether you are routing cases to level 2 experts or managing multi-million dollar contracts, this functionality ensures your approval workflows are as efficient, user-friendly as possible. Save and activate your record page layout, exit the Lightning App Builder, and watch your new approval processes in action.

[youtube https://www.youtube.com/watch?v=8AlAsH7qb68?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent&w=640&h=360]

Explore related content:

How to Build Custom Flow Approval Submission Related Lists

Start Autolaunched Flow Approvals From A Button

Supercharge Your Approvals with Salesforce Flow Approval Processes

Beyond the URL Button: The Salesforce Request Approval Lightning Component

Are you finding that as your company grows, the complexity of your approval workflows grows along with it? What once might have been a simple sign-off from a single manager can quickly transform into a multi-step process involving input from multiple departments, stakeholders, and even external partners. This complexity often leads to delays, inefficiencies, and frustration as approvals get stuck in bottlenecks or lost in email chains.

Salesforce’s free Flow Approval Processes, built on Flow Orchestrator, automate even the most intricate workflows. A previous post explored launching these Autolaunched Approval Orchestrations via a custom URL button. Today, we are taking that functionality a massive step forward. We will explore the new Request Approval Lightning component and its tie-in to autolaunched flow functionality. This component expands automation by allowing dynamic user inputs directly from the record page.

The Foundation: Autolaunched Flow Approvals

Before diving into the new component, let’s quickly recap how autolaunched flow approvals function. When you build an autolaunched approval process, you are essentially building an autolaunched automation that can be executed on demand, very similar to an autolaunched Orchestration or flow. However, the traditional method of launching Salesforce automations (the quick action button) has strict limitations. Quick actions can only be used to add an active screen flow to the page layout; orchestrations are simply not supported. Furthermore, quick actions do not allow you to pass additional input parameter values into your automation beyond the standard recordId.

Because of these limitations, the standard workaround has been to build an autolaunched Approval Orchestration and assign it to a custom URL button on the page layout. For example, a common use case is to escalate a case to a queue of level 2 experts when a second opinion is required. By appending variables to the custom URL, such as ?recordId={!Case.Id}&submitter={!$User.Id}&retURL={!Case.Id}, administrators could successfully pass the necessary parameters to kick off the orchestration. While highly effective, this URL button method is a bit rigid. It automatically submits the record based on predefined flow logic without giving the submitter much runtime flexibility.

Enter the Request Approval Lightning Component

This is where the new Request Approval component completely changes the game. Instead of relying on a custom URL button to trigger your background orchestration, you can now add a native, user-friendly interface directly to your Lightning record pages. This component bridges the gap between the UI of a screen flow and the processing power of an autolaunched orchestration.

To utilize this feature, you must first design, test, and activate an autolaunched flow approval process. Once your flow is ready, you can simply open the record page where you want to place the component. Click the gear icon on the navigation bar, and select Edit Page to open the Lightning App Builder. From the Components tab, search for “Request” and drag the Request Approval component directly onto the layout.

Straightforward Setup

You can customize the title of the component to display user-friendly text at run time. Then search for and select your active, autolaunched flow approval process to run whenever the user clicks the “Start” button. You can also assign a specific label to identify the associated flow approval process to your users.

Expanding the Use Case: What Can Be Added?

So, how exactly does this new component expand the capabilities of your autolaunched flow use cases? The true power of the Request Approval component lies in its ability to gather critical, dynamic inputs directly from the submitter at the exact moment of submission. When using the old custom URL button method, the approver destination (such as the Level 2 expert queue) was hardcoded into the flow steps. With the new component, you can dramatically increase the flexibility of your processes through two main enhancements:

Dynamic Approver Selection

The component allows you to require submitters to actively select an approver before the flow runs. To enable this, you must configure your underlying autolaunched flow approval process to assign one or more approval steps to a specific resource named firstApprover. In the Lightning App Builder, you then select the Require submitter to select an approver setting.

It is critical to ensure your flow is properly configured to accept this input. Consider whether the flow approval process you selected assigns one or more steps to the firstApprover resource. If it does, you must select this requirement on the component to prevent the flow approval process from failing when a submitter attempts to use it. This means a single autolaunched flow can now be routed to entirely different managers, departments, or external stakeholders on the fly.

Submission Comments

Another massive expansion of your use case is the ability to capture submission comments. Often, an approver needs context as to why a record is being submitted. The Request Approval component shows an Approval Request Comments field by default. This exposes optional submitter comments directly to the approvers via the submissionComments resource.

If your business process dictates that comments are unnecessary, or if you want to streamline the UI to prevent the submitter from adding comments about a submission, you easily have the option to select Hide submitter comments within the component configuration. These comments are stored cleanly in the new data model under the Approval Submissions object, specifically within the Comments field, making them accessible via queries if you wish to display them in custom approver screen flows.

The Impact on Your Org’s Architecture

By tying the Request Approval component to your autolaunched orchestrations, you unlock a highly scalable and flexible architecture. You no longer need to build dozens of slightly different flows for different queues or approvers. Instead, you can rely on a single autolaunched flow that dynamically adapts based on the firstApprover and submissionComments variables passed from the component.

This ties seamlessly into the broader Flow Approval Process ecosystem. Once submitted, the process still leverages the brand-new UI and audit trail, including the Approvals Lightning app, Approval Submissions, and Approval Work Items. The orchestration sequences stages and steps behind the scenes. It potentially triggers automated background steps like updating records or sending notifications without requiring further user interaction. Approvers still receive their email notifications with links to the Work Guide, and they can still reply directly to the emails with keywords like “Approve” or “Reject” to complete their action. Furthermore, administrators must still remember to add the Flow Orchestration Work Guide component to the record page. It approvers have a centralized interface to actually interact with the assigned approval step.

It is important no note that this component allows the user to recall the approval process once it is started.

Conclusion

The Request Approval component takes the Autolaunched Flow Approval Process and makes it more dynamic and user-centric. By moving away from static URL buttons and embracing this native Lightning component, administrators can empower their users to select appropriate approvers and provide vital context through comments. All while leveraging the free, robust automation engine of Salesforce Flow Orchestrator.

Whether you are routing cases to level 2 experts or managing multi-million dollar contracts, this functionality ensures your approval workflows are as efficient, user-friendly as possible. Save and activate your record page layout, exit the Lightning App Builder, and watch your new approval processes in action.

[youtube https://www.youtube.com/watch?v=8AlAsH7qb68?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent&w=640&h=360]

Explore related content:

How to Build Custom Flow Approval Submission Related Lists

Start Autolaunched Flow Approvals From A Button

Supercharge Your Approvals with Salesforce Flow Approval Processes