Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Briefly: prompts against CRM data fail for three reasons, and none of them is that the prompt was not clever enough. The output format was left to the model, the empty and missing fields were not handled, and nothing told the model what to do when the data does not support an answer. Fix those three and most of what people call prompt engineering stops being necessary.

Be specific about format

An unspecified format gets you whatever the model feels like, and it will vary between runs. If anything downstream reads the output, that variation is a defect.

Weak instruction:

Summarise this opportunity.

Better:

Write exactly two sentences. First sentence: what
the customer is buying and the stage. Second: the
next step and who owns it. No greeting, no closing,
no bullet points. Plain text only.

Specify length in a countable unit. “Brief” is not a length. “Two sentences” is. Say what you do not want too, because models add framing sentences by default and those are what make generated text obvious.

If the output feeds a field, give the limit. A 255-character field receiving a 400-character summary fails at the write.

Handle missing fields explicitly

This is the largest single source of bad output against CRM data, because CRM data is mostly incomplete.

A blank field merges as nothing at all. The prompt arrives with a label and no value, and the model does what it does best: it produces something that fits the pattern. An opportunity with no close date gets a close date. A contact with no title gets a plausible title.

The fix is a sentence, and it belongs in every template that touches optional fields:

Some fields may be empty. Where a value is missing,
write "not recorded". Never infer, estimate or
substitute a value from context.

Then test it with a genuinely empty record, not a tidy demo one. The demo record has every field populated, which is why the problem never appears until go-live.

Preventing invention

The model will fill gaps unless told not to, and it does it fluently, which is what makes it dangerous. Three things reduce it.

State the boundary. “Use only the information above. If it is not stated, say it is not available.” Not a guarantee, and it changes the rate substantially.

Do not ask open questions of closed data. “What are the risks on this deal?” invites speculation. “List any risks explicitly noted in the description or the most recent activity” does not.

Keep numbers out of the model. Any figure that matters should be calculated elsewhere and merged in as finished text, with an instruction to repeat it exactly. Models manipulate digits as text, get simple sums right often enough to build confidence, and then quietly do not.

CRM-specific details that catch people

  • Picklist API names. The model sees the stored value, which may be an internal code rather than a human-readable label. Merge the label instead.
  • Free text is adversarial. Case descriptions and notes contain whatever a customer typed, including text shaped like instructions. The model cannot distinguish your instructions from theirs by origin. Put your instructions after the data, be explicit that the data section is content rather than direction, and do not rely on either as a security control.
  • Long fields crowd out instructions. A description field of several thousand words dilutes everything you wrote. Truncate before merging when the field can be large.
  • Dates and currency. Generated text, not formatted values. The model may write a date in a convention your users do not use. State the format you want.

Iterate on failures, not on wording

The common mistake is rewording a prompt repeatedly based on one bad output. That is tuning against noise, because a second run of the original prompt would have produced something different anyway.

Keep a fixed set of twenty records covering your awkward cases. Run every change against all twenty. Count how many outputs are acceptable. If a change does not move that count, it did not help, however much better the new wording reads.

Frequently asked

Do examples help? Yes, usually more than extra instruction. Two or three examples of good output pin the format better than a paragraph describing it.

Should I tell it to be accurate? “Be accurate” does nothing. Constraints do. Name what it may use and what it must do when the data runs out.

How do I stop it sounding like marketing? Ban the register directly, and supply real examples written by a person. Default output is enthusiastic, and the default is what you get unless you say otherwise.

Does a longer prompt work better? Only up to a point. Past it, instructions compete with each other and adherence drops. Cut instructions that are not earning their place.