Reuse a Power Platform prompt across records with input parameters

AB-410 By islever Editorial Last updated

Short answer

B Add input parameters so each record supplies its feedback and customer tier at run time without manual prompt edits.

Question

A company builds a custom prompt to summarize customer feedback and categorize responses by customer tier.
The company requires the prompt to be modified to be reused across multiple records without requiring manual updates.
You need to modify the prompt.
How should you configure the prompt?
  1. Use your own model.
  2. Add input parameters. Correct Answer
  3. Use a connector.
  4. Publish the prompt for reuse.

Key Takeaways

The question tests how AI Hub prompts achieve reuse across records; the trap is choosing publishing (D) or a model change (A) when neither removes per-record manual editing.

To reuse one prompt across many customer feedback records without editing it each time, add input parameters in AI Hub. The correct answer is B, because parameters let each record supply its own values while the prompt text stays unchanged.

Common mistake: D — publishing the prompt for reuse — seems to satisfy "reused," but publishing only shares the prompt; without input parameters each record still requires manual updates to the prompt text.

Expert Analysis

The qualifying requirement

The decisive wording is "reused across multiple records without requiring manual updates." The prompt already summarizes feedback and categorizes by customer tier; what is missing is a way for each record's own data to flow in without someone editing the prompt text every time. That is exactly what a parameterized prompt does — you insert placeholders such as {{feedback}} and {{customerTier}}, and Power Platform supplies the value per record at run time.

Why B is correct

Option B, add input parameters, converts the static prompt into a reusable template. The prompt body stays constant while each record supplies different values, so one prompt serves every record with zero manual edits between runs. This is the standard AI Hub pattern for prompt reuse across rows, and it matches the scenario's focus on customer feedback plus customer tier fields.

Why the others fail the constraint

  • A, use your own model, changes which language model generates the answer. It says nothing about injecting per-record data, so each record would still need manual prompt editing — the very thing the requirement forbids.
  • C, use a connector, would let a prompt fetch data from an external source, but the requirement is about reusing the same prompt across records, not about pulling additional data in; connectors alone do not vary input per record.
  • D, publish the prompt for reuse, only makes an existing prompt visible to other makers or apps. Publishing without parameters still means hard-coded text, so each record's feedback would require manual updates — failing the "without requiring manual updates" clause directly.

Reading the qualifier carefully

"Without requiring manual updates" is the filter that eliminates D (reuse by sharing, but still manual) and A (model choice, irrelevant to reuse), while "across multiple records" is what elevates B above C. The correct configuration is B.

Exam Strategy

On prompt-configuration questions, isolate the verb in the requirement — "reuse across records," "avoid manual updates," "fetch data" — and match it to the AI Hub feature that performs that verb. Publishing addresses visibility, connectors address data retrieval, and model selection addresses generation quality; only input parameters address per-record variability. Eliminate any option that leaves the prompt text needing edits.

Frequently Asked Questions

Why does adding input parameters avoid manual prompt updates?

Input parameters become placeholders in the prompt text, so each record's values are substituted at run time. The prompt body itself never changes, eliminating per-record editing.

Is publishing a prompt the same as making it reusable?

Publishing only makes the prompt available to other makers and apps. It does not vary the prompt per record, so you would still edit it manually for each new input.

When should I use a connector instead of parameters in a prompt?

Use a connector when the prompt must pull data from an external source at run time. Use parameters when the calling app or flow already has the per-record values to pass in.

More AB-410 FAQ →

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

  1. ah2006 👍 1 Answered B
    Same Prompt + different answers per record -> Input paramters

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

← Back to AB-410 Study Guide