DEV Community: Rohan Mehta

Salesforce Winter '26: Admin Updates That Take the Friction Out of Daily Work

Rohan Mehta — Sat, 17 Oct 2026 13:21:17 +0000

Salesforce releases arrive three times a year, and honestly, most of them blur together. Winter '26 is worth a closer look — not because it introduces flashy net-new products, but because it sands down the rough edges of the tools admins touch every single day: list views, reports, dashboards, and Flow Builder.

I went through the release notes and picked out the updates I think will matter most in real admin life. You can also read the full breakdown in the original Way2Force article: What Salesforce Winter '26 Brings for Admins: Top Updates.

Sort list views by up to five columns

List views finally support multi-column sorting. You can now order records by up to five fields at once, each ascending or descending — cases by Contact Name, then Priority, then Date/Time Opened, for example, or opportunities by Close Date and then Amount.

To set it up, open a list view's controls and choose up to five fields with a direction for each. The custom sort stays put until you change or clear it. To go back to the default, use List View Controls → Reset Column Sorting, or click a column header that isn't part of your current sort.

Find list-view fields with type-ahead search

Anyone who has scrolled through an endless field list while configuring a list view will appreciate this one. Field pickers now support type-ahead search: type a character to jump to the first matching field, type it again to keep moving down the list, and press Ctrl+Space to select the focused field. It works in Lightning Experience across all editions and supports every language Salesforce supports.

Let generative AI power Flow decisions

Decision elements in flows can now analyze unstructured data with generative AI. Instead of writing brittle rules for every scenario, a customer-service flow can have AI read an incoming email, gauge its tone or urgency, and route it down the right path. This is available in Lightning Experience for Enterprise, Performance, and Unlimited editions with the Einstein add-on.

Use newly created records immediately in flows

A small but mighty change: when a flow creates a record, you can now reference that record's fields directly in later elements — no extra Get Records element required. Flows get simpler and leaner. It works in Lightning Experience and Salesforce Classic, in all editions.

Draft flows with Einstein Next Generation (Beta)

Einstein Next Generation turns a plain-language description of your business requirement into a draft flow. It's available broadly in Lightning Experience, but as a Beta it's covered by Salesforce's Beta Services terms — and generating drafts consumes Einstein Request credits, the standard usage metric for generative features.

Trigger flows when files are attached to records

You can now fire a flow automatically when a file gets attached to a record. Build an Automation event-triggered flow; in the Start element, open the Event Library, choose the File Attach event, and set your entry conditions.

Debug flows with a resizable side panel

Flow Builder's debugger gets a resizable side panel, and debug results now appear as cards. Each card has a dropdown menu that jumps you straight to the relevant element on the canvas via "View on Canvas." Use the Setup tab to configure debug options and the Details tab to inspect inputs.

Compare flow versions side by side

Ever wondered exactly what changed between two versions of a flow? You can now compare versions directly in Flow Builder — from the Automation app's list view or the flow's detail page, via the actions menu → Compare Versions. The comparison shows the total number of changes by type, the API names of updated elements and resources, and the details of each change. It works with autolaunched, scheduled, platform event-triggered, and record-triggered flows.

Translate report and dashboard labels

Reports and dashboards can now be localized: translate metadata labels such as Name and Description, plus dashboard widget titles, subtitles, and footers. Setup runs through Translation Workbench — enable it, add languages, assign translators, then choose your component and aspect and add the translation.

Block formulas in exported reports (Beta)

A quiet security win: admins can stop spreadsheet programs from interpreting exported field values as formulas. Enable it under Reports and Dashboards Settings, and add any extra trigger characters (comma-separated) that should be flagged at the start of field values.

Add reference lines to Lightning dashboard charts (Preview)

Reference lines — previously available only in report charts — are coming to Lightning dashboard charts. A sales manager could drop a monthly revenue target line onto a bar chart and check progress at a glance. Add a chart widget, select Show Reference Line, enter the reference value, and save the dashboard.

Try them in a sandbox first

Winter '26 is packed with quality-of-life wins. Review the ones that touch your org's processes in a sandbox first, then share the most useful with your stakeholders before they land in production.

Originally published at Way2Force

Stop Unwanted Emails from Leaving Salesforce: Blocking Addresses in Email-to-Case

Rohan Mehta — Sat, 17 Oct 2026 02:33:37 +0000

Stop Unwanted Emails from Leaving Salesforce: Blocking Addresses in Email-to-Case

Email-to-Case is one of Service Cloud's most useful channels — and one of the easiest to misfire. An agent hits reply-all on a case thread, and suddenly your response is bouncing around an internal distribution list, a vendor's legacy inbox, or an address that auto-replies and reopens the case in an infinite loop. Everyone who runs Email-to-Case has a story like this.

The usual quick fix is to hardcode blocked addresses into a validation rule or directly in Apex. It works for a week. Then a new address needs blocking, and someone has to edit code, run tests, and deploy. There's a cleaner pattern: keep the blocked list in a Custom Metadata Type and enforce it with a trigger. Admins can update the list; developers never touch the logic again.

The pattern in brief

A Custom Metadata Type (CMDT) acts as a configuration table that ships with your org's metadata but can be edited in Setup without a deployment. For this use case, one text field is enough:

CMDT label: Blocked Email Address
Developer name: Blocked_Email_Address__mdt
Field: Email_Address__c (Text, required)

Each record holds one address you never want agents emailing: no-reply@yourdomain.com, a decommissioned vendor inbox, the monitoring mailbox that replies to everything.

The enforcement: an Apex trigger on EmailMessage

The blocking happens in a before insert trigger on the EmailMessage object. Before any outbound email is committed, the handler loads the blocked list from CMDT and checks the To and CC fields. If either contains a restricted address, the email gets an addError and never sends.

trigger EmailMessageTrigger on EmailMessage (before insert) {
    if (Trigger.isBefore && Trigger.isInsert) {
        EmailMessageTriggerHandler.handleBeforeInsert(Trigger.new);
    }
}

public class EmailMessageTriggerHandler {
    public static void handleBeforeInsert(List<EmailMessage> emailMessageList) {
        // Load blocked addresses from Custom Metadata
        Set<String> blockedEmails = new Set<String>();
        for (Blocked_Email_Address__mdt meta :
             [SELECT Email_Address__c FROM Blocked_Email_Address__mdt]) {
            if (meta.Email_Address__c != null) {
                blockedEmails.add(meta.Email_Address__c.toLowerCase());
            }
        }
        for (EmailMessage email : emailMessageList) {
            // Outbound emails related to a Case (prefix 500) only
            if (!email.Incoming && email.ParentId != null
                && String.valueOf(email.ParentId).startsWith('500')) {
                String toAddr = email.ToAddress != null
                    ? email.ToAddress.toLowerCase() : '';
                String ccAddr = email.CcAddress != null
                    ? email.CcAddress.toLowerCase() : '';
                for (String blocked : blockedEmails) {
                    if (toAddr.contains(blocked) || ccAddr.contains(blocked)) {
                        email.addError('Email not allowed to be sent to or CC\'d '
                            + 'to restricted address: ' + blocked);
                        break;
                    }
                }
            }
        }
    }
}

A few design notes worth stealing:

Only outbound emails (!email.Incoming) get checked — inbound messages still create cases normally.
Only case-related emails (the 500 prefix check on ParentId) are filtered, so the same pattern can't accidentally break other email automation in the org.
Case-insensitive matching avoids the classic No-Reply@ vs no-reply@ bypass.
Keep the logic in a handler class rather than the trigger body, so it slots into an existing trigger framework.

Setting it up

Create the CMDT in Setup → Custom Metadata Types, with the Email_Address__c text field.
Add records under Manage Records — one per address to block. This is the part your admins own going forward.
Deploy the trigger + handler once. After that, blocking a new address is a five-second Setup task, not a deployment.

Why this pattern is worth adopting

It's dynamic — the list changes without code changes. It's secure — enforcement happens at the platform level before the email exists, so no flow or agent action can dodge it. And it's reusable — the same CMDT-driven approach works for any metadata-flavored rule: branding injection, routing overrides, feature flags.

If your org runs Email-to-Case, this is one of those small builds that prevents exactly one catastrophic "oops" email — and that's worth the afternoon.

Originally published at Way2Force

5 Websites Every Salesforce Professional Should Bookmark in 2026

Rohan Mehta — Thu, 15 Oct 2026 11:42:10 +0000

When I first joined the Salesforce world, my browser's bookmarks bar looked like a junk drawer. I had saved dozens of links — blog posts, help articles, forum threads — "for later," and almost never opened any of them again. That changed when a senior architect told me something I've never forgotten: you don't need more bookmarks, you need the right five.

Years later, I can confirm he was right. The Salesforce professionals who keep growing — the ones who clear certifications, ship clean Flows, and stay current with three platform releases a year — tend to rely on a small, sharp set of resources. Here are the five websites I'd tell every admin, developer, and consultant to bookmark in 2026.

1. Trailhead: the official classroom

No list can skip Salesforce's own learning platform, and in 2026 it's stronger than ever. Trailhead remains the fastest free route to certification prep, with Trailmixes that bundle exactly what each exam expects you to know.

Hands-on tip: before every Salesforce release, work through the release-readiness module. It takes about twenty minutes and routinely saves you hours of confusion when new features land in your org. Pair modules with hands-on playgrounds instead of reading passively — the knowledge sticks because you built something.

2. Salesforce Ben: the ecosystem's newsroom

If Trailhead is the classroom, Salesforce Ben is the staffroom conversation. What began as one person's blog has grown into a full publication covering certification guides, career advice, salary surveys, and release breakdowns written in plain language.

Hands-on tip: skim their release summaries the week a new Salesforce release drops. You get the practical "what changes for me" view in minutes, which makes planning your org's upgrade far less painful. And if you're considering a move, their salary data and job board are worth a look.

3. Unofficial SF: the community toolbox

Don't let the name fool you — this community-run collection is one of the most genuinely useful sites in the ecosystem. It's packed with tools, utilities, and guides that Salesforce doesn't ship itself but that working professionals reach for constantly.

Hands-on tip: spend one lunch break browsing the tool collection. You'll almost certainly find two or three utilities that slot directly into your daily workflow — the kind of thing that makes you wonder how you ever worked without them.

4. Automation Champion: the Flow encyclopedia

Run by Salesforce MVP Rakesh Gupta, this blog is arguably the single best Flow resource on the internet. Hundreds of detailed articles, each with step-by-step screenshots walking through real automation scenarios.

Hands-on tip: his guiding philosophy is "clicks before code." The next time you're tempted to write a trigger, search the site for a Flow-based approach first. You'll build faster, and your future self will thank you when the automation needs maintenance. This is the site I open most when I get stuck on a Flow requirement.

5. Apex Hours: the free video university

Prefer learning by watching? Apex Hours runs free live sessions — recorded for later viewing — hosted by Amit Chaudhary and a rotating cast of community experts. Apex, Lightning Web Components, integrations, DevOps: it's all covered.

Hands-on tip: treat the session recordings like a personal conference. Pick one topic a week, watch at 1.25x speed, and follow along in a scratch org. A month of this habit will move your skills further than a month of random tutorials.

Don't try to consume everything

The trap is the same one I fell into at the start: bookmarking all five and trying to read every article on every site. That's how a bookmark bar becomes a junk drawer again. Instead, pick the one resource that matches what you're working on right now — certification prep, a Flow build, release readiness — and go deep there first.

For a longer take on how these sites fit into a learning routine, I wrote the full version of this list over at Way2Force: 5 Websites Every Salesforce Professional Should Know in 2026.

What are your must-visit Salesforce sites? Drop them in the comments — I'm always looking to sharpen my own list.

Originally published at Way2Force

Building Customer Portals Without Experience Cloud: Four Alternatives Worth Knowing

Rohan Mehta — Wed, 14 Oct 2026 12:47:20 +0000

When Salesforce admins hear "customer portal," most of us picture Experience Cloud first. It is the native answer: customers sign in to a branded site, open their own cases, and read Knowledge articles, all against your live org data.

But the native answer is not always the right answer for every team. Licensing costs, admin capacity, design freedom, or a business unit that already runs on another stack can all push you to look elsewhere. The trouble is that most roundups of Experience Cloud replacements read like feature bingo, and almost every product ticks almost every box.

There is a better way to judge them. Instead of comparing features, ask two questions that sit underneath the whole decision: where does the portal keep customer data, and what are portal customers in Salesforce's eyes? Those two answers decide what you pay Salesforce and how the whole thing behaves when it breaks. I first mapped this out in the original long-form piece at Way2Force, and this post is the condensed, hands-on version for admins and developers.

Four places a portal can live

1. On the platform: Experience Cloud and its ecosystem

This is the starting point rather than a true alternative. Every customer is a licensed external user: Customer Community for high-volume self-service, Customer Community Plus when you need roles and sharing rules, Partner Community for channel users with leads and opportunities, plus a few narrower license types for edge cases.

Some tools that appear on "alternatives" lists actually live here. Advanced Communities adds components on top of Experience Cloud and still requires an Experience Cloud license. There is also a headless flavor: your own React or mobile front end that signs customers in through Salesforce's headless identity APIs, keeping them licensed external users governed by the sharing model.

Why teams stay: there is no second copy of anything. When an agent closes a case at 4:55 p.m., the portal shows it closed at 4:55 p.m., because it is the same record. Security is enforced by the platform itself, so profiles, permission sets, sharing rules, login history, and Shield event monitoring (if you own it) cover external users too. Knowledge articles and Service Cloud cases work against live data from day one, and newer Agentforce self-service components slot straight into the site.

The price you pay: every customer needs a license, and every configuration change needs Salesforce skills. Guest access deserves particular respect, because researchers have repeatedly found Experience Cloud sites exposing private records to anonymous visitors through overly generous guest permissions. Salesforce has tightened the defaults since — guest users now receive records only through read-only guest sharing rules, and the external org-wide default for guests is forced to Private. Those protections help, but the platform enforces the design you build, not the design you meant.

2. Off-platform with a live connection

These portals live outside Salesforce and read and write your org's records on demand through a connected app, keeping no copy of their own. CRMJetty is one example of this pattern. Salesforce stays the system of record, portal users do not consume Salesforce licenses, and the site can be configured without touching Experience Builder.

The big bill here is the API budget. An Enterprise org gets 100,000 API calls per rolling 24 hours plus 1,000 per full Salesforce or Salesforce Platform license; Customer Community Plus and Partner Community add 200 each, while plain Customer Community adds nothing. Do the rough math: 1,000 customers loading ten pages a day at three calls a page is 30,000 calls — drawn from the same pool your other integrations drink from. Ask every vendor how many calls a typical page costs and whether it caches.

Then there is connection security. In August 2025, attackers used OAuth tokens stolen from the Salesloft Drift integration to export data from Salesforce instances at more than 700 organizations, according to Google's threat-intelligence team. Nobody broke into Salesforce; they rode a trusted connection. So ask what permissions the integration user holds, where tokens are stored, how you would revoke them in an emergency, and whether the connected app is installed in your org — since September 2025, Salesforce blocks most users from authorizing uninstalled connected apps.

One more subtlety: visibility rules live in the vendor's layer here, because customers are not Salesforce users. Your access-control review must cover the portal's configuration, not just your org's. Test it like an attacker would: sign in as one customer and try to open another customer's record by changing an ID in the URL.

3. Off-platform with a synced copy

These products keep their own database and refresh it from Salesforce on a schedule. Magentrix mirrors CRM records into its own platform, no-code builders like Knack run on their own database, and community platforms like Higher Logic Vanilla sync through a connector or Zapier.

The appeal: pages load from local data, the portal keeps working through a Salesforce outage, and page views do not spend your API budget. The costs: freshness — a few hours of lag is invisible on a knowledge base and unacceptable on case or order status, so ask for the sync interval per object, not as a headline number. Writes can collide when a customer and an agent edit the same record at once, so ask which edit wins and who gets told. And every mirrored record is a second copy of customer data that you must secure, retain, and delete when asked.

4. A different system of record entirely

Microsoft Power Pages, for example, builds portals on Dataverse — Microsoft's data platform, not Salesforce. This only belongs on the shortlist if you are moving customer data off Salesforce or part of the business already runs on Dynamics 365. Otherwise you are adopting a whole second platform, and the portal is the smallest part of that decision.

Five questions that place any vendor on the map

Before the feature grid, put these to every option, including Experience Cloud:

After a customer views a record, where does it live — your org only, the vendor's database, or both?
Who is the customer in Salesforce's eyes — a licensed external user, or someone represented by an integration user?
What enforces record visibility — the Salesforce sharing model, or the vendor's access layer? If the vendor's, ask to see the configuration and the testing.
What does a typical page cost in API calls — or how stale can the data get? Every off-platform option spends one or the other.
What happens when the connection fails, and how do you revoke it? Walk through planned Salesforce maintenance and an expired token first.

These answers narrow a long shortlist to two or three serious contenders faster than any comparison table.

The short version

Experience Cloud is the only option where the portal and the CRM are literally the same system, and for teams with in-house Salesforce skills that is often the deciding advantage. Alternatives do not erase the work Experience Cloud does — they relocate it. A live connection shifts it to API budgeting and connection security; a synced copy shifts it to reconciliation and data governance. Choose the architecture whose chores your team is best equipped to handle, then compare features inside that lane.

Disclosure: this post adapts the original Way2Force piece, which disclosed the author's affiliation with one of the vendors named above. The architectures and questions here are meant to be applied to every option on a shortlist, including that one.

Originally published at Way2Force.

Why Every AI Strategy Needs Data Cleaning First

Rohan Mehta — Tue, 13 Oct 2026 11:42:12 +0000

Everyone wants AI. Salesforce admins get asked about Agentforce pilots, execs want predictive dashboards, and every vendor demo promises magic. But here's the uncomfortable truth I keep seeing in Salesforce orgs: AI fails on dirty data. Not sometimes — almost every time.

Large language models and predictive engines are pattern matchers. Feed them duplicate leads, half-empty account records, and five different spellings of the same company name, and they will confidently generate nonsense. Garbage in doesn't just mean garbage out anymore — it means garbage at scale, delivered with machine confidence.

Dirty data is an AI problem, not a housekeeping problem

In most Salesforce orgs I've worked with, the data issues are depressingly familiar:

Duplicate contacts and leads from years of web-to-lead forms and sloppy imports
Fields that look required but sit empty on half your records
"Closed Won" opportunities with no amount, no close date, and no products
Picklist values like "N/A", "n/a", "NA", and "Not Applicable" living side by side
Stale records for people who left their companies three years ago

An AI assistant trained on this mess will route cases to dead email addresses, score leads on fictional data, and summarize accounts with phantom revenue. Your users won't blame the data — they'll blame the AI, and adoption dies before it starts.

Start with a data audit, not a model

Before you greenlight any AI project, run a proper audit of the objects your AI will touch. Pull reports on empty key fields, run duplicate jobs, and sample records manually. You can't fix what you haven't measured — and a one-page "data health" summary is the most persuasive document you can put in front of leadership. I walk through this full process in Why Every AI Strategy Needs Data Cleaning First.

Clean in this order

1. Deduplicate. Merge duplicate accounts, contacts, and leads first — duplicates multiply every other problem downstream.

2. Complete the critical fields. Identify the 10–15 fields your AI actually needs (email, phone, industry, stage, amount) and get them reliably populated.

3. Standardize formats. Phone numbers, addresses, picklist values — pick one format and enforce it with validation rules.

4. Delete or archive the dead weight. Records untouched in years with zero engagement are noise. Archive them so they stop polluting your models.

5. Fix it at the source. Validation rules, required fields on page layouts, duplicate rules, and Flow-based enrichment stop bad data from re-entering the org.

Make cleanliness automatic

One-time cleanup projects fail because data decays. Set up scheduled duplicate jobs, exception reports emailed to record owners weekly, and a simple dashboard tracking data completeness over time. Assign real data ownership — every object should have someone accountable. This is the unglamorous operational layer that makes AI actually work.

Then — and only then — bring in AI

Once your data is trustworthy, Salesforce's AI features start earning their keep: lead scoring that reflects reality, case classification that routes correctly, summaries grounded in actual history. The teams that succeed with AI aren't the ones with the fanciest models; they're the ones whose data the model can trust.

Clean data isn't the boring prerequisite to your AI strategy. It is the AI strategy. Everything else is decoration.

Originally published at Way2Force

Apex Test Coverage in 2026: Rules, Gotchas, and How to Write Tests That Actually Help

Rohan Mehta — Mon, 12 Oct 2026 11:45:13 +0000

If you've ever tried to push Apex code to a production org, you've met Salesforce's deployment gatekeeper: the mandatory test run. In 2026, those rules haven't relaxed at all — and that's deliberate. Tests aren't bureaucracy; they're how a shared, multi-tenant platform stays trustworthy when thousands of developers ship code every day.

Why Salesforce enforces test coverage

Salesforce executes your code alongside everyone else's in a multi-tenant architecture. A careless trigger on your org can't be allowed to undermine the platform's reliability for your users. Mandatory tests serve two purposes:

Deployment safety. Production deployments require a passing test run. If your tests fail, your metadata stays in the sandbox. Simple as that.
Regression insurance. Orgs evolve constantly — admins add flows, validation rules, and required fields. A solid test suite catches the breakage before your users do.

The coverage rules, precisely

Here is what the platform actually demands before a production deployment:

At least 75% of all Apex code in the org must be executed by tests.
Every trigger must have some coverage — an untested trigger blocks deployment even if the org-wide number looks fine.
All test methods must pass. No failures, no uncaught exceptions.
Test classes themselves don't count toward the 75%.

Notice what's missing from that list: any requirement that your tests be good. A test that executes code without asserting anything still inflates the percentage. Which brings us to the real problem.

Stop gaming coverage; start asserting

Coverage is a floor, not a finish line. A test without System.assert calls proves nothing except that your code doesn't crash on one narrow path. Meaningful tests assert outcomes:

Assert the business result, not the implementation detail. ("The opportunity moved to Closed Won" beats "the method returned true.")
Test the unhappy paths: validation failures, null inputs, and governor-limit-adjacent bulk sizes.
Cover every branch of your conditionals — both sides of each if/else and every ternary outcome.

Write tests you'd trust to run at 2 AM during a release window. We walk through the full setup in our test classes and code coverage guide.

Bulk-safe test data patterns

Tests that insert a single record and call it a day are lying to you. Real orgs process data in bulk — triggers fire on up to 200 records at a time. Build that reality into your tests from the start:

Create your own data. Never depend on existing org data (SeeAllData=true is a trap that makes tests fail in fresh sandboxes). Generate records that mirror real business scenarios, including related records.
Use @TestSetup. One setup method builds shared data once per test class, keeping tests fast and consistent.
Centralize with a Test Data Factory. A single utility class that produces Accounts, Contacts, and Opportunities with sensible defaults saves everyone on the team from reinventing fixtures.
Test in bulk. Insert 200 records, not one. That's where SOQL-in-loop bugs and governor-limit failures hide.

@isTest
private class AccountTriggerTest {
    @TestSetup
    static void makeData() {
        List<Account> accts = new List<Account>();
        for (Integer i = 0; i < 200; i++) {
            accts.add(new Account(Name = 'Test ' + i));
        }
        insert accts;
    }

    @isTest
    static void bulkInsertSetsIndustry() {
        Test.startTest();
        // trigger logic under test runs against the @TestSetup data
        Test.stopTest();

        Integer flagged = [SELECT COUNT() FROM Account WHERE Industry = 'Technology'];
        System.assertEquals(200, flagged, 'All bulk-inserted accounts should be flagged');
    }
}

Test.startTest() and Test.stopTest() also reset governor limits and force asynchronous code — future methods, queueables, batch jobs — to run synchronously, which is essential for testing anything @future or scheduled.

Deployment gotchas that still bite in 2026

Coverage evaporates on edit. The moment you modify a class, its coverage data is cleared until tests run again. Re-run after every change.
Mixed DML errors. Creating a User and an Account in the same transaction blows up. Wrap user-context setup in System.runAs(), which also lets you verify sharing rules and profile behavior.
Run test classes individually when debugging. One class at a time makes failures far easier to isolate than a full-org run.
Aim above the minimum. 75% gets you deployed; targeting 90% or more across classes and triggers gives you headroom for the inevitable coverage dip when someone edits a class the night before a release.

Good tests are documentation that executes. They tell the next developer what the code is supposed to do — and they scream when it stops doing it. Write them like the next person reading them is you, six months from now, during an incident.

Originally published at Way2Force.

Stop Manually Removing Salesforce Permissions: Assign Permission Sets That Expire on Their Own

Rohan Mehta — Sun, 11 Oct 2026 11:42:20 +0000

Stop Manually Removing Salesforce Permissions: Assign Permission Sets That Expire on Their Own

Every Salesforce admin has the same recurring chore: granting temporary access and then remembering to take it away. A contractor needs elevated access for two weeks. A support rep covers a queue for a month. A developer needs production data access until go-live. You grant the permission set, make a mental note to revoke it later — and later never comes.

Permission sets with an expiration date fix this at the source. Instead of remembering to remove access, you set the end date when you grant it. Salesforce handles the rest.

How assignment expiration works

When you assign a permission set to a user, you can now choose an expiration date for that assignment. On that date, the assignment is removed automatically — no manual cleanup, no audit scramble.

The mechanics are straightforward:

Go to Setup → Permission Sets and open the permission set you want to assign.
Click Manage Assignments → Add Assignments.
Select the users, click Next — and this is the step most admins miss — set the expiration date before confirming.
Alternatively, manage expirations in bulk from Setup → Users → Permission Set Assignments using the Manage Assignment Expiration action.

You can also pick a relative window (a set number of days) instead of a fixed date, which is handy when the same temporary-access pattern repeats.

Where this actually pays off

Contractors and consultants. Scope their access to the engagement window. When the contract ends, the access ends — not three months later when someone finally audits.

Temporary elevation. Covering for a colleague on leave? Granting elevated access "until Sarah is back"? Put a date on it instead of trusting your memory.

Project teams. Data migration, go-live support, UAT — all time-boxed by nature. Match the access window to the project window.

Compliance and reviews. If your org does quarterly access reviews, expiration dates turn the review into a confirmation exercise instead of a cleanup project. Auditors love seeing access that provably lapsed on schedule.

A few things to watch

Expiration removes access silently, so communicate the end date to the user — nobody enjoys discovering at 9 AM that their access evaporated overnight. For genuinely recurring temporary needs, consider automating the assignment itself with a flow so the whole lifecycle is hands-off. And note that expiration applies to the assignment, not the permission set: the permission set definition stays intact and reusable.

One more consideration: session-based permission sets (the old "activate for this session" model) are on their way out. Assignment expiration is the supported pattern going forward — it's worth migrating any session-based processes to it now rather than under deadline pressure.

The bottom line

Access that expires on its own is one of those small governance wins that compounds. Fewer stale assignments, cleaner audits, and one less thing living in your memory instead of the system. If you've been managing temporary access with calendar reminders, this is the week to stop.

Originally published at Way2Force

Send Custom Notifications in Salesforce Using Flow: A No-Code Guide

Rohan Mehta — Sat, 10 Oct 2026 11:43:15 +0000

Send Custom Notifications in Salesforce Using Flow: A No-Code Guide

Users miss things. A high-value opportunity stalls, a case sits untouched for days, an approval request goes unnoticed — not because Salesforce can't surface these moments, but because nobody thinks to look in the right place at the right time.

Custom notifications fix that. They push an alert straight to the Salesforce notification bell (and the mobile app) when something important happens, and the whole thing can be built with clicks in Flow Builder — no Apex required.

What you need before you start

Two building blocks:

A Custom Notification Type — created once in Setup (Notification Builder > Custom Notifications). Give it a name, set the channels (desktop, mobile, or both), and finish. This is the "envelope" your flow will use.
A Flow — typically a record-triggered flow that decides when the notification fires and who receives it.

Building the flow

Create a record-triggered flow on the object you care about — Opportunity, Case, or whatever matches your use case. Set it to trigger on create or update, then add your entry criteria so it only fires when it matters (for example, an opportunity stage changing to "Negotiation" with an amount over a threshold).

Next, add the Send Custom Notification action element. This is where you wire up the pieces:

Notification Type — the custom notification type you created in Setup. You'll need its ID (grab it from a Get Records on the CustomNotificationType object, or reference it directly).
Title and Body — build these with formula resources so the message feels personal: something like "Opportunity {Record.Name} needs attention" with the stage and amount in the body.
Recipient IDs — a collection variable of user IDs. Use Get Records to find the right people (opportunity owner, team members, managers) and assign their IDs into the collection.
Target ID — the record the notification should deep-link to, so one click takes the user exactly where they need to act.

A practical example

Say you want managers notified whenever a deal over $50K goes idle for more than 7 days. A scheduled-triggered flow can run daily, query opportunities that match, and send one notification per record to the owner and their manager. The recipient gets a bell notification and a mobile push with the deal name, stage, and a link straight to the record — instead of a forgotten line in a report.

Tips that save you headaches

Keep the title short. The bell banner shows limited text; put the detail in the body.
Mind volume. Scheduled flows plus broad criteria can spam people fast. Filter aggressively, and consider batching into a summary message.
Test as a non-admin. Notification visibility respects sharing; verify the recipient can actually open the target record.
Use mobile push for the truly urgent. Bell-only notifications are cheap and quiet; save push for escalations.

Custom notifications are one of those small Flow features with outsized impact: five minutes of configuration, and your team stops missing the moments that matter.

Originally published at Way2Force

Setting Up Slack with Salesforce: A Practical Admin Walkthrough

Rohan Mehta — Fri, 09 Oct 2026 11:42:28 +0000

Salesforce admins spend a big part of their week inside the CRM, but the rest of the team lives in Slack. Deal notes get discussed in channels, support escalations fly through DMs, and important updates vanish into the scroll before anyone logs them in Salesforce. Connecting Slack to Salesforce bridges that gap — conversations stay tied to records, and data stays visible where work actually happens.

I recently walked through this setup in a trial org, and it turned out to be far more straightforward than I expected. Here is the path I followed, plus a few lessons learned along the way.

1. Connecting Slack to Salesforce with Guided Setup

You don't need a paid add-on or custom code to get started. Salesforce ships a guided flow that handles the connection for you:

Open Setup (click the gear icon) and search for Guided Slack Setup.
The guided page lists the steps to link a Slack workspace to your org. In many trial and scratch orgs, a Slack workspace is already provisioned, so all you do is open Manage Slack Connection to confirm the workspace name, URL, and connection status.
Click the workspace URL, sign in to Slack, and return to Salesforce.

Mark each step complete in the guided page as you go — it keeps the rollout traceable if a colleague needs to replicate it later.

2. Bringing Slack into Record Pages and Flow

The connection alone is only half the value. The real payoff comes from surfacing Slack where users already work:

Add the Slack component to record pages. Back in Guided Slack Setup, choose Add Slack conversations to record pages, pick an object (Account is the natural starting point), and open the page in Lightning App Builder. Drag the Slack component onto the layout where it will be noticed, then save and activate.

Test it. Open an Account record, and from the Slack component you can connect or create a Slack channel tied to that Account. Messages posted from the record appear in the Slack channel, and replies in Slack flow back into the record. The conversation is anchored to the right Account, so context never gets lost.

Use Slack inside Flow. Admins can push notifications into Slack directly from Flow — for example, posting to a channel when an Opportunity stage changes or when a Case escalates. Pair this with the record-page component and you get a loop: alerts go out automatically, and discussion happens against the record.

Let users view Salesforce data from Slack. Once connected, Salesforce actions appear inside Slack. Users can look up records, view details, and — depending on permissions — update fields, with changes syncing both ways.

3. Practical Tips for Admins

Check licenses and permissions first. Salesforce permissions still govern what each user can see and edit. Test with a standard user profile, not just as an admin.
Start with one object. Roll out on Account first, learn how your team uses it, then extend to Opportunities or Cases.
Name channels deliberately. A consistent naming convention (for example, acct-acme-corp) makes channels discoverable and keeps the integration tidy.
Train on the two-way sync. The biggest "wow" moment for users is learning that an update in Slack shows up in Salesforce — demonstrate it live in your first demo.
Monitor adoption. Watch which records get linked channels and which don't; low usage usually means the component placement or the workflow needs adjusting, not that the integration is broken.

The Payoff

The benefits show up quickly: less app switching, conversations that stay attached to the right records, faster updates from either side, and productivity gains that compound across the team. Most importantly, nothing about security changes — the same Salesforce permission model applies inside Slack.

If you haven't connected the two yet, block out an afternoon and try it in a sandbox or trial org. The guided setup removes the guesswork, and your users will thank you the next time a deal discussion doesn't disappear into a Slack thread.

Originally published at Way2Force

ClaudeForce and Salesforce: What the Anthropic Partnership Really Means for You

Rohan Mehta — Thu, 08 Oct 2026 11:43:15 +0000

If your feed felt a little louder than usual earlier this year, there was a reason: Salesforce and Anthropic announced ClaudeForce, arguably the biggest AI news in the Salesforce ecosystem in 2026.

I've spent years watching Salesforce roll out AI features, from Einstein Copilot to Agentforce. ClaudeForce is different. It isn't another assistant bolted onto the CRM. It's a two-way bridge: Claude can now reason over your Salesforce data, and Salesforce is available directly inside Claude. Let me unpack what it actually is, why it exists, and what it means for those of us building on the platform every day.

What Is ClaudeForce, Really?

ClaudeForce is the product of Salesforce's partnership with Anthropic. At its core, it plugs Claude's reasoning into Salesforce's Customer 360 — your records, your Slack conversations, your workflows — and lets you work with all of it through natural language.

Ask for a summary of an account before a meeting, and Claude pulls together the relevant records and business context instead of you clicking through five tabs. Describe a change in plain English and have the record updated. That is the promise: less hunting, more doing.

Critically, ClaudeForce is not a chatbot skin, and it is not here to replace Agentforce. Salesforce kept its existing security and permission model intact, so enterprise governance travels with the data. AI gets the reasoning seat; Salesforce keeps the keys.

Why Salesforce Built It

Here's the honest truth about life as a Salesforce user: you live in tab-switching purgatory. A sales rep checks opportunities in Salesforce, reads the customer thread in Slack, pulls a report, then updates the CRM by hand. Multiply that by every rep, every day, and you get an enormous amount of expensive busywork.

ClaudeForce exists to collapse that context-switching. If one AI can see the CRM, the conversations, and the workflows together, the rep stops being a data courier and starts being a seller.

Salesforce in Claude: The First Big Experience

The flagship experience is called Salesforce in Claude. Once an admin enables it, Salesforce data becomes available inside Claude — no custom APIs, no integration project.

Salesforce shipped 37 pre-built Sales Skills with it. Think of them as ready-made superpowers for sellers: prepping for customer meetings, summarizing account history, reviewing pipeline health, flagging opportunities at risk, and updating records using natural language. A seller can ask Claude to brief them on an account, and it assembles the picture from Salesforce records and surrounding business context.

Slack integration and the underlying plumbing — components Salesforce calls AIforce, Headless 360, Data 360, and MCP — round out the first release.

What It Means for Salesforce Professionals

For admins, the message is: learn the enablement and governance story. Your sharing rules and permissions still apply, which means the architecture you already built continues to protect the data. ClaudeForce rewards clean data and well-designed security.

For developers, ClaudeForce is a signal about where Salesforce is heading: open protocols like MCP, headless access to 360 data, and AI experiences that live where users already work. The integration surface is shifting from screens to conversations.

The Practical Takeaway

Don't wait for a mandate to start experimenting. Pick one repetitive workflow — meeting prep is the classic — and try running it through Salesforce in Claude in a sandbox or pilot org. Time how long the manual version takes today, then compare. That gap is the business case, and it's the number you'll bring to your stakeholders.

The platforms we build on are changing shape. ClaudeForce won't replace good Salesforce architecture — but it will reward the teams whose data and governance are clean enough for AI to reason over.

Originally published at Way2Force

Delegate These 7 Salesforce Admin Tasks to Claude Code

Rohan Mehta — Wed, 07 Oct 2026 11:41:43 +0000

AI conversations in the Salesforce world tend to orbit around models, features, and integrations. But working admins usually ask a much more practical question: what can I actually use AI for, day to day?

One strong answer is Claude Code — an agentic coding assistant that works with Salesforce DX projects. You don't need to write Apex to get value from it. Here are seven admin tasks where it can take on the repetitive research, comparison, and drafting work, leaving you to make the decisions that need real Salesforce judgment.

A few ground rules first: always test changes in a sandbox before touching production, and check your org's policy on AI tools reading metadata and data — anything Claude reads leaves your org for processing by the model provider (Anthropic, Amazon Bedrock, or Google Vertex AI, depending on your setup). Authenticate the Salesforce CLI against a sandbox (sf org login web --instance-url https://test.salesforce.com) and run Claude Code from an SFDX project.

1. Audit custom fields with no detected references

Leftover custom fields from old projects pile up. Ask Claude to retrieve custom fields on Account and Opportunity and flag those with no detected references across page layouts, Lightning record pages, field sets, list views, formulas, validation rules, Flows, Apex, email templates, report types, and your specified report folders — presented in a table, marked as review candidates, not confirmed unused.

Your review step: reports are tricky, because the Metadata API doesn't support wildcard report retrieval, so Claude can only scan the folders you include. Also check outside the retrieved metadata — integrations, external reporting tools, data loads, managed packages, workflow rules, and old Process Builder automation. Confirm with the field owner before removing fields from layouts or deleting them; Salesforce offers no deactivate option for custom fields.

2. Generate permission set documentation

When an org has dozens of permission sets, tracking who has what is slow. Have Claude retrieve the permission set metadata and query PermissionSetAssignment records (filtering out profile-owned sets), including permission set groups, member sets, and muting permission sets, then write a Markdown doc per set covering object permissions, system permissions, and assigned users.

Your review step: spot-check a few sets — especially sensitive ones like Modify All Data and View All Data — against Setup. Remember the doc won't show complete effective access: profiles and session-based permission sets aren't included.

3. Review Flows for missing fault paths

Record-triggered and screen Flows with Create, Update, Delete, or Get Records elements — or action elements — that lack fault connectors will show users ugly unhandled fault messages (and send error emails). Ask Claude to review the Flows in your project, list elements that support fault connectors but have no explicit fault path, explain the potential failure for each, and suggest an error-handling approach.

Your review step: decide which recommendations fit your org's error-handling standards, then build and test both success and failure scenarios in a sandbox.

4. Draft validation rules from business requirements

Stakeholders speak plain English; validation rules need formulas. Ask Claude to draft the rule — formula, error message, and error location — from a requirement like "prevent closing an Opportunity as Closed Won unless Amount is greater than zero and a primary contact is set, with a custom-permission bypass."

Your review step: verify API names against your org. If you're checking for a primary contact, Opportunity's standard ContactId field (the ID of the contact marked Primary in Opportunity Contact Roles) may do the job without a new lookup field — though validation rules can't directly query Opportunity Contact Role records. Test valid, invalid, and bulk scenarios, including data loads and integrations, and use a custom permission rather than a profile for the bypass.

5. Compare metadata between sandbox and production

Environments drift. Ask Claude to retrieve the same package.xml manifest from sandbox and production into separate folders, compare them, summarize the differences, and flag anything that exists only in production.

Your review step: the comparison only covers what's in your manifest. Components that exist only in production might be direct hotfixes, managed-package content, or Salesforce features — bring genuine production changes back into the sandbox or source control before deploying so you don't overwrite them.

6. Write SOQL queries for data cleanup reports

Standard reports don't always answer data-quality questions. Ask Claude to write and run a SOQL query — e.g., Contacts created in the last 90 days with no email and no recorded activity (using LastActivityDate), exported to CSV.

Your review step: cross-check the record count with a quick Salesforce report, confirm your org's activity data before treating results as final, and remember query results sent to the AI tool leave your org — avoid sensitive fields unless your policy allows.

7. Prepare deployment packages with a change summary

Release documentation eats time. Ask Claude to identify the week's changed components from Git history, build a package.xml manifest, run a validation-only deployment against production (sf project deploy validate), and write a plain-language release summary for business users.

Your review step: source tracking and Git history only go so far — provide the component list yourself when they don't. Review the summary from a business user's perspective, and be careful with permission sets: a deployment must include full permission set metadata (API 40.0+) to avoid overwriting permissions.

Conclusion

Claude Code won't replace admin judgment — but it can absorb the repetitive research, comparison, querying, and drafting work while you focus on the decisions that genuinely need your Salesforce expertise. Pick one task from this list, try it in a sandbox, review the output, and expand from there.

Originally published at Way2Force

Salesforce Flow Run Context, Explained: User vs System Context

Rohan Mehta — Tue, 06 Oct 2026 11:46:14 +0000

Every Salesforce flow runs as someone. Most days you never think about it — the flow just works. Then a screen flow that behaves perfectly for you throws "insufficient privileges" for a sales rep, or an autolaunched flow quietly updates records a user was never meant to touch. That is run context at work: the set of permissions your flow borrows while it executes.

The two worlds: user context vs system context

User context means the flow runs with the launching user's permissions. Object access, field-level security, sharing rules, the role hierarchy — all enforced exactly as if the user were clicking through the records themselves. If the user cannot see a field, the flow cannot read it either.

System context means the flow bypasses the user's object and field permissions. It comes in two flavors: with sharing still respects record sharing rules and the role hierarchy, while without sharing removes even those guardrails — the flow can touch any record in the org.

Each launch method ships with a default. Screen flows launched from a Lightning page run in user context; record-triggered and schedule-triggered flows run in system context without sharing. And flows can inherit elevated access from the flow that called them — context flows downhill.

The four options in Flow Builder

On newer API versions (v68.0 and later) you get explicit control over this for screen and autolaunched flows:

User or System Context — let the launch method decide (the default behavior).
User Context – Enforces User Permissions — always the user's access, even when a system-context flow calls this one. Use it when a flow must never gain elevated access.
System Context with Sharing — ignores object and field permissions, but respects sharing rules.
System Context without Sharing — no object, field, or record-sharing restrictions at all.

Setting it takes ten seconds: open the flow in Flow Builder, click View Properties, then Show Advanced, and under How to Run the Flow pick your context and save. If the dropdown is greyed out, that flow type does not support changing run context.

You will need the Manage Flow permission to touch these settings (it covers flows that use Einstein and Agentforce for Flow as well).

Gotchas worth knowing

Experience Cloud is the danger zone. A screen flow running in system context on a public or community site can expose internal data to external users. Default to user context there unless you have a very specific reason not to.
Some elements ignore your choice. Lightning screen components and local actions always execute in user context. The Post to Chatter action always runs in user context too.
Apex can rewrite the picture. Flows launched from Apex may bypass object and field permissions depending on the calling code's sharing declaration — with sharing versus without sharing on the class still matters.
Watch inherited context. When a system-context autolaunched flow launches a subflow, the subflow can inherit that elevated access. Trace the chain before you assume the user context applies.

The bottom line

Run context is a security decision wearing an admin setting's clothes. Default to user context when the flow acts for a specific person; reach for system context only when the flow needs data the user legitimately cannot reach — and prefer with sharing over without sharing when you do. Set it deliberately once, and you will never debug a phantom permissions error at midnight again.

Originally published at Way2Force.