13.3 Adding Knowledge to a Prompt

Left to itself, a prompt answers from the language model's training data — fluent, but unaware of your business. Knowledge fixes that. When you attach organizational data to a prompt, responses are grounded in your facts through retrieval-augmented generation (RAG): at run time the system retrieves the most relevant records from the connected source and injects them into the prompt before the model writes its answer. Because the model reasons over retrieved records instead of memory alone, grounding measurably reduces hallucination — confident, fabricated answers.

Supported knowledge sources

Verified against Microsoft Learn as of July 2026, prompt builder knowledge sources are:

• Dataverse tables — pick a table, select specific columns, and follow relationships to related tables.
• Connector tables — Salesforce, Oracle, SAP, and Zendesk — available only for prompts used in Power Automate.

Just as important is what is not a knowledge source here: documents and images are passed as inputs (the Image or document input type from section 13.2), not attached as knowledge objects in prompt builder. Expect the exam to exploit that distinction.

Adding and filtering knowledge

In the designer, type / or select Add content, then choose a data source from the Knowledge section. Navigate the source and select one or more columns — each selection becomes a knowledge object in the prompt, which the model uses with your natural-language instruction. You can refine retrieval in two ways:

• Filter attribute — select the knowledge object, choose a field to filter on, and enter a value. The value can be free-form text or a prompt input, so the caller can steer retrieval on every run (for example, only FAQ rows whose Topic matches the caller's Question input).
• Insert data references — walk relationships and insert references to related tables' columns, such as an account's orders, and refer to them naturally in the instruction.

Microsoft's own scenario examples include summarizing an account from selected Account and Order columns, classifying an email into categories defined in a Category table, and drafting a reply matched against FAQ topics and solutions — all input-plus-knowledge patterns worth memorizing.

Limits and freshness you should know

Grounding is powerful but bounded, and the numbers are exam favorites:

• 30 records are retrieved by default; you can raise the limit to 1,000 in the prompt's settings.
• Relationships: only one-to-many and many-to-one, up to two levels deep (Account > Contacts, and one hop further).
• Virtual tables are not supported as knowledge sources.
• Filter attributes are limited to these data types: text, number, date and time, choice, currency, and unique identifier.
• Dataverse environment languages are a fixed supported list, and connector-based knowledge works only in prompts consumed from Power Automate.

On freshness: retrieval happens at run time against current data, so grounded answers reflect the table as it exists when the prompt executes rather than a snapshot frozen at authoring time. That is the awareness-level framing — size your columns and filters so the right rows fall inside the retrieval cap.

A worked scenario ties the limits together. Contoso grounds a Draft a reply prompt on its Dataverse FAQ table, selecting only the Topic and Solution columns to keep retrieval lean. The maker adds a filter attribute on Topic, bound to a text input named Question, so each run retrieves only rows relevant to the caller's issue — comfortably inside the 30-record default. When Contoso later asks why a lookup to a virtual-table product catalog fails to appear in the picker, the answer is the documented limitation: virtual tables are not supported as knowledge sources, so the catalog data must reach the prompt another way, such as a connector table in a flow or an input.

Security: grounding respects permissions

Grounded retrieval runs against Dataverse security. Makers need appropriate permissions to the underlying tables for them to be visible and selectable during setup, and retrieval honors the caller's data access — grounded answers come only from rows the user is permitted to read. You do not build a separate row-filtering mechanism on top; enterprise security is enforced at the data layer.

Inputs vs. knowledge vs. model settings — the decision matrix

Classic exam scenarios: summarize the account named in this run combines an input (the name) with knowledge (Account and Order columns); classify this email using the Category table uses knowledge with the email body as an input; pass the triggering record's description is an input alone.

Exam trap: a requirement that answers must come only from rows the signed-in user can access is testing the fact that grounding already honors Dataverse permissions — the correct answer keeps the knowledge source, not a custom security workaround. Conversely, a requirement to ground a prompt on an uploaded PDF is satisfied with an Image or document input, because prompt-builder knowledge sources are tables, not files.