The habits that make the biggest difference, roughly in order of how much they change the result.
Start in the AI Assistant, not the task form
The single most useful one. Instead of opening a task and writing a spec from scratch, have the conversation first: describe the problem to the Assistant, let it look at your org, and work out what needs to change. Then ask it to create the task.
The task description it writes will be shorter and more specific than one written by hand, because it names the components it just looked at. By the time the task exists, the thinking has already happened.
When you start that conversation, describe what is wrong rather than what to build, and list the components involved with their API names and types.
Tasks created by the Assign Action Plan quick action are not picking up the custom end date the user sets in the UI, even after I added a field specifically to trigger the automation. Can you work out why?
1. Person_Account_Assign_Action_Plan (Flow)
2. Task_Record_Triggered_Update_Assigned_To_As_Per_Action_Plan (Flow)
3. Account.Assign_Action_Plan (QuickAction)
4. Person_Account_Record_Page (FlexiPage)
Two things are doing the work there: a description of the symptom, so it can diagnose rather than just build what you asked for, and an explicit list so it knows where to look.
Be specific about the outcome
Think of AI Admin as a capable admin you are delegating to. The more completely you describe what you want, the more precisely it builds it. A vague ask still produces something. A specific ask produces the thing you actually wanted.
Instead of | Say |
"Add a region field to Account" | "Add a picklist field Sales Region to Account with values West, East, Central, South. Give read and edit access to the Sales and Sales Manager profiles." |
"Update the onboarding flow" | "In the record-triggered flow Onboarding, add a decision: when Type is Renewal, also create a Task called Renewal check-in for the owner. Keep the existing logic and the fault path." |
"Make a validation rule for opportunities" | "On Opportunity, add a validation rule that blocks saving as Closed Won when Amount is blank or zero or less, with the message Won opportunities need a positive Amount." |
Say who should have access
When you create a field, tell AI Admin which profiles get read and which get edit. That is the difference between a field your team can use straight away and one they cannot see yet, and it is the single most useful detail to include.
Say what to keep when you update something
AI Admin modifies existing flows, classes, validation rules and objects in place, so you can improve automation you already have without rebuilding it. Phrase an update as what to add plus what to leave alone: "add X, and keep the existing Y and Z". Boundaries like "leave the existing error message alone" or "nothing else on this object changes" are the most useful thing you can add, because they are what stops a change growing wider than you intended.
Batch several of the same thing into one prompt
Adding five fields to one object is one prompt, not five trips through the field wizard.
On the Account object, create these fields and give the Sales and Sales Manager profiles read and edit access to all of them:
- Sales Region, picklist: West, East, Central, South
- Account Tier, picklist: Platinum, Gold, Silver
- Renewal Date, date
- At-Risk, checkbox
- Health Notes, long text area
This works best for several of the same simple thing. Work that spans different kinds of component tends to go better as separate tasks, so split a change that touches a flow, an Apex class and a layout rather than asking for all three at once.
Read the plan before you approve it
AI Admin writes a technical design covering the whole solution and each component it will create or update, and shows it to you before it builds anything. This is the review point and it is worth the few minutes.
Because it is good at filling in the details, it will sometimes include a bit more than you asked for, and occasionally it will reference a field or component that sounds right for the pattern but does not exist in your org. Reading the design is how you catch both. You can comment on it and regenerate from your comments, at the level of the whole solution or a single component, and you can review each component on its own before approving it.
If a deploy is rejected, ask it to try again
A rejection is a normal step rather than a verdict, and a second attempt often works. This is the habit that separates getting a lot out of AI Admin from getting a little, and it takes no particular skill.
Go back to the conversation and tell the Assistant the task failed. You do not need to interpret the error or paste anything in. "The admin task failed on the flow" is enough to work with.
Give each build a quick confirm
A ten second once-over before you roll it out is the same check you would give your own work. For a flow, make sure it is switched on. For a field, that the people who need it can both see and edit it. For Apex, that the test class is there.