Prompting Patterns for Salesforce Development

The Meta-Skills This Tutorial Teaches

Series: Build a Salesforce Guide App with AI

Type: Standalone reference — no prerequisites required


About This Page

This page distils the prompting lessons from building the Guide Hub app into reusable patterns you can apply to any Salesforce project. You don’t need to have completed the tutorial to find this useful — these patterns apply any time you’re using Claude to help with Salesforce development.

Share this page independently if it’s useful. It stands alone.


The Honest Picture First

Before the patterns: a realistic assessment of what AI is good at in Salesforce development, and where it falls short.

Where Claude genuinely helps:

  • Generating Apex boilerplate from a plain English description of behaviour
  • Writing LWC components from a list of requirements
  • Diagnosing deployment errors from terminal output
  • Explaining architectural tradeoffs before you commit to one
  • Adapting code quickly when requirements change
  • Writing test classes with high coverage

Where Claude is unreliable:

  • Very recent Salesforce features (anything released in the last 6 months)
  • Complex sharing models and governor limit edge cases
  • Org-specific configuration details it can’t know (field names, record type IDs, custom flows)
  • Subtle business logic that requires understanding your specific processes

Where Claude will confidently produce something wrong:

  • SOQL syntax edge cases (see Pattern 3)
  • Apex reserved words used as variable names (see Pattern 7)
  • Platform behaviour that differs between Lightning contexts (the Screen Action lifecycle issue is a good example)

Knowing these boundaries lets you use Claude where it’s fast and reliable, and apply your own judgment where it isn’t.


The Eight Patterns

Pattern 1 — Give context before asking for code

The single most impactful habit. Before every new phase, paste a summary of what’s already been built. Claude has no memory between conversations and limited memory within a long one.

A context-setting prompt like this produces dramatically better code than jumping straight to “write me an Apex class”:

I’m building a Salesforce internal guide application. Here’s the context:

Custom objects already created: Guide__c (fields: Name, Summary__c, Body__c rich text, Status__c picklist Draft/Pending Approval/Published, Audience__c picklist User/Admin, Is_Active__c checkbox), Guide_Topic__c, Guide_Topic_Assignment__c (junction, child relationship Topic_Assignments__r), Guide_Video__c (child relationship Guide_Videos__r).

Already deployed: GuideService.cls with methods getGuides, getGuideDetail, getTopics, saveGuide, saveVideos, submitForApproval.

I now need to build [next thing]. Key constraints: [list them]. Please confirm your understanding before writing any code.

The more specific your context, the less Claude has to guess, and the fewer errors appear in what it produces.


Pattern 2 — Ask for explanation before implementation

When facing an architectural decision, ask Claude to explain the options and tradeoffs before choosing one. This is faster than asking for code, discovering the approach was wrong for your situation, and having to refactor.

I need to [achieve X]. What are my options? For each option, explain the tradeoffs and which you’d recommend for my situation. Don’t write any code yet.

This is especially valuable for decisions that are hard to reverse — OWD settings, Master-Detail vs Lookup relationships, whether to use a junction object or a multi-select picklist.


Pattern 3 — Describe errors precisely

The quality of the fix depends entirely on the quality of the error description. Paste the exact error table from the terminal — don’t paraphrase it. Include the line numbers. Include the surrounding code.

I got this deployment error. Here’s the exact output: [paste terminal output]

Here’s the code around line [N]: [paste the relevant section]

What’s the root cause and how do I fix it?

The SOQL bind variable error is worth knowing about specifically. If you see Unexpected token ':' on a line with a SOQL filter, the cause is almost always a bind variable on the left side of a comparison:

// Invalid — bind variable on the left
AND (Category__c = :cat OR :cat = 'All')

// Valid — bind variable on the right only
// Fix: use two separate queries with if/else

If Claude produces the invalid pattern, say: “The SOQL bind variable :cat = 'All' is invalid — Salesforce requires bind variables on the right side of a comparison. Please rewrite this using two separate queries with an if/else.”


Pattern 4 — Recognise when Claude is guessing

Claude will sometimes produce plausible-looking but incorrect Salesforce-specific code. Signs it might be guessing:

  • The code uses an API that sounds right but isn’t the standard approach
  • The error it predicted doesn’t match what actually happened
  • It produces a workaround when a simpler built-in approach exists
  • The explanation is vague where you’d expect a specific answer

When something doesn’t work after a fix Claude suggested, ask:

Is this the standard Salesforce approach to this problem, or is it a workaround? What would a senior Salesforce developer do here? Are there any known limitations with this approach I should be aware of?


Pattern 5 — Iterate in small pieces

Don’t ask for an entire component in one prompt. Ask for one method or one section at a time. Test it before continuing. Small iterations mean smaller errors and faster debugging.

In practice this means:

  • Request Apex methods in groups of 3–4, not the entire class at once
  • Deploy and test after each group before continuing
  • For LWC, build and test one component fully before moving to the next

The temptation is to get everything at once to save time. The reality is that debugging a 300-line class with five errors takes longer than catching one error per deploy across five deploys.


Pattern 6 — The file encoding problem on Windows

When copy-pasting code from a browser into VS Code on Windows, angle brackets in generic types get converted to HTML entities:

List<Guide__c>  becomes  List&lt;Guide__c&gt;

This causes deployment failures that look like syntax errors but aren’t obvious to diagnose. The fix is to always ask Claude to generate a PowerShell script that writes the files for you:

Generate a PowerShell script that writes [list of files] to [path]. Base64-encode all file content so no special characters appear in the script itself. Use [System.IO.File]::WriteAllBytes() to write the files — not Set-Content, which adds a BOM. Create component directories with New-Item -ItemType Directory -Force before writing. Print a success message when done.

This completely bypasses the browser copy-paste pipeline and eliminates the encoding problem.


Pattern 7 — Reserved words will catch you out

Apex shares keyword space with SOQL. These variable names cause compile errors:

desc, asc, from, select, where, limit, type, object, group, order

Claude occasionally uses them anyway — desc for a description field is a common one. When you see a deployment error on what looks like a valid variable name, check whether it’s in this list.

When Claude uses a reserved word, tell it immediately:

The variable name desc is a reserved word in Apex (used in ORDER BY … DESC). Please rename it to videoDesc throughout the method.


Pattern 8 — Know when to stop using AI

AI is fast at generating boilerplate, slow at understanding subtle business logic, and unreliable on very new Salesforce features. There are three situations where you should set Claude aside and use other resources:

Features released recently — Anything in the last two API versions. Claude’s training has a cutoff and may not know current platform behaviour. Check the Salesforce Release Notes directly.

Governor limits and performance — Claude can write SOQL that works in tests but hits limits at scale. If you’re querying large objects or building something that will run in batch, verify the approach against Salesforce’s own documentation.

Your specific org configuration — Claude doesn’t know your record types, your existing flows, your profile setup, or any customisation that existed before this project. Any prompt that relies on org-specific context needs that context explicitly provided — Claude can’t infer it.

The best Salesforce developers using AI aren’t the ones who use it for everything. They’re the ones who know which parts of their work benefit from AI assistance and which require their own expertise.


The Prompting Toolkit at a Glance

Situation What to do
Starting a new phase Paste a full context-setting prompt before the first code request
Facing an architecture decision Ask for options and tradeoffs, explicitly say “don’t write code yet”
Got a deployment error Paste the exact terminal output and surrounding code
Something works in tests but not in the org Ask if it’s the standard approach or a workaround
Building a large component Break into sections, deploy and test each before continuing
On Windows, copying code Ask Claude to generate a base64 PowerShell script instead
Seeing a cryptic variable error Check if the variable name is an Apex/SOQL reserved word
Working with recent features or complex limits Use official Salesforce documentation directly

← Back to series: Build a Salesforce Guide App with AI