The Assistant answers the question you ask. A few extra words tell it which part of your org to look at, how much ground to cover, and what shape you want the answer in. That is usually the difference between a good answer and exactly the answer you had in mind.
Everything below is a small addition to a prompt you would write anyway. None of it is technical, and you can combine them freely.
The moves
Ask for things by name
The most useful three words you can add. Asking for names turns general guidance into a specific list you can act on, and it gives you something you can look up in your org straight away.
Which automations fire when an Opportunity moves to Closed Won? List them by name.
The words doing the work: "list them by name".
Use it any time you plan to do something with the answer: hand it to a developer, paste it into a ticket, or check it against your org. It works for flows, validation rules, Apex classes, profiles, permission sets, and fields.
Point it at one object or one process
Naming the object or the business process you care about is the single most effective thing you can do for answer quality. The Assistant scopes its research to what you mention, so telling it where to look gets you depth instead of breadth.
Walk me through everything that governs the Opportunity object.
Walk me through our lead-to-opportunity conversion process end to end.
The words doing the work: naming the process, "lead-to-opportunity conversion".
If your question naturally spans several objects, name them all. When you name the full path, the Assistant maps the real relationships between them. When you leave objects out, it works with what it has.
Say how much you want covered
If you want the whole set rather than a representative sample, say so.
Review the profiles in this org and cover every profile rather than a sample.
The words doing the work: "cover every profile rather than a sample".
This is worth adding whenever you are doing an inventory, an audit, or a migration, and the completeness of the list is the point of the exercise.
Name the kinds of components you care about
Automation lives in several places in Salesforce, and older orgs usually have a mix. Naming the types you want brings back the full picture.
What automation runs on Case? Include workflow rules, Process Builders, flows and Apex triggers.
The words doing the work: naming the types, "workflow rules, Process Builders, flows and Apex triggers".
Say how deep to go
This one changes the answer more than people expect, and it is worth being explicit about.
For a walkthrough, a handover, or anything you want to understand quickly:
Walk me through our quote approval process. Keep it at the process level.
The words doing the work: "Keep it at the process level".
For a build spec, where the exact API names matter because someone is going to work from them:
Explain the validation rules on Quote. Read the full stored definition for each one rather than the summary, and give me the exact formula and error message.
Both are correct. Pick by what you are going to do with the answer. The first is faster and easier to read. The second is what you want when the names are going into a spec.
Say what you want the output to be
Ask for the format up front and you get it first time.
Create a CSV of every custom field on Account with its type, description and where it is used.
The words doing the work: "Create a CSV". Say "create", not "convert".
Say "create" rather than "convert". Asking for a new document in a specific format is clearer than asking for a change to something you already have.
Give it your source material
If your question is about a Salesforce release, a scan from another tool, a user story, or a security review, give the Assistant the material itself. Paste it in, or upload it as an attachment, whichever suits the document. The Assistant then compares that material against your actual org, which is far more useful than a general answer.
Here are the release notes for the upcoming Salesforce release. Tell me which components in this org are affected, by name.
[paste the release notes]
This is the most common thing experienced users do, and it turns a broad question into a specific one about your configuration. For longer documents, uploading is usually easier than pasting: see Using Attachments in Swantide AI for the supported formats.
Ask it to rank
Ranking gives you a place to start, which is usually what you actually want from an audit.
For the Sales User profile, list the system permissions that carry real risk and explain the risk of each, most significant first.
The words doing the work: "most significant first".
Ask for the query alongside the answer
When a number is going to drive a decision, ask for the query that confirms it. You get the answer and the means to verify it in one turn.
How many active users are on admin-equivalent profiles? Flag any number that should be confirmed with a direct query, and give me the query.
The words doing the work: "Flag any number that should be confirmed with a direct query, and give me the query".
It is particularly good for anything involving user counts, licences or record volumes, where the answer depends on your data as well as your configuration.
Say who the answer is for
The Assistant will pitch the answer at whoever you name.
Write a one page summary of our opportunity approval process for our EMEA sales team, who do not use Salesforce day to day.
The words doing the work: "for our EMEA sales team, who do not use Salesforce day to day".
Worth knowing: naming a non technical audience gets you clean, readable prose and fewer technical details. If you want breadth and depth, ask for the depth you want instead.
Include the things that are switched off
Inactive and draft components are often exactly what you are looking for during a cleanup.
List the validation rules on Account, including inactive and draft ones.
The words doing the work: "including inactive and draft ones".
Ask for labels when the reader is an end user
Write a guide to the new opportunity process for our sales reps. Use the field labels they see on screen rather than API names.
The words doing the work: "Use the field labels they see on screen rather than API names".
Paste the exact error message
When you are chasing a problem, copy the error text in full rather than describing it. The error names the component, and that is the fastest route to the thing that produced it.
Users are getting "Close Date is required when Stage is Closed Won" on the Opportunity object, but the Close Date is filled in. Find what is producing that error and explain the condition that triggers it.
The words doing the work: the quoted error string.
Tell it what you are trying to achieve
Adding your goal in a sentence lets the Assistant choose the right depth and shape on its own.
Audit the Opportunity record types in this org. The goal is to work out whether they are still meaningfully different from each other, so we can consolidate them.
The words doing the work: "The goal is to work out whether... so we can consolidate them".
Putting it together
These combine naturally. A strong prompt usually says what to look at, what to call things, how much to cover, and how deep to go.
A quick question:
What fires when an Opportunity closes?
The same question, shaped:
Walk me through everything that fires when an Opportunity moves to Closed Won. Cover workflow rules, Process Builders, flows, validation rules and Apex triggers, name each one, and keep it at the process level.
The words | What they get you |
"when an Opportunity moves to Closed Won" | Scopes it to one process, which is what buys depth |
"Cover workflow rules, Process Builders, flows, validation rules and Apex triggers" | The full picture, not just one kind of automation |
"name each one" | A checkable list instead of general advice |
"keep it at the process level" | A walkthrough you can follow, not a field-by-field dump |
An audit you can act on:
Review the Sales User profile and list the system permissions that carry real risk. Name each one, explain the concrete risk, and put the most significant first. Flag any number that should be confirmed with a direct query, and give me the query.
The words | What they get you |
"the Sales User profile" | Scopes it to one profile |
"Name each one" | A list you can check against your org |
"most significant first" | A place to start, rather than a flat list |
"Flag any number... give me the query" | The answer, plus the means to confirm it |
A migration inventory:
Create a CSV of every profile and permission set in this org. Cover every one rather than a sample, list them by name, and show which risky permissions each one grants.
The words | What they get you |
"Create a CSV" | The format, asked for up front |
"Cover every one rather than a sample" | The whole set, which is the point of an inventory |
"list them by name" | Rows you can act on |
Working across a conversation
The moves above shape a single prompt. These two shape the conversation around it, and they matter just as much.
Ask follow-up questions to go deeper
A conversation keeps its own history, so the Assistant remembers what you have already established. That makes follow-ups short and cheap, and several focused turns usually get you further than one very large opening prompt.
Start broad, then drill in:
What handles our lead conversion?
Then, in the same conversation:
Tell me more about the entry criteria on that flow, and what happens when it does not match.
This is also the way in when you do not know what something is called yet. Ask by behaviour first, then ask again using the name you get back:
Which flow makes sure opportunities get created when a lead reaches a certain status?
Walk me through Auto_Convert_Lead_from_Conditions_with_New_Opportunity, and tell me which validation rules could block it.
The move: find it by what it does, then go deep using its name.
Start a new chat for a new topic
The same history that makes follow-ups work is worth resetting when you move on. A conversation that stays on one subject gives sharper, faster answers, because everything in it is relevant.
Start a new chat when you switch topic or component, and when you want a new deliverable such as a second test script or a different solution design. If answers start to drift toward something you asked about earlier, that is the moment to open a fresh one.
Stay in the same conversation while you are iterating on one thing: refining a design, adding cases to a script, or working through the same component from different angles.
A good rule: one conversation per task. If you cannot describe what a conversation is for in a single sentence, it is doing too much, and splitting it will get you better answers.
Adapting these to your own work
Three habits carry most of the value:
Name the thing. The object, the process, the profile, the package. Whatever the question is really about, put it in the prompt.
Say what you will do with the answer. A walkthrough, a build spec, a handover doc and a CSV are four different answers to the same question.
Ask for names. Almost any answer becomes more useful when the components in it are named.
Everything else is refinement. If a first answer is close but not quite right, say what you want changed and ask again. The Assistant keeps the context of your conversation, so follow-up turns can be short.
When the Data Dictionary is the better tool
For a complete inventory you want to filter, sort and export, go to the Data Dictionary. It is built for exactly that: browse every component in your org, filter by type or object, and export to CSV. The References view shows you what a component points at and what points back at it, in both directions.
Broad questions are fine to ask the Assistant. For something big and analytical, ask for it as a Deep Dive and you get a document you can share rather than a long answer in the chat.
A good rule: use the Assistant when you want something explained, designed or analysed, and the Data Dictionary when you want the full list in a spreadsheet. Many of the best workflows use both, starting with a Data Dictionary export and then asking the Assistant to analyse it.
What you want | Where to go |
Understand how a flow, trigger or process works | Assistant |
Work out why something is behaving the way it is | Assistant |
Know what would break if you changed something | Assistant |
Design or build something | Assistant |
A broad piece of analysis written up as a document, such as an org health score or a technical debt register | Ask for it as a Deep Dive |
A full list you want to filter, sort or export as a spreadsheet | Data Dictionary |
Everything that references one component | References view |
The split is about what you want out, not about what the Assistant can handle. Ask it for analysis and judgement. Use the catalog when what you actually want is a filterable, exportable list, and the References view when you want the dependency picture for one component.
One tip for searching the catalog: search the label you see on screen, such as Digital Signature, rather than the API name form, such as DigitalSignature. Labels return the fuller set of matches.