DEV Community: Rohan Mehta

Salesforce DevOps Center: Moving Metadata Without the Change-Set Headache

Rohan Mehta — Sun, 08 Nov 2026 11:42:34 +0000

Salesforce DevOps Center: Moving Metadata Without the Change-Set Headache

If you have ever deployed a change set, waited twenty minutes, and then watched it fail on a component you forgot to include, you already know the problem DevOps Center was built to solve. Change sets work, but they are manual, forgetful, and silent about what they leave behind. DevOps Center replaces that guesswork with a tracked, visible pipeline.

What DevOps Center actually is

DevOps Center is Salesforce's free, native release-management tool. It sits on top of your orgs and sandboxes and tracks every change as a work item — a user story, a bug fix, a small enhancement — from the sandbox where it was built to the org where it needs to land.

Instead of remembering which fields, flows, and Apex classes belong to a change, you attach them to the work item as you go. When it is time to deploy, DevOps Center bundles exactly those components. Nothing more, nothing forgotten.

Change sets vs DevOps Center, in practice

Change sets are a snapshot: you hand-pick components, upload, validate, deploy, and hope. If two admins change the same field, the last deploy wins and nobody gets told. Rollback means rebuilding the old version by hand.

DevOps Center is a pipeline: each work item moves through stages — In Progress, Ready to Promote, In Review, Complete. Every promotion is a real deployment with validation, and the history of what went where is recorded. When a conflict appears, it shows up before deployment, not after.

Getting started in 4 steps

1. Install and connect your orgs. DevOps Center is a managed package you install in a dedicated org, then connect your development sandboxes and production as environments. One pipeline per project keeps things clean.

2. Create a work item for every change. Even a one-field fix gets a work item. This is the discipline that makes the whole system work — untracked changes are invisible changes.

3. Build in the sandbox, commit to the work item. As you make changes in the sandbox, DevOps Center detects them and lets you add them to the work item. Review the component list before promoting; it is your last chance to catch a stray change.

4. Promote through the pipeline. Promote the work item to the next stage — usually a test sandbox first, then production. Each promotion validates first, so a failing test stops the deploy before it touches production.

3 mistakes to avoid

Skipping tests in the pipeline. A promotion that does not run your Apex tests is a change set with better branding. Solid test coverage is what makes deployments boring instead of scary — our guide to Apex test classes and code coverage covers the rules that keep your tests honest.

Promoting straight to production. The test sandbox stage exists for a reason. A Flow that works in dev can still break against real data volumes and real user profiles. One extra promotion stage costs minutes; one bad production deploy costs a weekend.

Letting work items pile up unreviewed. A pipeline full of half-finished work items is just a change-set queue with extra steps. Review and promote weekly, or the backlog becomes the bottleneck.

Where DevOps Center still falls short

It is not a full CI/CD tool. If you need automated testing on every commit, branch-based development, or deployments triggered from GitHub, you will outgrow it and move to something like Salesforce DX with GitHub Actions or a dedicated DevOps tool. DevOps Center is the bridge between change sets and that world — and for most small teams, the bridge is enough.

It also pairs naturally with a modern local workflow. If your developers work in VS Code with the Salesforce extensions, the same work items map cleanly to scratch orgs and source-tracked sandboxes — see our walkthrough on setting up Claude Code for Salesforce development for how a terminal-based workflow fits alongside it.

The bottom line

DevOps Center will not make deployments fun. It will make them visible, repeatable, and hard to mess up quietly — and for a team that has ever lost a Friday to a failed change set, that is the whole point. Start with one project, one pipeline, and the rule that nothing deploys without a work item.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce Batch Apex: Processing Millions of Records Without Hitting Governor Limits

Rohan Mehta — Sat, 07 Nov 2026 11:42:19 +0000

Salesforce Batch Apex: Processing Millions of Records Without Hitting Governor Limits

If you have ever tried to update 50,000 records with a Flow or a trigger and watched Salesforce stop you cold, you have met governor limits. Batch Apex exists for exactly this problem: it breaks a huge job into small, safe chunks and processes them one at a time.

How Batch Apex actually works

A batch job has three parts. The start method collects the records to process — usually with a SOQL query locator. The execute method runs once per chunk (the default scope is 200 records) and does the real work. The finish method runs once at the end, which is where you send a summary email or kick off the next job.

That chunking is the whole point. Each execute call gets its own fresh set of governor limits, so a job that would blow up as a single transaction sails through as a batch.

5 practices that keep batch jobs healthy

1. Keep the scope small on purpose. The default 200-record scope is fine for simple updates, but if each record triggers heavy logic — callouts, complex calculations, related-record updates — drop the scope to 50 or even 10. A slower job that finishes beats a fast one that fails halfway.

2. Make execute idempotent. A batch can be retried, and a chunk can occasionally run twice. Write your logic so running it again on the same records changes nothing the second time. Check-before-update beats blind updates every time.

3. Never put SOQL or DML inside a loop. This is the oldest Apex rule in the book and it matters most in batch jobs, because a single sloppy loop multiplied across thousands of chunks is how orgs hit limits at 2 AM. Collect, then act on the collection.

4. Handle errors per chunk, not per job. Wrap risky logic in try-catch inside execute and log failures to a custom object or send a digest in finish. One bad record should never kill a 100,000-record job — and you should be able to find the bad record afterwards.

5. Test with realistic volumes. A batch that passes its test class with 200 records can still fail in production with two million. Your test classes should cover the empty batch, the single-chunk batch, and the multi-chunk batch. That coverage discipline is what keeps batch code deployable — see our guide on Salesforce test classes and code coverage.

When Batch Apex is the wrong tool

Not every big job needs a batch. If the work is under 50,000 records and runs on a schedule, a scheduled Flow may be simpler. If it needs to happen the moment a record changes, a record-triggered Flow or Queueable Apex fits better. Batch Apex shines for nightly data cleanup, mass recalculations, and migrations — the jobs where volume is the problem, not timing.

And before any large-scale update, clean the data first. A batch job that faithfully processes dirty data just produces dirty results faster. Our write-up on why every AI strategy needs data cleaning first applies just as well to batch jobs: garbage in, garbage out, at scale.

The bottom line

Batch Apex is not glamorous, but it is the workhorse behind every Salesforce org that handles real data volumes. Small scopes, idempotent logic, no queries in loops, per-chunk error handling, and honest testing — get those five right and your batch jobs will quietly do their work while you sleep.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce Flow Orchestration: Coordinating Multi-Step Automations

Rohan Mehta — Fri, 06 Nov 2026 11:40:58 +0000

Salesforce Flow Orchestration: Coordinating Multi-Step Automations

Most Salesforce automations start simple: one record changes, one Flow runs, one thing happens. Then the business grows. A new opportunity needs a task for sales, a Slack ping for delivery, a Chatter post for the account team, and a follow-up record for finance — and suddenly you have five Flows tripping over each other, firing in the wrong order, or duplicating work.

Flow Orchestration, generally available in recent releases, is Salesforce's answer to that sprawl. Instead of five disconnected Flows, you build one orchestrated process with stages and steps, each step assigned to a person, a group, or an automated Flow — and the platform handles the sequencing, handoffs, and tracking.

What orchestration actually does

An orchestration has stages, and each stage has steps. A step can be:

An automated Flow — a record-triggered or autolaunched Flow that does the work.
A background step — an Apex action or invocable action.
An interactive step — a screen Flow or approval assigned to a user or queue, with a due date.

The orchestration moves from step to step only when the previous one completes. If a step fails, the orchestration pauses instead of silently continuing — which is a big improvement over chaining Flows with platform events and hoping the order holds.

A practical example: new-customer onboarding

Take a new customer onboarding process. Stage one is automated: when the account's onboarding status flips to "Ready," a Flow creates the welcome tasks and the implementation project record. Stage two is interactive: the onboarding specialist gets a screen Flow to confirm the kickoff call happened, with a three-day due date. Stage three is automated again: a Flow provisions the customer portal user and sends the welcome email.

Without orchestration, that is three Flows, a couple of email alerts, and a dashboard someone has to watch. With orchestration, it is one process with a visible status — anyone can open the orchestration run and see exactly which stage a customer is stuck in.

Where it fits (and where it doesn't)

Orchestration shines for processes with handoffs between people and automation — approvals, onboarding, case escalation paths, quote-to-cash steps. It is overkill for a single "when X happens, do Y" rule. A plain record-triggered Flow is still the right tool there.

A few practical notes before you build your first one:

Map the process on paper first. Orchestration makes bad processes visible, not good. If nobody can agree on who does step three, the tool won't fix that.
Keep each step's Flow small. One Flow per step, one job per Flow — the same discipline that keeps Flow run context predictable applies here.
Use the orchestration run record for monitoring. It shows stage, step, assignee, and status in one place — far easier than tracing five Flow interviews.
Mind your limits. Orchestration runs consume Flow interviews like any other automation, so a high-volume process still needs governor-limit thinking.

Start small

Pick one process that currently lives in three Flows and a spreadsheet. Rebuild it as a single orchestration with two stages: one automated, one interactive. Watch it run for a week. If the team stops asking "where is this stuck?", you have your answer — and a pattern you can repeat for the next process.

For the building blocks, our guide to custom notifications in Flow covers alerting the right people at the right step — handy when an orchestration hands work to a human.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce Einstein AI: What Every Admin Should Know Before Turning It On

Rohan Mehta — Thu, 05 Nov 2026 11:41:22 +0000

Salesforce Einstein AI: What Every Admin Should Know Before Turning It On

Salesforce Einstein puts AI inside the CRM your team already uses — scoring leads, drafting emails, summarising cases, and predicting which deals will close. It sounds like magic, but for admins it is mostly configuration, data hygiene, and change management. Turn it on without a plan and you get confident-sounding predictions built on messy data. Here is what to get right first.

1. Einstein Is a Family of Features, Not One Switch

"Einstein" covers several products: Einstein Lead Scoring, Opportunity Scoring, Einstein Activity Capture, Einstein Generative AI (now part of Agentforce), and Einstein Prediction Builder. Each one is licensed and enabled separately. Before you promise anything to stakeholders, check exactly which Einstein features your edition and licences actually include — and which ones need an add-on.

2. Your Predictions Are Only as Good as Your Data

Einstein learns from your historical records. If your opportunity stages are inconsistent, your lead statuses are a free-for-all, or half your accounts are missing key fields, the model will learn those bad habits and repeat them at scale. Clean the data first: standardise picklists, close out stale records, and fix the required-field gaps. We wrote a longer guide on why every AI strategy needs data cleaning first — it applies to Einstein more than anywhere else, because the model trains directly on your org's history.

3. Permissions Decide What Einstein Can See

Einstein respects Salesforce sharing and field-level security, which is good news — but it also means a badly configured model can surface insights a user should not see, or hide the ones they need. Review object and field permissions before enabling scoring or generative features, and test with a real user profile, not just System Administrator. If your permission sets are tangled, start by getting your access model tidy before layering AI on top.

4. Start With One Use Case, Not Five

The teams that succeed with Einstein pick one painful, measurable problem — usually lead prioritisation or case summarisation — and pilot it with a small group. Measure the result for a month: are reps actually working the scored leads first? Are case summaries saving time or creating rework? A single win earns you the credibility to expand. Five half-finished pilots earn you a reputation for hype.

5. Generative AI Needs Guardrails, Not Just Prompts

Einstein Generative AI can draft emails and summarise records, but it will occasionally invent details. Set expectations with users: AI output is a first draft, not a send-ready message. Use the Einstein Trust Layer settings to mask sensitive data, and agree on which fields AI may never touch. A short internal policy — two paragraphs is enough — prevents most of the embarrassing mistakes.

6. Train Users on the "Why", Not Just the Buttons

A score on a lead record means nothing if reps do not trust it. Show them how the score is calculated, what signals matter, and what to do when they disagree with it. Feedback loops matter: when reps mark a prediction wrong, that correction improves the model over time. Einstein gets smarter only if humans stay in the loop.

The Bottom Line

Einstein is genuinely useful when it is switched on deliberately: clean data, tight permissions, one pilot use case, clear guardrails, and users who understand what they are looking at. Skip those steps and you will spend more time explaining bad predictions than you save. Get them right, and AI becomes the quiet assistant your team actually relies on — not another feature nobody trusts.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce Data Security: Field-Level Security, Profiles, and Shield Basics

Rohan Mehta — Wed, 04 Nov 2026 11:41:14 +0000

Salesforce Data Security: Field-Level Security, Profiles, and Shield Basics

Every Salesforce admin eventually faces the same question: who should see what? Get it wrong and sensitive salary data lands in front of the wrong team, or a well-meaning user edits a field they should only read. Get it right and security becomes invisible — people simply see what they need, nothing more.

Start with the principle of least privilege

The rule is simple: give each user the minimum access they need to do their job, and nothing extra. That sounds strict, but it is actually liberating. When access is tight and deliberate, you stop firefighting permission problems and start trusting your data.

Profiles are the foundation. Each user has one profile, and it controls the baseline: which objects they can see, create, edit, or delete, and which fields are visible. Think of a profile as the job description for access. Sales reps get one baseline, support agents another, managers a third.

Field-level security does the fine work

Object access is coarse. Field-level security is where the real control lives. A support agent may need to see a case, but not the customer's payment details stored on it. A sales rep may need to see an opportunity amount, but not the discount approval notes.

Set field visibility per profile: visible, read-only, or hidden. Review it whenever you add a new sensitive field — the default is often more open than you expect. One practical habit: whenever you create a field that holds personal, financial, or HR data, immediately check its field-level security before you move on. That thirty-second habit prevents most accidental exposures.

This pairs naturally with getting the basics right elsewhere in your org. If your required-field strategy is shaky, users will find workarounds that undermine security too — see our guide on how to make fields required in Salesforce.

Permission sets fill the gaps

Profiles are one-per-user, so they cannot cover every exception. That is what permission sets are for: small, targeted grants layered on top of a profile. A sales rep who occasionally approves discounts gets a permission set for that, not a whole new profile.

Keep permission sets small and named for what they do — "Approve Discounts up to 10%" beats "Extra Access 3". And where access should be temporary, use expiration dates so it removes itself. Our walkthrough on permission sets with an expiration date shows exactly how to set that up.

What about Shield?

Salesforce Shield adds three enterprise-grade layers: Platform Encryption, Event Monitoring, and Field Audit Trail. Most small teams do not need Shield on day one. But know when it matters: if you handle regulated data, need to prove who viewed a record, or must retain a long audit history, Shield is the conversation to have with your Salesforce partner.

Event Monitoring, in particular, answers the question every security review asks: who accessed what, and when? Without it, you are guessing.

A quick security checklist

Audit profiles once a quarter — remove access people no longer need.
Check field-level security on every new sensitive field.
Name permission sets clearly and expire temporary access.
Turn on login history and setup audit trail reviews.
Test as a real user: log in as a sales rep profile and try to see what you should not.

Security in Salesforce is not a one-time project. It is a habit of small, deliberate decisions. Start with least privilege, use field-level security for the fine work, and let permission sets handle the exceptions — your future self, facing an audit, will be grateful.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce Omni-Channel Routing: Getting Cases to the Right Agent Faster

Rohan Mehta — Tue, 03 Nov 2026 11:41:03 +0000

When support volume grows, the bottleneck is rarely effort — it is routing. Cases sit in a shared queue while agents cherry-pick the easy ones, urgent issues wait behind routine ones, and customers repeat themselves because the case lands with someone who has no context. Salesforce Omni-Channel exists to fix that: it pushes work to agents based on capacity, skills, and priority, instead of letting agents pull whatever looks easiest.

Start with capacity, not channels. An agent handling three live chats cannot also take a complex phone case well. Set realistic capacity per channel — for example, two chats plus one case at a time — and let Omni-Channel enforce it. Overloading agents looks productive on a dashboard and feels terrible in practice: slower first responses, more transfers, and more mistakes.

Next, route by skill, not just availability. A billing question and a technical outage are not interchangeable work. Use skills and routing rules so that product specialists get product cases and billing specialists get billing cases. The first-touch resolution rate improves fast when the first agent is actually the right agent.

Presence statuses deserve the same care. If "Available" means everything, agents will go invisible to survive the day. Create clear statuses — Available for Cases, Available for Chat, Break, Meeting, Offline — and make sure supervisors can see who is genuinely available versus who is marked available while buried in follow-ups.

Prioritise explicitly. Not every case is equal, and a first-in-first-out queue pretends otherwise. Give high-priority and SLA-sensitive cases a faster lane, and review the queue rules monthly. Routing rules written once and never revisited quietly rot as products, teams, and volumes change.

Finally, connect routing to the rest of the org. A case that arrives from Slack or a form should carry its context with it, not start from zero. Our walkthrough of setting up Slack with Salesforce shows how to keep that context attached, and custom notifications built with Flow can alert the right team the moment a high-priority case lands instead of waiting for someone to refresh a queue.

Good routing is invisible to customers. They just notice that the first person they talk to can actually help, and that nobody asks them to start over.

Originally published at Way2Force

Salesforce Marketing Cloud: Campaigns, Journeys, and First Steps for New Teams

Rohan Mehta — Mon, 02 Nov 2026 11:42:16 +0000

Marketing Cloud can look intimidating from the outside. Journeys, automations, data extensions, studios — the vocabulary alone is enough to stall a first project. But at its core, Marketing Cloud does one simple job: it helps a team send the right message to the right person at the right time, and learn from what happens next.

Start with the audience, not the tool

Before building anything, get clear on who you are talking to. A list of contacts is not an audience. An audience is a group of people who share a need, a stage in a buying journey, or a relationship with your business.

Start with one segment you understand well — for example, new trial users, or customers who bought in the last 90 days. Build your first campaign for them only. A narrow, relevant first campaign teaches you more than a broad blast that pleases nobody.

Good data habits matter here just as they do inside Sales Cloud. If your contact data is messy, your campaigns will be too — duplicate records, stale emails, and missing fields quietly undermine even the best-designed journey. Clean data first, then automate.

Campaigns vs journeys: what's the difference?

A campaign is a single coordinated effort — a launch email series, a webinar invitation, a seasonal promotion. A journey is the automated path a person follows over time, with branches based on what they do: open, click, ignore, buy, or go quiet.

Think of it this way: the campaign is the event, the journey is the experience around it. A new subscriber might enter a welcome journey, receive three helpful emails over two weeks, and then move into a nurture journey based on what they clicked. Nobody has to remember to send each message by hand.

For a first project, keep the journey short: a welcome series of three emails, or a post-purchase follow-up of two. Short journeys are easier to test, easier to fix, and far more likely to actually ship.

Build in small, testable pieces

Marketing Cloud rewards teams that build incrementally:

One data extension, well structured. Don't import every field you own. Import the fields this campaign actually uses.
One email, well written. A clear subject line, one idea, one call to action.
One journey, with a clear entry and exit. Know exactly who enters, what happens, and when they leave.
One report you actually read. Open rate alone tells you little. Look at clicks, bounces, and unsubscribes together.

Testing matters more than polish. Send to a small test group first, check rendering on mobile, and confirm every link works. A broken link in a mass send is embarrassing; a broken link caught in testing is just a Tuesday.

Connect marketing to sales

Marketing Cloud works best when it is not an island. When a lead engages — clicks a key link, downloads a guide, replies to an email — that signal should reach the sales team in Salesforce, not sit in a marketing report nobody reads.

That connection is what turns campaigns into pipeline. It is also where many teams stumble: marketing celebrates opens while sales complains about lead quality. Agree upfront on what counts as a qualified signal, and make sure both teams can see the same record.

If your team already connects Salesforce to everyday tools, the same thinking applies here — for example, our guide on setting up Slack with Salesforce shows how a simple integration keeps the right people in the loop without extra manual work.

What to avoid in the first 90 days

Buying a huge contact list. It damages deliverability and trust.
Building a 20-step journey before you have sent one email.
Measuring only opens. Clicks, replies, and conversions matter more.
Letting marketing and sales use different definitions of a good lead.
Automating a message you would not want to receive yourself.

A practical first-month plan

Week one: define one audience and clean its data. Week two: write and test one welcome email. Week three: build a three-step welcome journey. Week four: review the results, fix what underperformed, and plan the second journey. That is a real Marketing Cloud practice — not a demo, not a deck, but a working system your team can build on.

Marketing Cloud does not reward the team with the most features switched on. It rewards the team with the clearest audience, the simplest journey, and the discipline to learn from every send.

Originally published at Way2Force

Salesforce Dynamic Forms: Showing the Right Fields at the Right Time

Rohan Mehta — Sun, 01 Nov 2026 11:40:58 +0000

Salesforce Dynamic Forms: Showing the Right Fields at the Right Time

By Rohan Mehta, Salesforce writer at Way2Force.

Most Salesforce page layouts show every field to every user, whether they need it or not. The result is a long, noisy form where reps scroll past fields that don't apply to them, skip the ones that do, and enter bad data out of sheer fatigue. Dynamic Forms fixes that by letting you control field visibility on Lightning record pages — without code.

1. Start with the sections, not the fields

Dynamic Forms works at the section level on Lightning record pages. Before you touch visibility rules, sketch the page as a user would experience it: which fields matter at qualification, which matter after the deal closes, which only finance should ever see. If you can't explain why a section exists, it probably shouldn't be on the page at all.

2. Use visibility rules for genuine conditions, not clutter

A visibility rule like "show Billing Address only when Type is Customer" is a good rule — it removes noise for prospects. A rule like "show this field only when three picklists align" is usually a sign the process needs simplifying, not more conditions. Keep rules readable: the next admin should understand them at a glance.

3. Don't forget required fields still need a home

Making a field invisible doesn't make it optional. If a field is required at the object level, hiding it from a page can block saves with a confusing error. Pair visibility work with a clear required-field strategy — our guide on how to make fields required in Salesforce walks through the options and their trade-offs.

4. Test as each profile, not just as admin

Admins see everything, so admin testing hides visibility bugs. Open the page as a sales rep, a support agent, and a manager. Check the mobile view too — a clean desktop layout can still collapse badly on a phone.

5. Pair forms with automation, not against it

Dynamic Forms controls what people see; Flow controls what happens next. When a field appears conditionally, make sure the downstream automation expects it — a Flow that assumes a value will always be present will fail silently when the field was hidden. Our guide on Flow run context is a useful companion when you're wiring the two together.

Clean forms are a trust exercise. Every field you remove from someone's view is time back for real work — and fewer bad records for everyone downstream.

Originally published at Way2Force.

Salesforce Approval Processes: Designing Approvals That Don't Stall Deals

Rohan Mehta — Sat, 31 Oct 2026 11:40:58 +0000

Salesforce Approval Processes: Designing Approvals That Don't Stall Deals

Sales reps hate waiting. Managers hate approving from a cluttered inbox. And admins hate the ticket that says "my approval is stuck." Most approval pain isn't a Salesforce limitation — it's design. A few deliberate choices up front keep approvals fast, visible, and hard to break.

1. Approve the record, not the spreadsheet

If approvals still live in email threads and chat messages, there's no audit trail and no single source of truth. Move the decision into Salesforce so every approval, rejection, and comment is stamped on the record. When someone asks "who approved this discount?", the answer should be one click away, not a search through inboxes.

2. Keep the approval chain short

Every extra approver is another chance for a delay. Map the real decision: who actually needs to say yes, and who just wants to be informed? Inform the second group with a notification instead of a step. A three-step chain that finishes in a day beats a six-step chain that finishes next week.

3. Make the approval request answerable in one glance

Approvers decide fast when the request shows the what, the why, and the impact. Put the key fields on the approval page: amount, discount, close date, and the reason for the exception. If an approver has to open three related records to understand the request, they'll postpone it — and postponement is where deals stall.

4. Set a fallback for every step

Approvals break when the designated approver is on leave. Assign a delegate or a queue as the fallback for each step, and test it before go-live. A queue-based step is often better than a named individual: anyone on the team can act, and nothing waits on one person's holiday.

5. Notify where people actually work

An approval email that lands in a crowded inbox is easy to miss. Pair email alerts with in-app notifications so approvers see pending items when they open Salesforce — and keep the notification short, with a direct link to the approval page. For teams that live in chat, a Slack notification pointing back to the record closes the loop fast. See our guide to connecting Slack with Salesforce.

6. Lock what matters, leave the rest editable

Approval processes lock records by default, which frustrates users who need to fix a typo while waiting. Decide deliberately: lock the fields that affect the decision (amount, discount, terms) and leave harmless fields editable. Document the choice so users understand why some fields are greyed out.

7. Test the unhappy paths

Happy-path testing catches almost nothing. Test rejections, recalls, resubmissions, and skipped steps. What happens when a deal is rejected, edited, and resubmitted — does the chain restart cleanly? Does the submitter get told why? Most "stuck approval" tickets trace back to an unhappy path nobody tested.

The bottom line

Good approval design is boring in the best way: short chains, clear requests, real fallbacks, and notifications people actually see. Get those right and approvals stop being the bottleneck — they become the part of the process nobody thinks about, because they just work.

Originally published at Way2Force — practical guides on Salesforce Flow, automation, and CRM.

Salesforce List Views: 6 Filters and Tricks That Save Admins Hours Every Week

Rohan Mehta — Fri, 30 Oct 2026 11:41:11 +0000

Most Salesforce admins live in list views all day — and most of them only use a fraction of what list views can do. A well-built list view is not just a filtered table. It is a daily workflow: triage queue, follow-up list, data-quality radar, and manager report, all in one click.

Here are six practical list-view habits that pay off every single week.

1. Build views around a job, not an object

"All Opportunities" helps nobody. "My Open Opps Closing This Month, No Activity in 7 Days" helps a rep start Monday morning without thinking. Name the view after the job it does, and set the filter to match: owner equals current user, stage not closed, close date this month, last activity older than seven days.

The same principle applies to any triage work. Before you build a view, write down the exact question it answers. If you cannot state it in one sentence, the view will become clutter.

2. Use relative date filters, not fixed dates

A view filtered to "Close Date equals October 2026" dies on November 1. Relative filters — this week, next 30 days, last 7 days — keep working without maintenance. This is the same discipline as keeping your data clean in the first place: a view built on stale criteria quietly misleads everyone who trusts it. If your underlying data is messy, no view will save you — which is why clean data has to come before any AI or reporting strategy.

3. Pin the columns that decide the next action

Every column in a list view should earn its place by helping someone decide what to do next. Owner, stage, amount, next step, and last activity date are usually enough for an opportunity queue. Ten columns of context nobody reads just slow the page down and bury the signal.

If a field only matters once a quarter, leave it off the view and keep it on the record page instead.

4. Share views deliberately, and clean up the rest

A shared folder full of abandoned views is worse than no views at all — people stop trusting the list and go back to exporting spreadsheets. Review shared list views quarterly: who owns each one, who actually uses it, and whether its filters still match how the team works. Delete or unshare the dead ones.

5. Pair list views with inline editing — carefully

Inline editing from a list view is a huge time saver for bulk updates like next steps or close dates. But it is also how bad data spreads fast. Limit inline editing to fields with validation behind them, and pair it with required-field discipline on the records themselves, so a quick edit cannot create a half-finished record.

6. Use list views as a data-quality radar — and automate the follow-up

A list view finds the problem; automation fixes it at scale. Once a view surfaces, say, records stuck without a next step, a well-designed flow running in the right context can route, remind, or escalate them without manual chasing.

A "records missing key fields" view is the cheapest data-quality tool in Salesforce. Build one per object: accounts with no industry, contacts with no email, opportunities with no next step. Review it weekly, fix what you find, and watch the counts fall. Clean data makes every report, flow, and automation downstream more trustworthy.

The bottom line

List views reward a little upfront thinking with hours saved every week. Build them around real jobs, keep the filters relative, keep the columns tight, and prune them regularly. Your future self — and every user who opens Salesforce on Monday morning — will feel the difference.

Originally published at Way2Force.

Salesforce Data Import: Data Loader vs Import Wizard — When to Use Each

Rohan Mehta — Thu, 29 Oct 2026 11:41:01 +0000

Salesforce Data Import: Data Loader vs Import Wizard — When to Use Each

Every Salesforce admin eventually faces the same question: a spreadsheet full of records needs to get into Salesforce, and there are two official tools staring back at you — the Data Import Wizard and Data Loader. Pick the wrong one and you either hit a record limit halfway through or spend an afternoon doing by hand what a bulk tool could have done in minutes.

The Import Wizard: fast, guided, limited

The Data Import Wizard lives right inside Setup, and it is the right call for small, simple imports. It handles up to 50,000 records, walks you through field mapping step by step, and covers standard objects like accounts, contacts, leads, and custom objects. If you are loading a cleaned list of a few thousand contacts, this is the fastest path from spreadsheet to Salesforce.

Its limits are real, though. It cannot import every object, it caps out at 50,000 records, and it offers no command-line or scheduled option. It is a guided tool for one-off jobs, not a pipeline.

Data Loader: bulk, flexible, and worth learning

Data Loader is a separate desktop application (with a command-line mode) built for bulk work. It handles millions of records, supports insert, update, upsert, delete, and export, and works with nearly every object. Upsert is the feature that matters most: match on an external ID and Data Loader decides whether each row creates or updates a record, which is exactly what recurring imports need.

The trade-off is setup. You install it, authenticate, and map fields yourself — there is no friendly wizard holding your hand. But once you have done it twice, a 200,000-record load is a ten-minute job instead of a weekend project.

The decision rule I use

Under 50,000 records, standard objects, one-off load: use the Import Wizard.
Over 50,000 records, upserts, recurring loads, or any object the wizard does not cover: use Data Loader.
Either way, clean the data first. No import tool fixes bad data — it just loads bad data faster. Our guide on why every AI strategy needs data cleaning first makes the same point for a different reason: garbage in, garbage out, whatever the tool. And if your import feeds an automation, check how Flow run context works before you automate anything against the imported records.

Before you hit import

Three checks save more imports than any tool choice: deduplicate the file before loading (Salesforce will happily create the duplicates you feed it), validate required fields and picklist values against your org, and always run a small test batch — fifty rows — before the full load. A test batch that fails costs you five minutes. A full load that fails costs you a cleanup project.

Pick the tool that matches the size and repeatability of the job, test with a small batch, and importing stops being the scary part of the week.

Originally published at Way2Force

Salesforce Sharing Rules Explained: OWD, Role Hierarchy, and Manual Sharing

Rohan Mehta — Wed, 28 Oct 2026 11:41:35 +0000

Most Salesforce orgs start open and get locked down only after someone sees data they shouldn't. Sharing is easier to get right if you build it in layers, from the broadest default to the narrowest exception.

Start with organization-wide defaults

Organization-wide defaults (OWD) set the baseline for each object: Private, Public Read Only, or Public Read/Write. Private is the safest starting point for sensitive objects like cases or opportunities — you can always open access up later, but clawing it back after users have built reports and habits around open data is painful.

Set OWD deliberately, object by object. An object that holds customer financial details deserves Private; a reference object like a product catalog can stay Public Read Only without much risk.

The role hierarchy does the heavy lifting

The role hierarchy grants access upward: managers see what their reports see. This is usually the right shape for a sales org, where a regional manager legitimately needs their team's pipeline.

The trap is building a hierarchy that mirrors the org chart too literally. Every extra level is another path for data to flow upward, and roles created for reporting convenience can quietly widen access. Keep the hierarchy as flat as the business allows, and review it when teams reorganize.

Sharing rules fill the gaps

Sharing rules open access sideways — for example, giving the support team read access to accounts owned by sales, or letting a partner team see cases in their region. They are rule-based, so they stay consistent as records change, unlike one-off manual shares.

Keep sharing rules few and well-named. A dozen overlapping rules on one object is a sign the data model or the role design needs rethinking, not more rules.

Manual sharing is the exception, not the system

Manual sharing lets a record owner share a single record with a specific user or group. It is useful for genuine one-offs — a deal that needs a specialist's eyes for a week. It is a poor substitute for a rule: manual shares are invisible in most audits, they survive after the reason is gone, and nobody remembers to remove them.

If you find yourself manually sharing the same kind of record repeatedly, that is a sharing rule waiting to be written. The same discipline applies to automation: when access depends on who runs a process, understanding how flow run context works keeps you from accidentally granting a flow more access than its user should have.

A quick audit checklist

OWD set to the most restrictive sensible default per object.
Role hierarchy reviewed after every reorg.
Sharing rules documented with their business reason.
Manual shares reviewed quarterly and removed when stale.
Field-level security checked alongside record access — a shared record with sensitive fields exposed is still a leak.

Sharing done well is invisible: users see exactly what they need, and nothing they don't. That is worth an hour of design before it becomes a cleanup project.

Originally published at Way2Force