4.3 Configure Actions and Connectors in Flows

Actions are the work; connectors are the hands

Creating a flow (Section 4.1) and adding human gates (Section 4.2) still leave the core exam skill: configure actions and connectors so the automation reads and writes the right systems safely. In Copilot Studio, connectors are proxies around APIs—the same Power Platform connector fabric used by Power Automate and Power Apps—so skills transfer, but AB-620 focuses on how those connectors appear inside agent flows and how they interact with agents, capacity, and governance.

Action categories in an agent flow

When you select Insert a new action, think in Microsoft’s four buckets:

Exam stems that say “post to Teams after Dataverse create” are connector configuration problems. Stems that say “loop each line item and compose a summary string” are built-in data-operation problems. Stems that say “classify the attachment then create the row” mix AI actions with connectors.

How connectors show up in Copilot Studio (broader context)

Connectors are not only for flows. Microsoft documents multiple surfaces:

• Agent tools (agent-level Tools page)
• Topic tools (Action nodes on a topic)
• Agent flow actions (this section’s focus)
• Knowledge sources (some connector-based knowledge patterns)

For AB-620 flow questions, stay focused on the flow designer action: pick the connector operation (for example Create a new row in Dataverse, Post message in a chat or channel in Teams), authenticate the connection, and map inputs/outputs.

Connector classes

Choosing connector vs custom code (decision guidance for scenarios):

Rule of thumb: lowest custom surface that is governable. Prebuilt connectors inherit Microsoft’s connector updates and admin DLP controls; custom code and raw HTTP increase maintenance and review burden.

Input mapping and parameters

Every trigger and action card has a Parameters pane. Values come from:

1. Static constants — fixed channel ID, fixed list name for a single-purpose flow
2. Dynamic content — outputs of the trigger or earlier actions (email subject, RFI number field, Dataverse row ID)
3. Expressions — formulas when you must combine, format, or convert values (including base64 conversion for some approval file inputs)

Mapping checklist:

• Match types (string vs number vs boolean); convert explicitly when needed
• Prefer IDs returned by prior create actions over hard-coded GUIDs that differ per environment
• For environment portability, plan environment variables or solution configuration rather than baking production URLs into every action
• After human-in-the-loop steps, map RFI/approval outputs into connector fields (cost center, approve flag, adjusted amount)
• Use Apply to each carefully—each iteration multiplies connector actions and capacity

Example chain: Outlook trigger → AI extract fields → Compose normalized vendor name → Dataverse Add a new row (map composed fields) → Condition on amount → Teams Post message with row link dynamic content.

Authentication and connections

Connectors require a connection (stored credentials/consent for that API).

For agent-level connector tools, Microsoft documents switching Credentials to use to Maker-provided credentials under tool details after the agent uses an authenticated channel. In flows, the connection on each action is typically the identity configured on that connection reference—treat connection references in solutions as ALM assets so DEV/TEST/PROD do not silently share the wrong mailbox.

Security notes that appear in real deployments (and scenario traps):

• DLP policies can block connector combinations or premium connectors—publish failures may be governance, not “broken mapping”
• Sharing connections in Power Apps/Power Automate (Can use + share) may be required for other makers
• SSO limitations exist in some Teams + custom AD auth configurations for connector tools—users may need manual connection setup
• Least privilege: a maker connection with global admin rights is a poor default for production agent flows

Configuring actions in the designer (exam procedure)

1. Under the previous card, select Insert a new action
2. Search by connector or operation name
3. Create or select a connection
4. Fill required parameters; use dynamic content where the value is run-specific
5. Add conditions for failure paths (empty ID, connector error) before assuming success
6. Run Flow checker; fix red errors
7. Publish and Test; open each action’s outputs to verify mapping
8. If the flow is an agent tool, confirm Respond to the agent returns the fields the topic/orchestrator expects

Capacity and performance with connectors

Every connector call is an action for capacity. Design implications:

• Batch or filter early so you do not loop hundreds of unnecessary updates
• Prefer Get item / targeted queries over downloading entire lists
• Keep agent-invoked flows under the 100-second response expectation
• Avoid chatty sequences (create, update, update, update) when one create with complete fields works
• Test runs in the designer do not consume capacity—use them to perfect mappings before load

Scenario: Contoso service desk agent flow

Requirements: when an agent classifies a user issue as “hardware,” create a ServiceNow incident, attach the conversation summary, and email the ticket number back to the agent response.

Configuration outline:

1. Trigger: When an agent calls the flow with input parameters IssueSummary, UserEmail, Urgency
2. Action: ServiceNow connector Create incident — map urgency and short description from inputs; use a maker or integration account connection authorized for incident create
3. Built-in: Compose a user-facing message including returned number
4. Optional: Outlook Send an email to the user if business wants dual notification
5. Respond to the agent with TicketNumber and Message (Asynchronous response Off)
6. DLP check: ServiceNow + Outlook allowed together in the environment policy
7. If no ServiceNow prebuilt operation matches Contoso’s custom table API, build a custom connector from their OpenAPI rather than embedding long custom scripts in the flow

Wrong exam answers often suggest pure generative “make up a ticket number,” or using SharePoint knowledge as if it creates incidents. Ticket creation is a connector action (or custom connector), not knowledge.

Connector vs topic tool vs flow action — same API, different control

You can call many connectors directly as agent tools without a flow. Use a flow when you need:

• Multi-step orchestration across several connectors
• HITL between connector calls
• Centralized error handling and retries before responding to the agent
• A reusable automation also started by schedule or email, not only chat

Use a direct connector tool when a single operation with light parameters is enough and orchestration can call it once.

Configuration pitfalls checklist

1. Unmapped required fields — publish blocked or runtime failures
2. Wrong connection identity — works in maker test, fails for users or posts as the wrong account
3. Hard-coded environment IDs — breaks when solution is imported
4. Ignoring DLP — connector available in gallery but blocked at runtime/publish
5. Oversized payloads — slow runs, timeouts on agent-called flows
6. No response shape — agent cannot speak the ticket number because Respond to the agent omitted outputs
7. Custom code first — higher cost when a standard connector already exposes the operation

Putting Sections 4.1–4.3 together

A production-grade agent flow is usually: well-chosen trigger → connector and AI actions with clean mapping → optional HITL → more connector side effects → respond or notify. Capacity, DLP, authentication, and determinism are part of the design, not operations-only concerns. If you can explain which action category, which connector class, whose credentials, and how inputs are mapped for a Contoso-style stem, you are operating at AB-620 level for this skill.