Prompting best practices

Best practices for writing prompts for Assist.

Consider the following best practices for writing effective Assist prompts.

Reference content from your organization

You can @ mention resources, code, and components in your prompt.

Update the data source for @supportTable to utilize the @Customer Support Tickets Database resource.

Give as much context as possible

Be as specific as you can about the type of app you want to create or the edits you want to make. The more detail you include about what you're trying to build, the better Assist can do on the first pass.

Build me a dashboard of movies released in the 1980s with search and filters by genre. I want to be able to add movies and provide my own rating.

Iterate and refine

If the first output isn't exactly what you expected, add more info or adjust your prompt. You can also manually edit your app and come back to Assist to continue where you left off. Working with Assist is designed to be an iterative process.

I made some changes manually. Can you verify that everything is still working?

Switch between Ask and Build mode

Use Ask mode when you want Assist to answer questions, explain how a part of your app works, or recommend an approach — without making any changes. Switch to Build mode when you're ready for Assist to modify the app. You can toggle between modes using the dropdown in the Assist panel.

Ask mode is especially useful before starting a large build: ask Assist to describe the current app structure or evaluate an approach, then switch to Build mode once you're aligned.

Describe the current app structure without making any changes.

Tell me what data is available in the @Salesforce resource

Be specific about resource nuances

Databases (Retool Database, Postgres, MySQL, etc.) can be queried or modified using similar patterns, so Assist can reliably generate SQL queries. On the other hand, API request structures and specifications can vary widely between endpoints. Giving details about how your system is configured, or pasting API documentation into your prompt helps Assist understand the structure.

When configuring your resource, be as detailed as possible in the Description setting on the Resource configuration page. If you're using a REST API specification, consider connecting an OpenAPI or Swagger specification. This information is passed to Assist, and it provides valuable context on when or how the resource should be used.

Use the @ptoRequests resource to manage requests using the /approve and /deny endpoints.

Plan before you build

For complex apps, ask Assist to create a wireframe or technical spec before writing any code. Reviewing the plan gives you a chance to correct the approach before Assist starts making changes.

Create a wireframe for this app before building it.

Write a technical spec for this feature first, then wait for my approval before making any changes.

Scope requests to one feature at a time

Assist works through tasks in steps, pausing to check in as it goes. Breaking a large request into smaller, focused prompts, such as one feature or section at a time, gives you more control and leads to more complete results than asking Assist to build an entire app in a single message.

I want you to create an app that helps me manage employee PTO. First, use the @ptoRequests resource to help me view outstanding and historical requests.

Now, add functionality that enables me to approve and deny new requests.

Ask Assist to wire up event handlers

When building or editing features that create, update, or delete data, explicitly ask Assist to wire up all event handlers. This ensures mutations are followed by the right data refreshes and UI updates.

Wire up all event handlers when you're done.

Make sure the table refreshes after the form submits.