Study guide
13.3 Adding Knowledge to a Prompt
Microsoft Certified: Intelligent Applications Builder Associate AB-410
Track your progress as you read
Finished sections get a check mark.
1 Introduction
1.1 About the AB-410 Exam 1.2 How to Use This Study Guide
2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools
2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options
3 Chapter 3: Environments and ALM Strategy
3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy
4 Chapter 4: Dataverse Tables and Columns
4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns
5 Chapter 5: Relationships, AI Data Features, and Data Security
5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security
6 Chapter 6: Model-Driven App Forms and Views
6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language
7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps
7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards
8 Chapter 8: Creating and Designing Canvas Apps
8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps
9 Chapter 9: Canvas App Components, Variables, and Error Handling
9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps
10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps
10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App
11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals
11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows
12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting
12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows
13 Chapter 13: Building Prompts in AI Hub
13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt
14 Chapter 14: Prompt Settings, Models, and Consuming AI
14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows
15 Chapter 15: Business Rules and Business Process Flows
15.1 Configuring Business Rules 15.2 Configuring Business Process Flows
16 Chapter 16: Calculated Columns and Business Logic Strategy
16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic
13.3 Adding Knowledge to a Prompt
Key Takeaways Explain This Topic AI
Grounding a prompt with knowledge uses retrieval-augmented generation (RAG): relevant records are retrieved at run time and injected into the prompt, which reduces hallucination
Prompt knowledge sources are Dataverse tables and — for prompts used in Power Automate — connector tables such as Salesforce, Oracle, SAP, and Zendesk
Knowledge retrieval returns 30 records by default and can be increased to 1,000 in settings; virtual tables are not supported
Only one-to-many and many-to-one Dataverse relationships are supported, up to two levels deep, and filter attributes are limited to text, number, date and time, choice, currency, and unique identifier types
Grounding respects Dataverse security: makers and callers need permissions to the underlying data, so grounded answers come only from data the user is allowed to read
Last updated: July 2026
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
If the scenario needs... Use...
- The specific record or value for THIS run Input
- Reference data that grounds ANY run (FAQ, catalog, policy rows) Knowledge
- Callers to steer which knowledge is retrieved Knowledge filtered by a prompt input
- A trained, deterministic prediction over many rows AI Builder model , not a prompt
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.