How to Use Cursor for Salesforce Development

This guide explains how to use Cursor as an AI development assistant for Salesforce projects, from understanding requirements and planning changes to writing code, troubleshooting issues, and testing implementations.

The goal is to make development more structured and efficient while keeping developers responsible for reviewing changes and verifying results.

1. Set up Cursor to work with Salesforce

• Open your Salesforce project _or local source-code folder in Cursor.

• Connect to your Salesforce org through the Salesforce CLI. The CLI is the connection layer for retrieving and working with available Salesforce metadata, configuration, and data.

• If you have multiple orgs connected, explicitly tell Cursor which org or sandbox you want to work with.

• Provide the relevant files, requirements, documentation, existing configurations, and examples before asking it to make changes.

2. Choose the right AI model

It is recommended to choose models based on task complexity and available usage limits.

• Routine tasks: Use a lower-cost or default model for straightforward bug fixes and smaller changes.

• Complex tasks: Switch to a stronger technical model, such as Claude, when the default model struggles with complicated logic or repeatedly produces incorrect results.

• Manage usage: Monitor model limits and avoid spending large amounts of context on information that is not relevant to the task.

An example of a model failing to solve a bug then succeeding after switching models and providing the right context.

3. Give Cursor clear context and instructions

Before asking Cursor to write or change code, explain:

• What does the business need to achieve.

• What currently exists in the Salesforce org.

• What is not working or needs to change.

• Which components, configurations, or records are relevant.

• What the expected result should be.

For example, instead of saying, “Fix Email-to-Case,” explains the existing email-to-Case setup, the case assignment problem, the relevant record types or permissions, and the expected behavior.

Important: Keep an eye on the agent while it works. Stop it if it starts investigating the wrong area or making unnecessary changes, then correct the instructions.

4. Use Spec Kit for new features

One of the most important topics in the session was Spec Kit and Spec-driven development.

Rather than asking Cursor to jump straight into coding, use a structured workflow:

Step 1: Write specifications

Describe the business requirements, user journey, expected behavior, and acceptance criteria. Keep this focused on what the user needs, not how the code should be built.

Step 2: Create a plan

Ask Cursor to research the existing code, org configuration, integrations, and dependencies. Have it identified the technical approach and unresolved questions.

Step 3: Generate technical tasks

Break the approved plan into manageable implementation tasks, such as Apex classes, triggers, Lightning Web Components (LWCs), metadata, permissions, and test classes where needed.

Step 4: Implement and validate

Let Cursor implement the tasks in stages, review the changes, run tests, and validate the behavior in a sandbox.

Note: OpenSpec is an alternative framework, but Spec has become more useful in experience.

Example from the meeting

For a Salesforce Agentforce customer-support agent, the specification included a customer verification journey:

• Ask for an order number and contact information.

• Send an OTP to the supplied email address or phone number.

• Verify the customer's identity before revealing order information.

• Define acceptance criteria for each behavior.

Only after defining these requirements should the team plan the technical implementation.

5. Understand skills versus commands

The meeting distinguished between two concepts:

• Commands: Actions you invoke through a terminal or supported AI workflow to perform a specific operation.

• Skills: Reusable instructions or capabilities that can be installed locally in a project and used by Cursor or Claude when relevant.

Spec Kit provides its own commands and skills. It is described using a command to turn an initial prompt and supporting documentation into specifications, then using subsequent steps to create the plan and tasks.

The transcript does not provide a complete installation guide or exact setup commands, so those details would need to be checked separately.

6. Keep specifications and context updated

For work that continues over weeks or months, do not rely on old chat history alone.

• Keep specifications and technical documentation in the project.

• Refresh the AI's context when starting a new chat.

• Tell which specification folders or feature documents to read.

• Work on one problem at a time when practical.

• If requirements change, update the specifications first and then update the code.

A Spec Kit context-update workflow is to help a new chat recover the project's business requirements and technical context.

For existing implementations that were not developed using specs, it recommended documenting important Apex classes and methods and maintaining a reusable technical guide. It is cautioned that technical documentation and user stories serve different purposes.

7. Use Cursor for testing, not just coding

The session included a practical AI-assisted testing workflow.

1. Give Cursor the Jira ticket, acceptance criteria, and relevant comments.

2. Provide test scenarios and test data, potentially in an Excel sheet.

3. Identify the correct browser tab, URL, sandbox, and any test-specific verification codes.

4. Ask Cursor to execute the scenarios and report on which tests passed or failed.

5. Keep the initial testing run separately from fixing. It is specifically instructed by the agent to report failures without automatically changing the implementation.

6. Review the results, ask Cursor to investigate the failures, implement approved fixes, and run the tests again.

Note: Testing individual topics or user journeys in Agentforce is a structured set of scenarios that can help make testing repeatable, especially as new releases are deployed.

8. Use AI across the Salesforce delivery lifecycle

Cursor can contribute beyond writing Apex code. Based on the session, the team can use AI for:

Development activity

How to use Cursor

Requirements: Turn business needs into specifications and acceptance criteria.

Planning: Research existing components, configuration, and dependencies.

Development: Generate or modify Apex, LWCs, tests, and other project files.

Troubleshooting: Investigate errors using relevant org configuration and code context.

Documentation: Explain classes and methods and maintain reusable technical guides.

QA and testing: Execute browser-based scenarios and report pass/fail results.

Maintenance: Refresh context from specs before modifying older features.

There is an emerging concept called “harnesses”.  

Note: Harnesses are raised as a possible future learning topic.

9. Recommended workflow for the Unboxx Salesforce team

For a new Salesforce feature, I would translate the session into this repeatable process:

1. Understand the Jira ticket

Clarify the business problem and expected outcomes.

2. Gather context

Open the project, identify the target sandbox, and provide relevant code, metadata, and documentation.

3. Create or update specs

Define user journeys, acceptance criteria, and open questions.

4. Plan the implementation

Have Cursor researched the existing solution and proposed a technical approach.

5. Implement in stages

Generate code and configuration, reviewing each meaningful change.

6. Test independently

Run relevant automated tests and acceptance scenarios; record failures.

7. Fix and retest

Address confirmed issues, rerun tests, and validate the sandbox behavior.

8. Document the outcome

Update specs, technical documentation, and the Jira ticket.

10. Example prompt to use in Cursor

I need to implement the following Salesforce feature: [describe the business requirement].

Before making any changes:

1. Review the existing project code, relevant metadata, and available documentation.

2. Confirm which Salesforce org or sandbox this work targets.

3. Define the user journey and acceptance criteria.

4. Identify missing information and ask questions instead of making assumptions.

5. Propose a technical implementation plan, including relevant Apex, triggers, LWCs, metadata, permissions, integrations, and tests where applicable.

Wait for approval of the plan before implementing it.

After approval, implement the work in manageable stages. Follow existing project conventions, explain significant changes, and identify any risks or dependencies. Do not modify unrelated components.

When implementation is complete, run the relevant tests and report what passed, what failed, and what still needs manual validation. Do not claim success for tests that were not actually executed.

The biggest lesson from the meeting is that using Cursor effectively is not just about generating code faster. It is about giving the AI the right business context, selecting an appropriate model, using structured specifications, supervising implementation, and validating the result.

‍