Practical Build Walkthrough: Create a SharePoint Request from a Copilot Studio Agent
The architecture discussed so far becomes much easier to understand when implemented as a small end-to-end solution.
In this walkthrough, we will build an atomic enterprise Agent capability:
The user asks the Agent to create an internal request. The Agent collects the required information, calls an Agent flow, the Flow creates a SharePoint list item, and the generated SharePoint item ID is returned to the Agent.
The architecture is intentionally small:
User
↓
Copilot Studio Agent
↓
Agent Flow Tool
↓
SharePoint Connector
↓
SharePoint List
↓
Structured Result
↓
Agent
↓
User
This example demonstrates the most important Agent-to-Flow concepts without introducing unnecessary complexity such as Microsoft Graph, Dataverse, Azure Functions, custom connectors, or external APIs.
1. Scenario
Assume the organization has a SharePoint list named:
Access Requests
The Agent allows an employee to submit a request for access to a SharePoint site.
A typical conversation might be:
User
I need Member access to the Finance site because I’m joining Project Atlas.
The Agent should identify:
| Parameter | Value |
|---|---|
| Site | Finance |
| Requested Role | Member |
| Business Reason | Joining Project Atlas |
The Agent then calls an Agent flow.
The Flow creates the SharePoint item and returns something similar to:
| Output | Value |
|---|---|
| success | true |
| requestId | 1055 |
| status | Submitted |
The Agent can then tell the user:
Request 1055 was submitted successfully. Its current status is Submitted.
Notice the responsibility boundaries.
The Agent understands the language.
The Agent flow performs the transaction.
SharePoint stores the authoritative business record.
2. Create the SharePoint List
Create a SharePoint list named:
Access Requests
For the first version of the laboratory, keep the data model deliberately small.
| Column | Type | Purpose |
|---|---|---|
| Title | Single line of text | Request title |
| SiteName | Single line of text | Requested SharePoint site |
| RequestedRole | Choice | Requested permission |
| BusinessReason | Multiple lines of text | Business justification |
| Status | Choice | Request state |
Configure RequestedRole with values such as:
Read
Member
Owner
Configure Status initially with:
Submitted
Pending
Approved
Rejected
For this first implementation, we are not creating an approval process.
The goal is only:
Agent → Flow → SharePoint → Agent
Once this contract works reliably, additional business logic can be introduced safely.
3. Define the Contract Before Building the Flow
Before opening the designer, define the interface.
This is an important enterprise development habit.
Our Tool contract will be:
Inputs
siteName
requestedRole
businessReason
Outputs
success
requestId
status
Conceptually:
Agent
siteName
requestedRole
businessReason
↓
Agent Flow
↓
SharePoint
↓
success
requestId
status
↓
Agent
The Flow does not need the original user message.
It receives structured business data.
4. Create the Agent Flow
In Microsoft Copilot Studio, open:
Flows
Select:
New flow → Agent flow
Copilot Studio creates the initial Flow structure.
The important elements are:
When an agent calls the flow
and:
Respond to the agent
The structure initially resembles:
When an agent calls the flow
↓
Respond to the agent
Everything required to perform the business operation will be inserted between these two nodes.
5. Configure the Agent Inputs
Open:
When an agent calls the flow
Add three inputs.
Input 1
Name:
siteName
Type:
Text
Description:
The SharePoint site requested by the employee.
Input 2
Name:
requestedRole
Type:
Text
Description:
The SharePoint permission level requested by the employee, such as Read, Member, or Owner.
Input 3
Name:
businessReason
Type:
Text
Description:
The employee's business justification for requesting access.
The contract now looks like:
When an agent calls the flow
siteName
requestedRole
businessReason
↓
Flow
The descriptions matter because these parameters eventually participate in the Agent Tool contract.
6. Add the SharePoint Action
Between the trigger and response, select:
Add an action
Search for:
SharePoint
Select:
Create item
Configure the SharePoint connection.
Then select:
Site Address
Choose the SharePoint site containing the Access Requests list.
Select:
List Name
Choose:
Access Requests
Now map the Flow inputs to SharePoint.
7. Map the Fields
Configure the SharePoint action approximately as follows:
| SharePoint Column | Value |
|---|---|
| Title | Access Request |
| SiteName | siteName |
| RequestedRole | requestedRole |
| BusinessReason | businessReason |
| Status | Submitted |
The architecture is now:
When an agent calls the flow
siteName
requestedRole
businessReason
↓
SharePoint — Create item
↓
Respond to the agent
This is already a complete transactional pipeline.
8. Capture the SharePoint Item ID
The SharePoint Create item action returns information about the record that was created.
One of the most useful values is:
ID
Do not discard this value.
The SharePoint item ID gives us a transaction identifier that the user and other processes can reference later.
For example:
1055
This enables future capabilities such as:
GetAccessRequestStatus(1055)
or:
CancelAccessRequest(1055)
Returning identifiers is therefore an important Tool design pattern.
9. Configure Respond to the Agent
Open:
Respond to the agent
Create three outputs.
Output 1
Name:
success
Type:
Boolean
Value:
true
Output 2
Name:
requestId
Use the ID returned by the SharePoint Create item action.
Output 3
Name:
status
Value:
Submitted
The resulting contract becomes:
Agent
↓
siteName
requestedRole
businessReason
↓
Agent Flow
↓
SharePoint Create item
↓
SharePoint ID
↓
Respond to the agent
success = true
requestId = SharePoint ID
status = Submitted
↓
Agent
This is our first complete Agent-to-business-system contract.
10. Check the Response Mode
For an Agent flow used as an Agent Tool, the response must be synchronous.
Inspect the settings of:
Respond to the agent
Under the relevant networking settings, verify that:
Asynchronous response = Off
The Agent expects a real-time response from this callable Flow.
The Flow should also normally return within the documented Agent action execution limit.
This means the synchronous section should remain small and efficient.
Our laboratory is ideal:
Create SharePoint item
↓
Return result
There is no long-running approval or heavy processing.
11. Publish the Flow
Select:
Publish
The Agent flow must be published before it can be added to the Agent as a Tool.
At this point, our automation exists independently of the conversational experience.
This is useful because we can reason about two separate components:
Component 1
Agent
Component 2
Agent Flow
This separation makes testing and troubleshooting considerably easier.
12. Add the Flow to the Agent
Return to the Agent.
Open:
Tools
Select:
Add a tool
Select:
Flow
Find the Agent flow we just created.
Select it and choose:
Add and configure
The Flow now becomes an executable capability available to the Agent.
Architecture:
Agent
↓
Tool
↓
Agent Flow
↓
SharePoint
13. Configure the Tool Name
Use a business-oriented name.
For example:
Create SharePoint Access Request
Avoid names such as:
Flow1
or:
CreateItemFlow
The Agent needs to understand the business capability, not its implementation technology.
14. Configure the Tool Description
A useful description would be:
Creates a new SharePoint access request for an employee. Use this tool when the user wants to submit a new request and the target SharePoint site, requested permission level, and business justification are known. The tool creates the request and returns the request ID and initial status. Do not use this tool to retrieve or cancel an existing request.
This description establishes:
WHAT the Tool does.
WHEN it should be used.
WHAT information it requires.
WHAT it returns.
WHAT it should not be used for.
That information helps generative orchestration select the capability correctly.
15. Inspect the Inputs
The Tool should expose:
siteName
requestedRole
businessReason
For each input, Copilot Studio can determine how the value should be filled.
With generative orchestration, a common configuration is:
Dynamically fill with AI
This allows the Agent to extract values from the conversation.
Suppose the user says:
I need Member access to Finance because I’m joining Project Atlas.
The Agent may derive:
siteName = Finance
requestedRole = Member
businessReason = Joining Project Atlas
without manually asking three separate questions.
16. Test Missing Information
Now try:
I need access to Finance.
The Tool requires:
siteName
requestedRole
businessReason
The conversation only provides:
siteName = Finance
The Agent should recognize that additional required information is missing.
It can ask for the missing values before invoking the Tool.
For example:
What permission level do you need?
User:
Member.
The Agent still needs the business reason.
It may then ask:
What is the business reason for the request?
User:
I’m joining Project Atlas.
Now the contract is complete.
17. Configure Completion Behavior
After the Tool runs, decide how the Agent should present the result.
For the first laboratory, a controlled response is useful because we want to see exactly what happened.
A response could use:
requestId
and:
status
to produce:
Your access request {requestId} was created successfully. Current status: {status}.
For example:
Your access request 1055 was created successfully. Current status: Submitted.
This keeps transactional information grounded in Flow output.
18. First End-to-End Test
Open:
Test your agent
Enter:
I need Member access to the Finance site because I’m joining Project Atlas.
Observe the execution.
Expected architecture:
User message
↓
Agent interprets intent
↓
Agent selects Create SharePoint Access Request
↓
Agent fills Tool inputs
↓
Agent calls Agent Flow
↓
Flow calls SharePoint
↓
SharePoint creates item
↓
Flow receives item ID
↓
Flow returns requestId + status
↓
Agent presents result
Then open the SharePoint list.
A new item should exist.
Example:
| ID | SiteName | RequestedRole | BusinessReason | Status |
|---|---|---|---|---|
| 1055 | Finance | Member | Joining Project Atlas | Submitted |
At this point, the complete integration works.
19. What We Have Actually Built
Although the laboratory is small, the architecture is significant.
We built:
User
↓
Natural Language
↓
Generative Agent
↓
Intent Interpretation
↓
Structured Parameters
↓
Tool Contract
↓
Agent Flow
↓
Power Platform Connector
↓
SharePoint Online
↓
Persistent Business Record
↓
Structured Result
↓
Agent Response
This is already a real enterprise Agent pattern.
20. Test the Boundaries Separately
Do not test only the happy path.
Test at least these cases.
| Test | Expected Result |
|---|---|
| Site + Role + Reason supplied | Tool executes |
| Site only | Agent requests missing information |
| Site + Role only | Agent requests business reason |
| Ask about access policy | Tool should not execute |
| Ask status of existing request | Create Tool should not execute |
| Invalid SharePoint connection | Flow fails |
| SharePoint list unavailable | Flow fails |
| Valid request | SharePoint item created once |
These tests verify both orchestration and execution.
21. The Most Important Negative Test
Ask:
What permission levels can I request for SharePoint?
The Agent should not create a request.
This is an informational question.
Architecturally:
Question
↓
Knowledge / Agent Response
not:
Question
↓
Create Access Request Tool
If the Tool executes, investigate its name and description before changing the entire Agent.
22. Inspect the Flow Run
If the Agent says that something failed, do not immediately modify the Agent.
Open the Flow execution information.
Ask:
Was the Flow called?
If no:
Investigate Agent orchestration.
If yes:
Did the correct inputs arrive?
If no:
Investigate Tool input configuration.
If yes:
Did SharePoint Create item succeed?
If no:
Investigate SharePoint connection, permissions, list configuration, or data.
If yes:
Did Respond to the agent return the expected values?
This gives us a clean troubleshooting sequence:
Agent selection
↓
Input mapping
↓
Flow execution
↓
Connector execution
↓
Output mapping
↓
Agent response
Only change the layer that is failing.
23. Security Analysis
This small laboratory already raises an important production question:
Which identity is creating the SharePoint item?
The answer depends on how the Flow and its connections are configured.
The execution path is not simply:
User → SharePoint
It is:
User
↓
Agent
↓
Agent Flow
↓
SharePoint Connection
↓
SharePoint
Therefore, inspect the SharePoint connection used by the Flow.
Ask:
- Which account owns the connection?
- What permissions does that account have?
- Can the Agent be used by users who do not have equivalent SharePoint permissions?
- Does the Flow validate whether the caller is allowed to submit the request?
- Does the connection have more privileges than necessary?
A connected Agent does not automatically mean that every user should receive the permissions of the connection account.
24. Least Privilege
If this Flow only needs to create items in:
Access Requests
the execution identity should not unnecessarily have:
SharePoint Administrator
or:
Site Collection Administrator
privileges.
The target architecture should always move toward:
Required operation
↓
Minimum required permission
The laboratory can use a convenient development connection.
Production architecture requires deliberate identity design.
25. Why We Did Not Use Microsoft Graph
We could theoretically implement:
Agent
↓
Flow
↓
HTTP
↓
Microsoft Graph
↓
SharePoint
But that would introduce:
OAuth scopes
API requests
HTTP handling
JSON parsing
additional authorization concerns
without solving a problem that the native SharePoint Connector already solves.
For this scenario:
Native SharePoint Connector is the simpler architecture.
Graph should be introduced when a requirement justifies it.
26. Why We Did Not Use Dataverse
We could also store the request in Dataverse.
But our requirement is currently:
Create a simple internal access-request record.
SharePoint already provides:
List storage
permissions
views
columns
Power Platform integration
Microsoft 365 integration
There is no architectural reason yet to introduce Dataverse.
If the solution later requires complex relational data, business rules, model-driven applications, sophisticated security models, or deeper Power Platform application architecture, Dataverse may become appropriate.
Technology should follow requirements.
27. Why We Did Not Use SPFx
An SPFx application could easily implement an access-request form.
In fact, if the requirement were simply:
Show five fields and submit them to SharePoint
SPFx or even a standard SharePoint form might be more predictable and cheaper than an AI Agent.
The Agent becomes valuable when users benefit from:
Natural-language interaction
intent understanding
context
knowledge
multiple related capabilities
dynamic orchestration
This laboratory uses a simple process specifically to isolate and learn the Agent architecture.
28. Architecture Lesson
We did not build:
AI that creates SharePoint items.
We built:
AI reasoning
↓
structured capability contract
↓
deterministic automation
↓
SharePoint transaction
That distinction is fundamental.
The Agent does not directly become the business process.
It orchestrates the business capability.
29. Next Evolution of the Laboratory
Once this version works reliably, the architecture can evolve incrementally:
Version 1:
Agent
↓
Create SharePoint Request
Version 2:
Agent
↓
Create Request
↓
Return Request ID
Version 3:
Agent
↓
Create Request
↓
Start Approval
↓
Return Submitted status
Version 4:
Agent
├── Create Request
└── Get Request Status
Version 5:
Agent
├── Knowledge: Access Policy
├── Create Request
├── Get Request Status
└── Cancel Request
Eventually:
Employee Services Agent
│
├── Knowledge
│ └── Access Policies
│
├── Tools
│ ├── Create Access Request
│ ├── Get Access Request Status
│ └── Cancel Access Request
│
└── SharePoint
└── Access Requests
At that point, we have moved from a laboratory to the beginning of an enterprise Agent architecture.
Practical Lab Result
The completed architecture is:
User
“I need Member access to Finance because I’m joining Project Atlas.”
↓
Copilot Studio Agent
Understands:
Site = Finance
Role = Member
Reason = Joining Project Atlas
↓
Create SharePoint Access Request Tool
↓
Agent Flow
When an agent calls the flow
↓
SharePoint — Create item
↓
SharePoint creates:
ID = 1055
↓
Respond to the agent
success = true
requestId = 1055
status = Submitted
↓
Agent
“Your access request 1055 was created successfully. Current status: Submitted.”
This small implementation demonstrates the architecture that will be reused throughout the rest of the series:
Natural language in.
Structured contract across the boundary.
Deterministic business operation.
Structured result back.
Natural language out.
