# How to use AI without connecting it to your Salesforce org
Security said no. Requirements, logic design, and specs were never the blocked part. Here is the four-step workflow, with the prompts.
**Time:** 12 minutes
**What you'll have when you're done:** A user story with acceptance criteria QA can test, a written list of open questions to send back to your business owner, and a design decision with its reasoning captured. No org connection, no security review, no data leaving the building.
**Before you start:**
- Any AI chat tool you're allowed to use
- A ticket or request you haven't started building yet
---If AI isn't approved against your org, every guide you've found assumes otherwise. This one assumes you didn't get a yes.
What's blocked is **access to org data**, not the work. Requirements, logic design, specs, and test plans are most of where your hours go, and none of it needs a connection.
The order matters more than any single prompt. Most bad specs come from skipping straight from step 1 to step 4.
---
## Step 0: the rule that keeps you employed
**Describe structure. Never paste data.**
| Fine | Never |
|---|---|
| Object and field names | Actual records |
| Relationships between objects | Customer or contact names |
| The business rule in words | Real pricing on a real deal |
| Field types and formula logic | Exported reports |
| Approval thresholds as concepts | Screenshots with data visible |
Read your company's AI usage policy first. If there isn't one, assume the stricter version.
---
## Step 1: describe the situation (the part people get wrong)
Most bad output comes from a two-sentence prompt. Fill this in instead. It takes five minutes, and it's the whole difference between a usable spec and confident filler.
```
CONTEXT
Platform: [e.g. Salesforce, standard approval framework, no custom code preferred]
Objects involved: [names and how they relate]
Who does this: [role, and their permission level]
THE ASK, AS IT ARRIVED
[paste the ticket verbatim, however vague]
WHAT I ALREADY KNOW
- [constraint 1: a thing that must stay true]
- [constraint 2]
- [what triggers this: a button, a status change, a field edit]
- [what has to come out the other end: a document, a notification, a record]
MY CURRENT INSTINCT
[e.g. "formula field over trigger if the logic allows". Say it so it can be argued with]
WHAT I HAVEN'T DECIDED
[anything you know is unresolved]
```
The "what I already know" section is doing the work. Vague in, confident garbage out. And confident garbage in professional formatting is more dangerous than obvious garbage.
---
## Step 2: the interrogation prompt
Paste this after your filled-in scaffold. Do not ask for the spec yet.
```
Before writing anything, interrogate this.
List every question a senior developer would ask before starting
that I haven't answered above. Group them:
- Business rules I've assumed but not confirmed
- Edge cases and reversal paths
- What enforces each constraint (validation, lock, or training expectation)
- Approval and audit gaps
- Null and fallback cases for anything customer-facing
Then argue against my stated instinct. Give me the strongest case
for the opposite approach.
Do not write the user story yet.
```
That last line matters. Left to its own devices it'll skip to the deliverable, which is where the unexamined assumptions get baked in.
**What good output looks like:** ten to fifteen questions, several of which you can't answer. **What bad output looks like:** questions whose answers are already in your scaffold. That means your input was too thin, or it ignored it. Say so and re-run.
Download the prompt template →Both prompts, the scaffold, and the failure modes in one plain-text file. No signup.
---
## Step 3: split the questions three ways
Do this by hand. It's the only judgment call that can't be delegated.
1. **Back to the business owner.** Anything about intent or policy. Send these as a list; you now have a documented reason your build hasn't started.
2. **Verify in a sandbox.** Anything about platform behavior. Non-negotiable, see the failure modes below.
3. **Your call.** Design decisions. Answer them in writing so the next person doesn't relitigate it.
---
## Step 4: ask for the artifacts
Only now, and one at a time:
```
Constraints still binding: [restate them. Long conversations drop them]
Answered since: [the questions you resolved, with answers]
Now write:
1. The user story, with acceptance criteria specific enough for QA
to test. Each one a pass/fail statement, not a description
2. The design decision and its reasoning, so it isn't reopened later
3. A test plan covering the reversal and null paths
```
Restating the constraints is not optional. On anything longer than an hour, things established early get quietly dropped.
---
## Worked example
The ticket, in full: *"Salespeople need to change a customer's billing model on equipment they already have, without it looking like a new order."*
Constraints I brought: existing unit tracked as an asset with a current billing model and term; the equipment configuration must stay identical because only the charging changes; approval required above a dollar threshold; customer signs a document showing old price beside new; formula field preferred over a trigger.
Questions that came back which I could not answer:
- Remaining term on the current model: prorated, forgiven, or carried?
- Reversible? If the salesperson flips it back same-day, one approval or two?
- What *enforces* configuration identity: field locked during the process, validated at save, or a training expectation?
- What does the signature document show when the new model has no comparable price? Is there a fallback display value, and who decides it?
- Who approves when the salesperson is the manager?
- Nine months later, which record answers "why did this account's billing change"?
Six went to the business owner. Four had never been written down. Two changed the design. The reversal path became a test case that didn't exist before question two.
The version where I skip this is the version where the fallback display value gets discovered in UAT.
---
## Where this breaks
**It invents platform behavior confidently.** Governor limits, what a formula field can reference, field-type availability in a given context, what a managed package exposes. It sounds equally certain when wrong. Every platform claim is a hypothesis until a sandbox says otherwise. The reasoning is usually sound; the specific limits often aren't.
**Recent releases are the worst ground.** Renamed products and this year's features are where you'll get stale answers. Old stable behavior is safe.
**It agrees with you.** Propose a bad design confidently and you'll get help building it. That's why Step 2 makes it argue the other side explicitly.
**It drifts.** See Step 4.
---
## What you're not getting
It can't see your org, so it can't audit metadata, find unused fields, or tell you why that Flow fails in production. Those need the connection you don't have. This is the other half. The half that happens in a document before anything gets built.
## Not on Salesforce?
Same wall everywhere: NetSuite, SAP, Workday, Epic, ServiceNow. Data blocked, thinking work not. Change the object names; the four steps are identical.