Indu Learning Platform
Course/Unit 5 · AI foundations
Lesson 5-2

Prompting for SAP work

A repeatable five-part prompt structure and reusable patterns for specs, mappings, test cases and error analysis.

Watch firstAI prompt engineering: A deep dive · AnthropicOpen on YouTube ↗

Prompting is writing a good brief

A good prompt is the brief you would give a junior consultant, written down. The difference: the model was not in the blueprint workshop and will not ask questions unless told to. Everything that matters must be in the prompt. Vague prompts get generic answers; specific prompts get checkable ones.

Anatomy of a good prompt

PromptContextProject, releaseData model, domainTaskOne clear jobWho it is forInputsSpec extractSample rowsError logOutputTable or JSONLength, languageChecksList assumptionsFlag gapsSay 'unknown'
Context, task, inputs, output, checks. Same five parts every time.

Try it: sort the prompt lines

Try it · Sort

Each line comes from one prompt. Which part does it belong to? (The inputs themselves sit between tags.)

Context
Task
Output format
Checks
Click an item, then a bucket (or drag it).

Delimiters and examples

Wrap each input in delimiters such as <spec>...</spec> so the model can tell data from instructions. Add one to three few-shot examples of the exact output you want; models copy a shown format more faithfully than a described one.

Prompt
You are assisting an SAP MDG migration team (ECC 6.0 -> S/4HANA 2023).
Task: propose a source-to-target mapping for Business Partner (customer role).
Use ONLY the fields inside <source> and <target>.

<source>KNA1: KUNNR, NAME1, NAME2, STRAS, ORT01, PSTLZ, LAND1, STCD3, KTOKD</source>
<target>Migration Cockpit "Customer": BP number, Name 1, Name 2, Street, City,
Postal code, Country, Tax number (category + value), BP grouping</target>

Example row:
| KNA1-NAME1 | Name 1 | 1:1 copy, trim spaces | H |

Output: markdown table  source | target | transformation rule | confidence (H/M/L)
Then list: source fields with no target, target fields needing a default
or value mapping, and every assumption you made.

Delimiters separate data from instructions; the example row fixes the format.

Pattern library for MDG work

Most daily prompts fit a few patterns. Keep one tested template per pattern in a shared place.

PatternInputs to pasteAsk forMapping specSource + target fields, rulesTable + gaps + confidenceTest casesBRF+ table, CR typePositive, negative, edge casesIDoc triageStatus 51 texts, segmentCause, fix, owner per errorSpec reviewFS sectionAmbiguities, missing rulesDuplicate checkTwo supplier recordsSame/different + evidenceLog summaryWorkflow / DRF logTimeline + root cause
Six patterns cover most MDG prompting.

Ask for checks and evidence

End with 'list your assumptions and missing information', and make 'unknown' an acceptable answer; otherwise the model fills gaps. Ask it to quote the evidence for each conclusion. Quotes take seconds to verify and make invented facts stand out.

Prompt
Compare the two supplier records inside <a> and <b>.
Decide: SAME, DIFFERENT or UNSURE.
Quote the exact field values that support your decision.
If tax number, bank account or address is missing, answer UNSURE
and say which field is missing. Do not guess values.

<a>
Name: Müller Industrietechnik GmbH | Street: Hauptstr. 12 | City: Stuttgart
VAT: DE123456789 | IBAN: DE89 3704 0044 0532 0130 00
</a>
<b>
Name: Mueller Industrie-Technik GmbH | Street: Hauptstrasse 12 | City: Stuttgart
VAT: DE123456789 | IBAN: (empty)
</b>

Try it: complete the prompt

Try it · Fill the blanks

Fill the blanks so the prompt is grounded, checkable and easy to parse.

You are assisting an SAP MDG team (S/4HANA 2023 hub).
Task: list every validation rule for supplier creation.
Use ONLY the material inside the  tags.
If a rule is not in the spec, write  instead of guessing.
Return a : rule | field | source section.
Finally, list your  and any missing information.

<spec>
...pasted FS section 4...
</spec>

Building a prompt, part by part

Step through · 1 of 5
Vague askAdd contextPaste inputsFix the formatAsk for checks
'Write test cases for supplier onboarding.' The model has to guess your release, CR types and rules, so you get generic test cases.
Each part closes one gap the model would otherwise fill by guessing.

Iterate like a tester, not a gambler

When a prompt fails, do not reword at random. Keep a few inputs with known answers, change one thing, rerun them all. Lesson 5-5 turns this into a proper test set.

Draft promptRun on 5 knowncasesCompare to expectedFind the failurepatternChange one thing
Small, controlled changes against the same cases.

Try it: symptom to fix

Try it · Match

Match each prompt failure to the first fix to try.

Pick an item on the left, then its match on the right.

Remember

  • A prompt is a written brief: context, task, inputs, output, checks.
  • Delimiters separate data from instructions; examples fix the format.
  • Ask for assumptions and quoted evidence, allow 'unknown', and iterate against known cases.

Check yourself

Which prompt element most reduces made-up answers?
Your mapping prompt returns prose instead of a table. Best first fix?
Why wrap pasted IDoc logs in <idoc_log> tags?
A prompt fails on one duplicate-supplier case. What is the disciplined next step?