13.2 Adding Inputs to a Prompt

Key Takeaways

  • Inputs turn a one-off instruction into a reusable function by injecting caller-supplied values into the prompt at run time
  • In the prompt designer you add inputs by typing / or selecting Add content; the Input section offers Text and Image or document
  • Selecting an input inserts a dynamic placeholder into the instruction that is replaced with the caller's value before the model runs
  • Every input carries a design-time sample value so the Test button can run the prompt before it is saved; sample values are not runtime defaults
  • When a flow calls a prompt with the Run a prompt action, each declared input becomes a mappable dynamic field, so descriptive input names matter
Last updated: July 2026

An input turns a one-off instruction into a reusable function. Instead of hard-coding the text to summarize inside the prompt, you declare an input — a named, dynamic value supplied every time the prompt runs. Microsoft defines input variables as the mechanism that lets you incorporate dynamic runtime content within a prompt and validate its behavior before integration into business solutions.

Input types in the designer

In the prompt designer, type / or select Add content. The Input section offers:

Input typeDesigner entryRuntime source example
TextAdd content > Input > TextA flow passes the body of a triggering email
Image or documentAdd content > Input > Image or documentAn app uploads a photo of a receipt or a scanned PDF

Dataverse record data reaches a prompt in two ways: as knowledge (covered in section 13.3) or by mapping record fields into text inputs when the prompt is called from a flow or app. For the exam, remember the contract: a prompt's declared inputs are exactly what every caller must supply on each run.

Inserting inputs into the instruction

Selecting an input inserts a dynamic placeholder into the instruction text, displayed as the input's name in the editor — for example: Summarize the following support case: CaseDescription. At run time the placeholder is replaced by the caller's value before the language model sees anything. Placement matters: reference each input at least once, put it near the instruction that uses it, and label what it is (The customer wrote: ...) so the model does not confuse input text with your directive.

Test values per input

Every input has a sample value field in the designer. Fill in each one before selecting Test — the test run substitutes those samples for the placeholders. Two exam-relevant facts follow. First, sample values are design-time only; they are not defaults at run time, so a caller that passes nothing leaves the placeholder empty. Second, treat every declared input as required in practice: the prompt's output quality depends on each placeholder receiving real content. If a run can legitimately omit a value, say so in the instruction (If no priority is provided, do not mention priority) rather than relying on optional-parameter behavior.

Exam trap: adding an input does nothing until you insert its placeholder into the instruction. A prompt with three declared inputs but no placeholders in the text runs on the instruction alone and ignores whatever callers pass.

Naming inputs for consumption

Input names become the public schema of your prompt, so name them for the people who will call it:

  • Power Automate — the AI Builder Run a prompt action renders one mappable dynamic field per input. CaseDescription is self-documenting; Input1 is not.
  • Power Apps / Power Fx — inputs surface as parameters when the prompt function is called from a canvas app.
  • Copilot Studio — the agent sees input names when wiring the prompt tool into a topic, and uses them to decide what to pass.

Data type mapping is straightforward but examinable. Text inputs accept strings: map any Dataverse text column, a compose action's output, or a Power Fx variable directly. Numbers, dates, and choices from Dataverse are passed as their string representations, so tell the model how to interpret them (The priority is 1 = high, 2 = normal). Image or document inputs receive file content — for example the File Content output of a SharePoint or Dataverse file field — not a URL or file name.

Worked example: Summarize a support case

Contoso's service team wants a three-sentence brief of any support case. The build:

  1. In make.powerapps.com, go to AI hub > Prompts > Build your own prompt and rename it Summarize support case.
  2. Add three Text inputs: CaseTitle, CaseDescription, CasePriority.
  3. Write the instruction: You are a support assistant. Summarize the case below in exactly three sentences for a busy agent. Use a neutral tone and never speculate about causes. Case title: CaseTitle. Priority: CasePriority. Description: CaseDescription.
  4. Enter sample values for each input — a realistic title, a paragraph-long description, priority 1.
  5. Select Test. If the summary rambles, tighten the format directive; if it invents causes, strengthen the never speculate clause. Re-test until stable.
  6. Save. A flow can now call it with Run a prompt, mapping the Case table's columns to the three inputs, or a prompt column on the Case table can generate the summary automatically from the row.

Exam trap: when a scenario says the flow must pass the description of the record that triggered the flow, the correct answer is a text input mapped to that Dataverse column — not a knowledge source and not a custom AI Builder model. Inputs answer the question what does the caller hand to this specific run; knowledge answers what reference data should ground every run.

Test Your Knowledge

In the prompt designer, how does a maker insert a declared input into the instruction so the caller's value is injected at run time?

A
B
C
D
Test Your Knowledge

A cloud flow must pass the description of the Dataverse case record that triggered it into a prompt. What should the maker configure?

A
B
C
D