Jair Talks Salesforce — English

Dreamforce 2026: Five Takeaways on Salesforce MCP

Sat, 03 Oct 2026 00:00:00 +0800

I attended Dreamforce 2026 in person this year. Every year, Dreamforce offers small hands-on challenges called Mini Hacks to introduce the technologies Salesforce is focusing on. This year there were five challenges: three involved MCP, while the other two covered model selection and React.

That mix of topics tells a story: Salesforce is bringing CRM capabilities into the AI tools people already use.

Rather than walk through the setup steps, I want to share five things that stood out to me as a developer working with Salesforce every day.

1. A new interface layer: AIforce

According to this year’s keynote, Salesforce now has four layers:

Interface layer: AIforce. The initial entry points include Claudeforce in Claude, Slackforce in Slack, and Agentforce Coworker in Lightning.
Agent layer: Agentforce.
Application and semantic layer: Sales Cloud, Service Cloud, and other applications.
Data layer: Data 360.

Why add an interface layer? Employees spend their day across email, documents, presentations, and communication tools as well as CRM. More people are doing their work directly in AI tools. CRM needs to participate in that ecosystem; asking users to return to Salesforce every time they need an agent adds friction.

The mechanism for bringing these capabilities into other tools is MCP (Model Context Protocol), a standard protocol connecting AI clients to external services. A service exposes its capabilities as tools. Each tool has a natural-language description that helps the AI decide which one to call.

In Salesforce, MCP configuration lives in Setup. Standard servers provide CRUD and search tools. Custom servers can expose Flows, Apex, agents, and Prompt Templates as tools. Once configured, a server gives you a URL to add to an MCP-compatible client. The Tableau Next and Slack Mini Hacks follow the same pattern, with different sources of capabilities and different entry points.

2. Development is shifting from building pages to designing tools

During the Mini Hack, I first tried using only the standard server. The AI could complete a multi-step booking workflow using CRUD, but it had to query and create records object by object. It was slow, and it had to work out the relationships between objects each time. The results were inconsistent, too.

When I wrapped the entire workflow in a Flow and exposed it as a single tool, one call completed the process.

My takeaways:

Package frequently used core workflows into tools with the right scope. Do not expect the AI to assemble them from individual CRUD operations every time.
The tool description is the new UI. Previously, people interacted with buttons and forms. Now the model interprets tool names, descriptions, and parameter explanations. Their clarity directly affects whether it selects the right tool and passes the right inputs.
Standard servers cannot be modified, but their tools can be combined. Create a custom server, use Add from Server to include the standard tools you need, then add your own Apex actions. This lets you assemble different servers for different roles.

An agent has a brain, but its ability to act depends on the tools we give it.

3. Plan authentication and security early

Connections use an External Client App (ECA). A few configuration details are easy to miss:

Select the mcp_api OAuth scope; the ordinary api scope is not sufficient. Add refresh_token as well.
Enable Require PKCE and Issue JWT-based access tokens for named users.

The bigger question is whose identity the tools run under. When an external AI client calls your exposed Apex, it acts as the authorized user. Custom Apex actions therefore need to respect sharing rules and field permissions, using mechanisms such as with sharing and WITH USER_MODE. Treat parameters from the model as user input, and do not concatenate them directly into dynamic SOQL. In the MCP era, you can no longer assume that only an internal page will call your code.

Salesforce is also introducing a permission configuration called Scoped Access. It addresses the situation where an AI client acts on behalf of a user whose permissions are broader than the client needs. Scoped Access lets you adjust the permission scope for that context rather than simply relying on the user’s full set of permissions.

4. Cost: MCP calls will consume Flex Credits

This is easy to overlook when designing a solution. A breakout session noted that successful MCP calls in production will consume Flex Credits. According to published reports, each successful call will count as a “Headless Platform Interaction,” tracked in Digital Wallet. The exact credit rate has not yet been announced. The rollout is planned for around November, alongside agent registration and security controls, with 30 days’ notice before billing begins.

This reinforces the point about tool design: well-scoped tools require fewer calls, which can reduce cost. Having an AI assemble a workflow one CRUD operation at a time can be expensive as well as slow.

5. More choice in models and front-end frameworks

The other two Mini Hacks may seem unrelated to MCP, but they reflect the same direction: greater openness.

Models can be changed. Prompt Templates and agents can use different models. In the new Builder, which uses Agent Script, each subagent can specify its own model through model_config. My approach: if prompt refinement stops improving inconsistent results, test another model. Start with a less expensive model, and reserve stronger models for the subagents handling complex tasks. Always rerun your test cases after changing models, because models differ in how they use tools. Agents built in the older Builder can move to the new version using the official Upgrade feature.
React is an option for the front end. Multi-Framework is now generally available, and React applications can be deployed to Salesforce as UI Bundles. When I asked “React or LWC?” at the event, the answer was direct: if your team knows React, use React. My view is that React fits complex, customer-facing single-page applications, while LWC remains the main choice for internal applications that need standard Lightning components.

Try it yourself

Trailhead now has modules covering AIforce. Search for them on Trailhead if you want to explore these capabilities hands-on.

Closing thoughts

My biggest takeaway from Dreamforce 2026 is that what Salesforce developers build for is changing. We still build interfaces for people, and now we also design tools for AI. Those tools need the right scope, clear descriptions, carefully enforced permissions, and attention to AI costs.

Translated from my Chinese article, originally published on the SalesforceTalk WeChat account. Read the original on WeChat.

How Agentic AI Changes the Work of Salesforce Admins and Developers

Mon, 25 May 2026 20:00:00 +0800

Agentic AI changes what Salesforce administrators and developers build, and how they build it. My original article presented this idea as a Chinese infographic based on TDX 2026. This English text edition makes its main points available without requiring the reader to interpret the image.

The shift is toward intent-driven development: describe the outcome, let AI assist with planning and implementation, then evaluate the result against the business requirement.

1. What makes an agent different?

An agent combines interpreting an instruction with reasoning, planning, and taking actions through available tools. A request such as “send the report to the sales team” can involve several steps rather than one response.

This is a useful design direction, not a guarantee that an agent always understands the request correctly. The outcome still depends on its instructions, tools, permissions, and the evidence supplied to it.

2. Why it matters for Salesforce work

AI can help interpret requirements, generate code and configuration, handle repetitive tasks, and connect work across systems. That changes the allocation of effort: less time on repetitive production of artifacts, more on architecture, design, evaluation, and improvement.

The developer’s responsibility does not disappear when a model generates the code. Someone still has to decide whether the implementation fits the requirement and operates safely in the platform.

3. From writing every line to guiding the work

The infographic describes a workflow with four parts:

Express the intended outcome.
Let an AI assistant reason about and generate an implementation.
Review the resulting artifact.
Correct and improve it through feedback.

The skills this requires include making intent clear, evaluating generated code, understanding architectural trade-offs, and shaping the behavior of an agent. Producing code is one part of a wider engineering process.

4. Openness, choice, and trust

Another theme is using AI tools alongside the Salesforce platform rather than limiting all work to one interface. MCP is one way to connect a compatible AI client to capabilities exposed by a service.

The original infographic contrasted external coding assistants with the platform’s own developer experience. The practical question is which environment fits the work, while maintaining the required controls around code, data, and access.

For more detail on exposing useful capabilities through MCP, see my Dreamforce 2026 MCP article.

5. An application and an agent can work together

An application provides visible structure: components, forms, validation, and a familiar workflow. An agent provides a conversational way to interpret a request and coordinate several steps.

These strengths are complementary. A conversation can guide the task, while a form or record view supplies a clear interface for entering details and reviewing the result. The best experience does not have to force every interaction into text.

6. Evaluate behavior, not only artifacts

Traditional application tests check defined behavior under particular inputs. Agent evaluation also needs to examine how the agent interprets varied requests, chooses tools, and handles uncertainty.

The infographic highlights Testing Center and observability as parts of that process. The underlying practice is to test representative prompts, inspect failures, and improve the behavior with evidence.

A successful demonstration is not enough. Check variations in wording, missing information, tool failures, and whether the agent asks for clarification at the right point.

7. What this means for administrators

For administrators, the opportunity is to use natural-language assistance with configuration and automation, and to spend more time understanding business problems.

Flows, reports, pages, and formulas still need a coherent design. AI assistance is most useful when the administrator can explain what the business needs and verify that the resulting configuration satisfies it.

8. The skills worth developing

The infographic brings together several capabilities:

Understanding the business and its users.
Expressing intent clearly.
Working with AI while judging the output critically.
Reviewing quality and applying governance.
Testing and observing agent behavior.
Continuing to learn as the tools change.

These build on existing platform knowledge. Knowing the data model, security model, and transaction boundaries remains important when another system helps produce the implementation.

9. Learn with the community

Hands-on experiments, hackathons, and shared Trailblazer examples help turn an abstract idea into practical experience. Study how others approach the same problem, then test the pattern against your own requirements.

My main takeaway from the infographic is that administrators and developers increasingly act as designers and reviewers of AI-assisted work. Their business understanding and technical judgment become more important as more of the implementation can be generated.

Source for the original infographic: TDX 2026 Highlights, S1E33.

Originally published on 2026-05-25. English edition revised on October 3, 2026. Adapted the Chinese infographic into an English text article. Read the Chinese original.

Four Practical Patterns for Reactive Salesforce Screen Flows

Sun, 24 May 2026 11:33:23 +0800

Screen Flow reactivity lets components on the same screen respond to one another as the user works. A checkbox can disable an input, a formula can turn a subject into a suggested priority, and several inputs can contribute to a calculated date—all without asking the user to click Next.

The useful pattern is to treat a screen as a small interactive application. Components supply values, formulas transform them, and other components use the results. Here are four examples from my original article.

1. Let one component control another

Add a Checkbox component called Confirmation and a Text component called Subject. Bind the Text component’s Disabled property to the checkbox’s Boolean value.

When the user selects the checkbox, the subject becomes read-only. When they clear it, they can edit the subject again. This is useful for an explicit confirmation step before submission.

The connection is direct: the checkbox is the source, and the Disabled property is the target. No formula is needed if the source already provides the right type.

2. Use a formula as a routing layer

A formula becomes useful when the target needs a different value from the one the user entered. Suppose the subject should suggest a high priority when it contains “urgent.” A Text formula resource can express that rule:

IF(
    CONTAINS(LOWER({!Subject}), "urgent"),
    "High",
    "Normal"
)

Reference the formula as the default value of a compatible priority component. Its choice values must match High and Normal; labels and stored values are not necessarily identical.

This produces a suggested priority, not a complete business validation rule. Check how the component behaves after the user manually changes it, and decide whether that choice should take precedence over the suggestion.

3. Combine inputs to calculate a date

The original example combines a priority-based number of days with a Slider adjustment. Configure the priority choice to provide a numeric value and create a Date formula such as:

TODAY()
+ BLANKVALUE({!PriorityDays}, 0)
+ BLANKVALUE({!AdjustmentDays}, 0)

Use the result as the default value for a compatible Date component. A user can change either input and see the proposed due date update on the same screen.

Explicit defaults matter. The formula should behave sensibly before all inputs have values. Also, this example adds calendar days; a requirement for business days needs a different calculation.

4. Show the right message at the right time

Use conditional visibility to show an approval warning when the Slider exceeds a threshold. For example:

Show the warning when AdjustmentDays > 3.
Show the normal guidance when AdjustmentDays <= 3.

These conditions cover the boundary value of exactly three days. Otherwise, it is easy to accidentally create a state where neither message appears.

The result is immediate guidance: the screen tells the user when their choice requires attention, rather than waiting until they submit it.

What to check before shipping

Reactivity is supported by particular components, properties, and formula functions—not by every resource in Flow Builder. Check the flow’s API version and test initial values, cleared values, user overrides, and returning to the screen. Salesforce lists the supported components and formula operators.

My takeaway is that formulas can serve as the small logic layer between screen components. A handful of clear connections can make a flow feel responsive without adding a separate screen for every decision.

Originally published on 2026-05-24. English edition revised on October 3, 2026. Expanded with illustrative formulas and implementation considerations. Read the Chinese original.

Salesforce Archive: Retention, Access, and Cost Considerations

Sat, 31 Jan 2026 18:12:53 +0800

As a Salesforce org grows, old records compete with current work for storage and attention. Closed cases, completed activities, and historical custom-object records may need to remain available even when users rarely open them.

Deleting everything is often unsuitable, while keeping everything in the primary org can become expensive and cumbersome. That is the problem I wanted to explain in my original article about Salesforce Archive.

Separate active data from historical data

The architectural idea is to distinguish two kinds of records:

Active data supports current business processes and frequent access.
Historical data is retained for reference, analysis, or the organization’s retention requirements.

An archive policy determines when a record moves from the first group to the second. A backup serves a different purpose: recovering data after an incident. An archive needs an intentional access and retention model for historical information.

Clarify which Archive product you are discussing

There is an important terminology issue when updating an older article. Salesforce’s current Archive product page describes automated policies, storage analysis, access to archived records, and restoration.

Salesforce also documents Legacy Salesforce Archive, an external-storage solution with a different setup and access model. Do not assume that a reference to AWS, Azure, or Salesforce Connect applies equally to every offering called Archive.

For an evaluation, identify the exact product, entitlement, and storage architecture before designing the solution or estimating costs.

Four capabilities to evaluate

1. Automated policies

Start with a business rule rather than a storage target. For example: a record is closed, older than the agreed retention threshold for active data, and no longer required by an active process.

Translate that rule into the product’s supported policy configuration. The expression “older than three years” is a business condition, not a ready-to-run SOQL expression. Also consider related records; removing a parent without preserving needed context can leave historical data difficult to interpret.

2. Access from the user’s workflow

Moving data out is only half of the problem. Users need a way to find and understand it afterward. Decide who may view archived data, where it appears, and when a record needs to be restored.

“Accessible” should be tested against real tasks. Can a support representative find an old case? Can they see the related information needed to interpret it? Does a report that once used active records still satisfy its requirement?

3. Storage and operating cost

The expected saving depends on the actual contract, data volume, growth, and access pattern. Include the archive subscription and the work needed to operate it, not just a comparison between storage unit prices.

An external-storage design may also involve infrastructure and connector costs. Those belong in the estimate only when they are part of the selected architecture.

4. Retention and governance

Define how long information remains available, who controls the policy, and how exceptions are handled. Retention, restoration, deletion, and records subject to a hold need a consistent operating process.

A configured retention period should implement your organization’s requirements; it is not a substitute for deciding what those requirements are.

When archiving is worth evaluating

Three useful signals from the original article remain relevant:

Storage is dominated by historical records that users rarely access.
Important queries or reports are becoming difficult to operate at the current volume.
The business needs historical access, but keeping every record active is costly.

Investigate performance separately. A large record count does not by itself diagnose data skew or prove that archiving will fix a slow query. Access patterns, relationships, query design, and indexing still matter.

Pricing: use an actual quote

The original article included a community price estimate whose units did not match its annual calculation. That estimate is intentionally omitted here.

Salesforce currently describes pricing as tailored to the customer’s archiving needs. Obtain a quote for the specific product and volume, then compare the full operating cost with your alternatives. A historical community number is not a reliable budget for a new project.

My recommendation

Begin with a retention and access policy, then evaluate the implementation. Some orgs need an archive product; others may have a simpler requirement for export, retention, and controlled deletion.

The goal is to keep the production org useful while preserving the historical information the business actually needs. That requires a clear access model as much as a place to store the data.

Originally published on 2026-01-31. English edition revised on October 3, 2026. Distinguished current and legacy Archive offerings and removed the inconsistent community price estimate. Read the Chinese original.

Using AI to Build a Salesforce Learning Plan from Your Trailhead Profile

Sun, 18 Jan 2026 12:56:57 +0800

Making a learning plan at the start of the year is a familiar routine. As a Salesforce professional, I normally combine Trailhead’s learning paths with my own experience to choose the certifications worth pursuing.

For my 2026 plan, I tried a different approach: using ChatGPT and Gemini as advisers to cross-check my choices.

1. Start with the right data

My first attempt was to ask Gemini for recommendations directly. It suggested certifications I had already earned. The missing ingredient was my actual learning history.

My Trailhead profile already contained useful evidence: badges, superbadges, certifications, and the distribution of skills I had studied. However, giving Gemini the profile URL did not produce usable content in that attempt.

In the workflow described in my original article, I used ChatGPT with the Atlas browser to extract the profile into Markdown. The instruction was:

Extract the information on this page in detail as Markdown.
Keep all the details. Do not summarize.
Write the output in English.

Manually copying the visible profile text works as an alternative. The important part is to check the resulting document for omissions; the model should be analyzing your history, not reconstructing it from guesses.

2. Give the analysis a reusable reference

I saved the extracted Markdown in a Google Doc, including the badge and superbadge information and the skill distribution. In the setup I used, Gemini could access the document as a reference.

That gave me a reusable snapshot rather than a long, one-off message. I could return to the same evidence when reviewing the plan later.

My analysis prompt was:

Using this Trailhead profile's learning history and skill distribution,
and considering current developments in the Salesforce ecosystem,
recommend the two certifications most worth pursuing in 2026.
Explain the reasons for each recommendation.

For another person’s plan, I would also include their role, years of experience, the work they expect to do, and their available study time. These details help distinguish a relevant next step from a generic list of popular certifications.

3. Compare the reasoning with your own judgment

The result surprised me. Gemini recommended exactly the same two certifications I had already selected manually. More interestingly, its reasoning matched my own: it identified gaps in my existing skills and explained why those areas were appropriate next steps.

The useful result was the method: give the model a verified learning history, then compare its recommendations and reasoning against your own goals.

Agreement is not proof that a plan is optimal. Before enrolling in an exam, check the current credential information, prerequisites, and exam guide on Trailhead Credentials.

A prompt for the wider plan

If you want to work on goals beyond certification, this is a useful starting point:

Write my goals for the coming year.
Ask me the most important questions to craft the best possible set of goals.

The key lesson from this experiment was simple: better evidence produces more relevant advice. If the result feels generic, improve the input with your work history, responsibilities, and intended direction before asking for another recommendation.

Originally published on 2026-01-18. English edition revised on October 3, 2026. Translated the prompts and clarified that the browser and document workflow describes the original experiment. Read the Chinese original.

Using Platform Events to Offload Complex Apex Trigger Work

Sun, 27 Aug 2023 18:03:37 +0800

An Apex trigger often starts with a small responsibility and gradually accumulates expensive work: calculations, integrations, and updates across several objects. Eventually, that work needs a transaction of its own.

My original article explored using a Platform Event to wake an asynchronous worker, while keeping the actual work in persistent Salesforce records. The separation is still useful, but the event should be a notification rather than the only copy of the business request.

Why simply enqueueing more jobs can fail

A straightforward response to slow trigger work is to move it into a future method or a Queueable job. That can be appropriate, but the calling context matters. Synchronous and asynchronous transactions have different enqueue limits, and several triggers in one transaction may share the same budget.

Even record counts can be misleading. Two objects processed in separate trigger batches can produce more enqueue attempts than a single combined record count suggests. Repeated DML and recursive updates add further complexity.

Also, moving work into a subscriber does not make every operation legal there. If an Apex Platform Event trigger needs to initiate an HTTP integration, design the handoff to a callout-capable asynchronous job rather than assuming the event trigger can make the callout directly.

Keep the work in records; use the event to signal it

The pattern has three parts:

Mark or store the pending work. Update a status on the business record, or create a separate work-request record containing the information the worker needs.
Publish a notification. The event tells the subscriber that work is available.
Process and acknowledge it. The subscriber queries the durable work, handles an appropriate batch, and records successful completion.

This means a notification does not have to carry every business field. It can be a wake-up signal. Pending work remains discoverable even if a notification is missed or processing stops unexpectedly.

When the subscriber depends on records written by the publishing transaction, configure Publish After Commit. Otherwise, a subscriber may act before the corresponding data is committed. Salesforce describes the distinction in Platform Event publishing behavior.

Make pending work unambiguous

The original design used two timestamps and a formula to identify records needing processing. A useful interpretation is:

RequestedAt records the latest requested change.
ProcessedAt records the request that was successfully handled.
A record is pending when it has a request and either has never been processed or has a newer request than the processed one.

The worker must acknowledge the version it actually handled. If another transaction requests new work during processing, setting ProcessedAt to an unrelated “now” could accidentally clear that newer request. A separate request record or explicit version number can make this easier to reason about.

Timestamp fields are a tracking mechanism, not a locking mechanism. Concurrent workers still need a deliberate ownership or concurrency strategy.

Plan for retries and recovery

Asynchronous processing needs more than a happy path:

Make repeated processing safe. For an external operation, use an idempotency key that represents the business request.
Record success only after the required work is confirmed.
Preserve failure information and retry eligible work deliberately.
Monitor the age and volume of the backlog.
Provide a recovery process that can find pending records independently of the event stream.

In this design, a periodic recovery scan can coexist with event-driven processing. The event provides prompt execution; the durable backlog provides a way to catch up. Accepting a missed notification should not mean accepting lost business work.

Update the capacity assumptions

My 2023 article described a single processing stream. That should not be interpreted as an absolute limit for every current implementation. Salesforce documents parallel subscriptions for supported custom high-volume events, with work distributed by a partition key. Ordering and concurrent updates must be considered when selecting that key. See Parallel Subscriptions for Apex Triggers.

Capacity also depends on event allocations, subscriber configuration, batch size, processing time, and downstream limits. Publishing success is not the same as completed business processing. Check the current publishing and subscribing considerations for your org and event type instead of treating an old hourly figure as a universal budget.

When I would use it

Use a Queueable directly when the workflow is simple and the transaction’s enqueue budget is well understood. Consider a durable backlog plus Platform Event notification when several triggers need to hand off work, when the producer and consumer should be separated, or when independent recovery is important.

The valuable idea is not that Platform Events remove limits. It is that they let the trigger signal work while another transaction handles it, with the business state stored somewhere recoverable.

The original demonstration repository provides background for the pattern; adapt any sample to your current requirements and platform version.

Originally published on 2023-08-27. English edition revised on October 3, 2026. Revised capacity assumptions and added durable backlog, concurrency, callout, and recovery considerations. Read the Chinese original.

A Practical Guide to Debugging Lightning Web Components

Sat, 09 Mar 2019 08:25:29 +0800

Lightning Web Components run as JavaScript in the browser, so Chrome DevTools is an essential part of debugging them. Salesforce adds a few complications: code can be minified, framework files can interrupt stepping, and values can appear through proxies.

The workflow from my original article still has three useful parts: enable readable code, set breakpoints in your component, and configure DevTools so that it shows the information you need.

Enable Debug Mode for the right user

In Salesforce Setup, search for Debug Mode and open Debug Mode Users. Select the user doing the investigation and click Enable. Reload the page containing the component.

Debug Mode makes the component code easier to inspect. It is a troubleshooting setting, so enable it for the users who need it rather than assuming every user’s session should use the same configuration. Salesforce explains the behavior in Debug Mode.

Find your component and set a breakpoint

Open Chrome DevTools with the browser menu or a keyboard shortcut, then select Sources. Use the source tree or Open File to locate the JavaScript file for the custom component.

Click a line number to set a breakpoint. Reload the page or repeat the interaction that triggers the code. When execution pauses, inspect local variables, the call stack, and the values entering your handler.

A breakpoint placed after the initial render will not tell you what happened before that point. For initialization problems, reload with the breakpoint already set. For an interaction problem, repeat the actual action rather than only refreshing the page.

Ignore framework code deliberately

My 2019 article used Chrome’s older term, Blackboxing. The current UI calls the feature Ignore List.

In DevTools Settings, open Ignore List and add patterns for framework or library files that are distracting you. You can also use a source file’s context menu to ignore that particular script.

Be careful with broad patterns. A rule that excludes a large component directory can hide code you are trying to inspect. Confirm that your own component remains visible and available for stepping, and remove the rule when investigating a framework boundary.

The goal is to make stepping useful: you want to follow the behavior you own, while still being able to inspect the surrounding code when it matters.

Enable custom formatters

In DevTools Settings, open Preferences and enable custom formatters. This can make proxied values easier to read when debugging in Salesforce.

Inspect the value before and after the line that changes it. A console entry by itself can be ambiguous when an object is inspected later; pausing at the relevant line gives you a clearer picture of the code’s state.

Salesforce’s JavaScript troubleshooting unit covers source-file discovery, Ignore List, and custom formatters.

Account for Lightning Web Security

The browser environment matters. When Lightning Web Security is enabled, some debugging behavior differs from older screenshots or examples. A console message’s apparent source is not always the component file you expected.

Use Salesforce’s Debug with LWS Enabled guidance alongside the ordinary LWC debugging workflow. Do not infer the origin of an error solely from a framework filename in the console.

A repeatable investigation

For a practical debugging session, I would follow this order:

Reproduce the problem with the relevant user and record.
Enable Debug Mode for that user and reload.
Locate the custom component’s source file.
Set a breakpoint in the handler or lifecycle method involved.
Inspect inputs, state, and the call stack as the problem happens.
Use Ignore List and custom formatters to make the session readable.
Recheck the fix under the ordinary runtime settings.

The useful habit is to connect the visible symptom to a specific value and code path. Debug Mode and DevTools help you do that much faster than adding more console messages at random.

Originally published on 2019-03-09. English edition revised on October 3, 2026. Updated Blackboxing terminology to Ignore List and added Lightning Web Security considerations. Read the Chinese original.

Apex Tests That Do More Than Meet Code Coverage Requirements

Sun, 22 May 2016 15:25:29 +0800

Apex tests are part of deploying to Salesforce, but their value should extend well beyond the coverage requirement. A test that executes a line without checking its result can satisfy a metric while missing the very defect it was supposed to catch.

My original article organized useful tests around four goals, five practices, and six challenges. That structure still provides a practical checklist.

Four goals

1. Test positive behavior

Start with the intended business outcome. Create valid inputs, execute the operation, and check that it completes as expected. If a method has branches, cover the meaningful successful paths rather than only the easiest route through it.

2. Verify the end state

Assertions are the part that makes a test useful. Check the returned value, the saved record, or the observable side effect that the requirement calls for.

System.assertEquals(
    'Closed',
    actualStatus,
    'The operation should close the request'
);

The assertion message should explain the expected behavior. A failure is much easier to investigate when the test tells you which promise was broken.

3. Test negative behavior

Try inputs that should be rejected or handled differently. A blank required value, an unsupported transition, or an unavailable related record can be just as important as the happy path.

Check the intended response: an error, a validation message, or an unchanged record. Merely catching an exception without asserting anything can hide a defect.

4. Test bulk behavior

Code that works for one record may fail when a batch arrives through an integration or data import. Test a representative collection—200 records is a useful trigger-batch scenario—and assert that all relevant records were processed correctly.

That helps expose SOQL or DML inside loops. It is not a guarantee that every governor-limit scenario is covered: multiple objects, repeated updates, trigger recursion, and asynchronous callers can produce different behavior.

Five practices

1. Own your test data

Avoid relying on existing organization data through SeeAllData=true. Such dependencies can make the same test pass in one org and fail in another.

Create the data the test needs. Use @testSetup for shared setup where appropriate, or Test.loadData with a CSV static resource when fixtures are easier to express that way.

2. Centralize repeated setup

A test-data factory keeps common record creation in one place. If a new required field is introduced, a factory is easier to update than dozens of nearly identical setup blocks.

Keep scenario-specific choices visible in the test. A factory should reduce duplication without making the reader guess which conditions are being tested.

3. Use descriptive names

A class name such as MyServiceTest makes the relationship to the production class clear. Method names should describe behavior: rejectsMissingAccount is more informative than testMethod2.

4. Separate setup, execution, and verification

Create fixtures before Test.startTest(), execute the operation between startTest() and stopTest(), then assert the result afterward.

// Arrange: create the records and inputs for this scenario.
Test.startTest();
// Act: invoke the operation under test.
Test.stopTest();
// Assert: verify the resulting records or return value.

This makes the test boundary easy to understand and is important when testing supported asynchronous work.

5. Give each test a clear purpose

One method should not try to exercise the entire application. Separate scenarios so that a failing test points to a specific behavior. Shared setup is useful; shared ambiguity is not.

Six common challenges

Scenario	Useful approach
Visualforce controllers	Set a page with `Test.setCurrentPage()`, provide URL parameters, instantiate the controller, and assert navigation or state.
SOSL	Use `Test.setFixedSearchResults()` to control the records returned by the test.
Asynchronous Apex	Use the supported `startTest()` / `stopTest()` pattern and assert the resulting work. Do not assume an arbitrary chain of nested jobs all runs in the test.
HTTP callouts	Implement `HttpCalloutMock` and register it with `Test.setMock()`; test success and failure responses.
User access	Use `System.runAs()` for user and sharing scenarios, then explicitly test the security behavior implemented by your production code.
Private members	Use `@TestVisible` when necessary, while favoring observable public behavior when that is sufficient.

User context, record sharing, object access, and field access are different concerns. runAs() alone should not be treated as proof that CRUD and field permissions are enforced. Queries and DML need the appropriate security behavior, such as user-mode operations, when the requirement calls for it. Salesforce explains these distinctions in Secure Apex Classes.

A test should protect a promise

Coverage answers whether code was executed. Useful tests answer whether the code kept its promise, rejected the wrong inputs, and behaved correctly under realistic workloads. Those are the tests that make the next change safer.

For the platform-specific tools mentioned here, see the Apex Developer Guide.

Originally published on 2016-05-22. English edition revised on October 3, 2026. Updated terminology and clarified bulk testing, asynchronous execution, and permission-testing boundaries. Read the Chinese original.

Why Images Fail in Salesforce Emails—and How to Fix Them

Mon, 16 May 2016 09:25:29 +0800

An email template can look correct inside Salesforce and still show a broken image to its recipient. The usual reason is that the image URL works for a signed-in user but is not a usable image source for an external email client.

My original article explained this through Salesforce Classic templates and Documents. The principle remains useful: an externally hosted image needs a stable, accessible URL, and the actual delivered message needs to be tested.

Choose the method for the template you use

Lightning templates and enhanced letterheads have image capabilities that differ from older Classic HTML and Visualforce templates. Start with the image tools in the editor for the template type you are using.

Salesforce documents that saving a template can convert Salesforce content-document links into content-asset links. That is one reason manually copying a file preview URL is not equivalent to inserting an image through the supported editor. See Using Images in Emails, Email Templates, and Enhanced Letterheads.

For a custom HTML template, you can reference a suitable hosted image explicitly:

<img
  src="https://cdn.example.com/email/logo.png"
  alt="Company logo"
  width="240"
  style="display:block; max-width:100%; height:auto;"
>

Replace the example URL with your actual image. The src should identify the image response, not a page that previews a file.

Check access without your Salesforce session

Open the final image URL in a browser session that is not signed in to your org. If it opens a login page or a file preview, it is not ready for the external recipient.

This check is necessary, but it is not the entire email test. A recipient’s client may block remote images until the user enables them, and different clients render HTML differently. Provide useful alternative text and keep the message understandable when images are hidden.

Only use public hosting for content intended to be publicly retrievable, such as a marketing logo. A picture’s presence in an internal Salesforce record does not establish that it is suitable for public distribution.

The historical Documents approach

In the Classic workflow from the original article, the steps were:

Upload the image to a Documents folder.
Enable Externally Available Image for the document.
Obtain its image URL.
Reference that URL in the HTML or Visualforce template.
Verify it without an authenticated org session.

The resulting URL used a form like this:

https://<salesforce-host>/servlet/servlet.ImageServer?id=<document-id>&oid=<org-id>

This is background for an existing Classic implementation, not a universal URL recipe for Lightning Files. Do not manufacture a download URL by replacing parts of a file preview link. Follow the supported image method for the particular storage and template type.

Salesforce’s Classic template image instructions describe that workflow and external image URLs.

Test a delivered message

After saving the template, send it to an external mailbox and inspect the result. A useful test covers:

The image loads when remote images are allowed.
The content remains readable when they are blocked.
The image has an appropriate size on desktop and mobile.
The URL does not depend on your login or an unexpectedly short expiration.
The received HTML references the intended image.

If it fails, inspect the image URL and response first. Authentication redirects, an expired link, or a file-preview response are different problems from an email client hiding remote content.

The practical lesson is to validate the recipient’s experience, not just the template editor. A stable source and a real delivery test will find problems that an internal preview cannot.

Originally published on 2016-05-16. English edition revised on October 3, 2026. Updated guidance for Lightning templates and retained the Documents approach as historical Classic context. Read the Chinese original.

Salesforce 15- vs. 18-Character IDs: Avoiding Integration Bugs

Sat, 16 Apr 2016 09:25:29 +0800

A Salesforce record ID identifies one record. It is used in queries, exports, integrations, and URLs, so a small misunderstanding about its format can turn into a difficult data-matching bug.

Salesforce IDs have two familiar forms: 15 characters and 18 characters. Both refer to the same underlying record, but they behave differently when a system compares text without respecting case.

Why there are two formats

A 15-character ID is case-sensitive. The letters in these two example strings differ:

00Qi000000g4YE2
00Qi000000g4ye2

A case-insensitive comparison treats them as the same text even though the original 15-character values are different. That is a problem when joining Salesforce exports in spreadsheets or another system with case-insensitive keys.

The 18-character form adds three characters encoding the capitalization of the first 15. That makes it suitable for matching in case-insensitive systems. Salesforce calls this form case-safe. Salesforce’s conversion guidance describes both formats.

Case-safe does not mean “change the capitalization whenever you like.” Preserve IDs exactly as received, and do not lowercase them before generating the suffix. If the original capitalization has already been lost, the conversion cannot infer it from a 15-character string alone.

What the prefix tells you

The first three characters are the object’s key prefix. For example, a familiar prefix can help identify the object type of a record you are investigating.

Avoid building business logic around assumptions about the rest of the ID, or hard-coding custom-object prefixes across organizations. In Apex, use the ID’s object type when you need it:

Id recordId = '001000000000001';
Schema.SObjectType objectType = recordId.getSObjectType();

This is a format example, not the ID of a record to query in your org.

How the extra three characters are calculated

Split the 15-character ID into three groups of five. Within each group, mark each uppercase letter with a bit. The first character corresponds to bit zero, the second to bit one, and so on. Lowercase letters and digits contribute zero.

That produces a number from 0 to 31. Use it as an index into:

ABCDEFGHIJKLMNOPQRSTUVWXYZ012345

Append the three resulting characters, one for each group, to the original ID. This equivalent bit-based explanation avoids having to reverse the groups manually.

Conversion options

Formula field

For an export or report, a Text formula field can expose the case-safe ID:

CASESAFEID(Id)

Salesforce documents the function in CASESAFEID.

Apex

Use the platform’s Id type instead of reimplementing the suffix calculation:

Id recordId = Id.valueOf(inputId);
String outputId = String.valueOf(recordId);

Handle invalid input at the integration boundary. A value having the right length does not establish that the record exists or that the current user may access it.

JavaScript

If you need the calculation outside Salesforce, this implementation converts a correctly capitalized, 15-character alphanumeric input:

function to18CharacterId(id) {
  if (typeof id !== "string" || !/^[a-zA-Z0-9]{15}$/.test(id)) {
    throw new TypeError("Expected a 15-character Salesforce ID");
  }

  const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZ012345";
  let suffix = "";

  for (let group = 0; group < 3; group++) {
    let mask = 0;
    for (let position = 0; position < 5; position++) {
      const character = id[group * 5 + position];
      if (character >= "A" && character <= "Z") {
        mask |= 1 << position;
      }
    }
    suffix += alphabet[mask];
  }

  return id + suffix;
}

The format check deliberately accepts only 15 characters. It does not validate an existing 18-character suffix or look up a Salesforce record.

My recommendation

Use 18-character IDs at integration and export boundaries, preserve capitalization, and normalize the format before joining datasets. Check format, record existence, and authorization separately. Removing this ambiguity early is easier than diagnosing mismatched data later.

Originally published on 2016-04-16. English edition revised on October 3, 2026. Updated the conversion example and removed legacy tool recommendations and assumptions about internal ID structure. Read the Chinese original.