🔥 Keep Users on One Flow Screen with Auto-Triggered Screen Actions – Now GA!

Salesforce Flow just got a major UX upgrade! With the new Automatically Triggered Screen Actions, you can now build screen flows that respond instantly to user input — without forcing users to click Next or navigate away from the screen.

This feature is now Generally Available, and it’s a game-changer for Salesforce Admins and Developers building interactive flows.

---

✨ What’s New?

Automatically Triggered Screen Actions let you:

• Run autolaunched flows in the background based on user interaction.
• Show real-time updates on the same screen – no page jumps.
• Improve performance by running logic only when needed.

Think of it like building React-like interactivity in Flow – but declaratively!

---

🎯 Real-World Use Case

Let’s say you’re building a Donation Calculator Flow in Nonprofit Cloud:

• The donor enters their donation amount.
• Based on their input, you want to auto-calculate gift impact, eligible campaigns, or show matching gift suggestions — without another screen.
• Now, with screen actions, as soon as the user enters the amount, your logic runs behind the scenes and updates relevant fields or messages right away.

---

⚙️ How to Use It

1. In your Screen Flow, open a screen element.
2. Scroll to the new “Configure Screen Actions” section.
3. Select an Autolaunched Flow to run as the screen action.
4. Define:
   • Run settings: e.g. Run on screen load or only on first load.
   • Run conditions: e.g. Run when “Donation Amount” is not blank.

💡 Pro Tip:

Always use run conditions smartly — this not only enhances performance but also avoids excessive flow execution that could slow down user interaction.

---

🔍 Where This Works

• Only in Lightning runtime (not Classic runtime).
• Editions: Essentials, Professional, Enterprise, Performance, Unlimited, Developer.
• Available in both Lightning Experience and Salesforce Classic (where supported).

---

🚀 Why This Matters

This upgrade allows you to:

• Minimize the number of screens.
• Deliver instant feedback to users.
• Create flows that feel smarter and faster.

🎨 Keep Up with the Latest SLDS Validator Enhancements – Cleaner Code, Faster UI Compliance!

If you’re building Lightning Web Components or Aura Components, chances are you’ve struggled at some point with keeping your UI SLDS-compliant. That’s where the SLDS Validator steps in — and now it’s even better!

---

🛠️ What Is SLDS Validator?

The SLDS Validator is a Visual Studio Code extension that helps you:

• ✅ Scan your HTML & CSS for SLDS guideline violations
• 💡 Get real-time suggestions to fix issues
• ⚡ Use auto-fix to clean up your code faster

Think of it like a linter, but specifically for Salesforce Lightning Design System!

---

📍 Where to Get It

• 🔗 Download from Visual Studio Marketplace
• Updates are rolled out regularly, so make sure to check the changelog to stay current.

---

🚀 What’s New?

With every release, the validator improves its rule set and auto-fix logic.

Here’s what you can expect in recent updates:

• Better validation of grid systems and utility classes
• Smarter suggestions for markup structure
• Enhanced auto-fix for commonly misused SLDS classes

🧠 Abhi’s Tip: Pair this with Prettier or ESLint in your VS Code workspace to enforce both SLDS and coding best practices in your projects.

---

📦 How to Use It

1. Install the Extension from VS Code Marketplace.
2. Open your LWC or Aura component files.
3. The extension will:
   • Highlight non-compliant SLDS usage.
   • Offer quick-fix actions.
   • Suggest proper SLDS alternatives.
4. Use the command palette (Ctrl + Shift + P → “SLDS: Validate Current File”) to run it manually too.

---

🎯 Why Use It?

• 🧹 Cleaner, consistent UI aligned with Salesforce standards
• 🛡️ Reduces risk of styling issues post-deployment
• 🧪 Improves accessibility and responsiveness
• 🧑‍🤝‍🧑 Keeps your components “future-proof” with Salesforce updates

---

✅ Ideal For:

• LWC & Aura developers
• Admins customizing components
• QA reviewing UI consistency
• Anyone contributing to a Salesforce design system

---

💬 From Abhi:
“If you want your components to look good, behave well, and stay Salesforce-safe — SLDS Validator should be a default part of your dev toolkit.”

🚨 Update Your Lightning Components to SLDS 2 Using SLDS Linter (Beta)

Salesforce is taking UI consistency to the next level with SLDS 2, and now you have a new tool to help you get there: the SLDS Linter (Beta).

Whether you’re maintaining old Aura components or scaling your LWC projects, SLDS Linter helps uplift your code to meet the latest Lightning Design System standards — quickly and in bulk!

---

🔍 What’s SLDS Linter?

The SLDS Linter (Beta) is a command-line tool that:

• 🔎 Scans your component markup
• 💡 Suggests updates based on SLDS 2 Beta guidelines
• ⚡ Automatically fixes your code (even in bulk!)

✅ Designed to modernize your Lightning UI stack
✅ Works without needing VS Code (unlike SLDS Validator)

---

⚙️ Key Features vs SLDS Validator

Feature	SLDS Linter (Beta)	SLDS Validator (Stable)
SLDS Version Support	SLDS 2 (Beta)	SLDS 1
Tool Type	CLI	VS Code Extension
Auto-Fix Support	✅ Bulk Auto-Fix	✅ Single-file Fixes
Setup	Very lightweight	Requires VS Code Extension
Target Audience	Teams, CI/CD pipelines	Individual Dev workflows

---

💡 Why It Matters

If you’re:

• Migrating to SLDS 2
• Cleaning up legacy LWC/Aura code
• Enforcing consistent UI at scale

Then SLDS Linter is your best friend. It helps ensure your entire repo complies with the latest Salesforce UI guidelines — with minimal manual effort.

---

🚀 How to Get Started

1. 📥 Clone or install from GitHub:
   🔗 SLDS Linter GitHub Repository
2. 🛠️ Run the linter in your project folder: bashCopyEditnpx slds-linter scan src/
3. 🧹 Fix your code automatically: bashCopyEditnpx slds-linter fix src/
4. ✅ Done! Your markup is now SLDS 2–ready.

---

⚠️ A Word on Beta Use

📌 Note:
SLDS 2 and SLDS Linter are in beta, and usage is governed by Salesforce’s Beta Services Terms. Use them at your discretion and test thoroughly in dev/sandbox environments.

---

💬 From Abhi:
“If you’re serious about upgrading your Salesforce UI to the next-gen experience, the SLDS Linter is a must. Use it in your pre-commit hooks, CI/CD pipelines, or one-time code cleanups. The faster you align with SLDS 2, the better your apps will perform — and look!”

🔍 Discover Your Platform Event Batch Size and User — Now Visible in Setup!

Great news for developers working with Platform Events! You no longer need to rely on Tooling API or Metadata API to discover who’s running your trigger and at what batch size — Salesforce has made this visible directly in Setup.

---

✅ What’s New?

You can now view:

• 👤 User under which the Apex Platform Event Trigger runs

This information appears in the UI under the Subscriptions related list of a Platform Event — making your debugging and optimization work way easier.

---

🧠 Why This Matters

Previously, this was only accessible through:

• Tooling API (PlatformEventSubscriberConfig)
• Metadata API
• Or your deployment scripts

But now, it’s:

• Click-and-check inside Setup UI
• Ideal for quick audits and platform diagnostics
• Great for understanding event delivery behavior in high-volume orgs

🛠 How to Access It

1. Go to Setup
2. In Quick Find, type and click Platform Events
3. Select your event (e.g., Donation_Event__e)
4. Scroll to the Subscriptions related list
5. 🔍 Check the new Batch Size and User columns

---

👨‍💻 Use Case: Debugging Apex Trigger Behavior

Imagine you’re troubleshooting why a Platform Event Apex Trigger isn’t processing as expected. Now you can:

• See if the batch size is too low for high-volume events.
• Confirm the running user to verify they have the right field/object permissions.

No API queries needed — it’s all right there in Setup.

---

📦 Where This Works

• ✅ Lightning Experience & Salesforce Classic
• Editions: Enterprise, Performance, Unlimited, Developer

---

💬 From Abhi:
“This is a small but powerful upgrade for Platform Event monitoring. Especially for ISVs or large-scale event-driven apps — visibility like this saves hours of manual digging.”

❓ Can You Change the Batch Size from Setup?

No — you cannot change the batch size directly in the Setup UI.

---

🛠️ So How Can You Change the Batch Size?

To update the batch size, you need to use Metadata API or Tooling API by modifying the PlatformEventSubscriberConfig.

Here’s how you can do it:

✅ Option 1: Use Metadata API via SFDX or VS Code

1. Retrieve the metadata for PlatformEventSubscriberConfig.
2. Update the <batchSize> tag.
3. Deploy the updated metadata.

<PlatformEventSubscriberConfig>
    <eventName>Your_Event__e</eventName>
    <subscriberType>ApexTrigger</subscriberType>
    <batchSize>200</batchSize> <!-- Set your desired batch size -->
</PlatformEventSubscriberConfig>

✅ Option 2: Use Tooling API (Advanced)

• You can issue a PATCH request to the PlatformEventSubscriberConfig object.
• Example using Workbench or a REST tool like Postman.

---

📌 Batch Size Limits

• Default: 200
• Minimum: 1
• Maximum: 2,000

Choose based on your event volume and how your Apex trigger handles data (e.g., CPU limits, DML per batch).

---

💡 Abhi’s Tip:

If you frequently adjust this for different environments, consider scripting it in your CI/CD pipeline using SFDX metadata deployments.

⚠️ JSON Serialization for Exception Types Has Changed (API v63.0+)

If your Apex code serializes custom or system exceptions into JSON, Salesforce just introduced a critical change in API version 63.0 that you need to know.

---

🚫 What’s Changed?

Starting in API v63.0:

• Apex no longer allows JSON serialization of exceptions — including custom exceptions and most built-in exceptions.
• Trying to serialize an exception now throws: System.JSONException: Type unsupported in JSON: MyException

---

💡 Why This Matters

Before this change (API v62.0 and earlier), you could serialize exceptions:

apexCopyEditMyException e = new MyException('Something went wrong');
String jsonStr = JSON.serialize(e); // ✅ Worked before (incompletely)

But that behavior:

• Was incomplete
• Could lead to serialization errors
• Didn’t serialize the full stack trace or useful data reliably

Now, Salesforce is enforcing stricter behavior to prevent developers from relying on unsafe or unstable serialization patterns.

---

🔍 API Version Scope

• Applies to all editions
• Change starts from API version 63.0
• Legacy behavior (incomplete serialization) still works in API 62.0 or lower

---

🔁 Should You Downgrade API Version?

No — not recommended.
While you can technically avoid the error by keeping your class or trigger at API v62.0 or earlier, it’s better to:

• Migrate to safe serialization patterns
• Avoid brittle exception-object serialization altogether

💬 From Abhi: “Instead of serializing raw exceptions, create a custom wrapper for logging, auditing, or API error messages. It’s safer, cleaner, and won’t break across API versions.”

public class ExceptionLog {
    public String message;
    public String exceptionType;
    public String stackTrace;
    
    public ExceptionLog(Exception e) {
        this.message = e.getMessage();
        this.exceptionType = e.getTypeName();
        this.stackTrace = e.getStackTraceString();
    }
}

// Usage
try {
    // Some logic
} catch (Exception e) {
    ExceptionLog log = new ExceptionLog(e);
    String json = JSON.serialize(log); // ✅ Safe and supported
}

⏸️ Pause and ▶️ Resume Scheduled Jobs Programmatically in Apex (Summer ’25)

Salesforce just gave Apex developers new powers in Summer ’25 — you can now pause and resume scheduled jobs directly from code!

If you’re managing automation-heavy orgs, complex retry logic, or scheduled jobs in regulated environments, this is a super useful enhancement.

---

🚀 What’s New?

The System class now includes four new methods:

• System.pauseJobByName(jobName)
• System.pauseJobById(cronTriggerId)
• System.resumeJobByName(jobName)
• System.resumeJobById(cronTriggerId)

You can now:

• Temporarily pause recurring jobs (e.g., during maintenance or a blackout window)
• Resume them programmatically after specific conditions are met

🧠 Previously, this was only possible via Setup UI. Now it’s available directly in code.

---

🔧 How to Use It

Here’s an example that pauses all scheduled jobs tied to a specific class:

To Pause:


Id apexClassIdToPause = '01p4u000000dVf7AAE'; // Replace with your class ID

List<AsyncApexJob> jobsToPause = [
SELECT CronTriggerId FROM AsyncApexJob
WHERE ApexClassId = :apexClassIdToPause AND Status = 'WAITING'
];

for (AsyncApexJob jobToPause : jobsToPause) {
System.pauseJobById(jobToPause.CronTriggerId);
}


To resume, simply call:

apexCopyEditSystem.resumeJobById(jobToPause.CronTriggerId);

Or by job name:

apexCopyEditSystem.pauseJobByName('My_Daily_DataJob');
System.resumeJobByName('My_Daily_DataJob');

---

📌 Where This Works

• Applies to all editions
• Works in Lightning Experience and Classic
• Available in API version 63.0 and later

---

⚠️ Developer Notes

• ✔️ These methods count toward DML limits
• ❗ If you try to pause/resume a job that doesn’t exist or is already completed, an exception is thrown
• 🔐 Make sure the running user has the correct permissions (Modify All Data or equivalent)

---

🎯 Use Cases

• ⏳ Maintenance Windows: Temporarily pause batch or sync jobs during data loads.
• 🧪 Staging/QA Flows: Pause jobs during test cycles and resume later.
• 🛡️ Compliance Needs: Dynamically control scheduled automations based on business logic.
• 🔄 Retry Handling: Pause a failed job and resume after upstream dependencies are fixed.

---

💬 From Abhi:
“This is one of those underrated admin+developer productivity boosts. If you’re managing dozens of scheduled Apex jobs, this saves tons of manual toggling from Setup.”