fix(designer): Default agent connection type to MicrosoftFoundry#9028
fix(designer): Default agent connection type to MicrosoftFoundry#9028Elaina-Lee wants to merge 1 commit intomainfrom
Conversation
…ead of AzureOpenAI Since the underlying connection is the same, reclassify agent connections with a cognitiveResourceId (that aren't Foundry Service or APIM) as MicrosoftFoundry instead of AzureOpenAI. Preserves AzureOpenAI for backward compatibility when deploymentModelProperties is absent. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
🤖 AI PR Validation ReportPR Review ResultsThank you for your submission! Here's detailed feedback on your PR title and body compliance:✅ PR Title
✅ Commit Type
|
| Section | Status | Recommendation |
|---|---|---|
| Title | ✅ | Keep as-is or optionally append brief context |
| Commit Type | ✅ | No change needed |
| Risk Level | Change to Medium and update PR label + justification |
|
| What & Why | ✅ | Add a short migration/communication note (optional) |
| Impact of Change | ✅ | Clarify user-visible runtime impact (if any) |
| Test Plan | ✅ | Add E2E or justify absence; describe new unit tests coverage |
| Contributors | Add contributors or a one-line note if none | |
| Screenshots/Videos | ✅ | Ensure screenshots show UI text changes |
Final Recommendation
Please update the PR to set Risk Level to Medium (update the checklist and the GitHub label), and either add an E2E/integration test for the end-to-end connection classification/filtering behavior or include a short explanation of why E2E tests are not required. Also add a short migration/release-note sentence in "What & Why" about the impact on newly created workflows and the backward compatibility approach you implemented.
Suggested text snippets you can paste into the PR body:
- Risk level update (checkbox):
- [ ] Low - Minor changes, limited scope-> uncheck- [x] Medium - Moderate changes, some user impact-> check
- Risk label justification (to add near the Risk Level):
- "Justification: This PR changes the default agentModelType used for new agent workflows and modifies UI connection filtering/display labels. Although it preserves backward compatibility for existing workflows, the default behavior for new workflows will change and may affect user experience, therefore risk is Medium."
- Test plan note if skipping E2E:
- "We did not add E2E tests because the changes are limited to client-side classification and manifest defaults; unit tests cover the mapping logic and the fallback/backwards-compatibility paths. Manual testing validated the UI behavior. If maintainers prefer, we can add an integration test simulating the selectConnection flow."
Once you update the Risk Level and add the small clarifications above, this PR should be in great shape to merge. Thank you for the thorough description and for preserving backward compatibility by checking deploymentModelProperties. 👍
Last updated: Tue, 07 Apr 2026 23:41:29 GMT
There was a problem hiding this comment.
Pull request overview
Updates the Logic Apps Designer agent workflow experience to default agent connections/model selection to MicrosoftFoundry (instead of AzureOpenAI) across manifests and Designer v1/v2 connection handling, while keeping a backward-compat path for older AzureOpenAI workflows.
Changes:
- Changed the agent loop manifest default
agentModelTypetoMicrosoftFoundry. - Updated Designer v1/v2 connection picker tagging/filtering to treat
MicrosoftFoundryas the default model type and renamed the display label toMicrosoftFoundry (OpenAI). - Updated Designer v1/v2 connection update logic to preserve
AzureOpenAIfor older workflows whendeploymentModelPropertiesis absent.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| libs/logic-apps-shared/src/designer-client-services/lib/standard/manifest/agentloop.ts | Switches default agent model source in the standard agent loop manifest to MicrosoftFoundry. |
| libs/designer/src/lib/ui/panel/connectionsPanel/selectConnection/selectConnection.tsx | Tags agent connections with model type and adjusts A2A filtering for the new default. |
| libs/designer/src/lib/core/actions/bjsworkflow/connections.ts | Defaults agent model type to MicrosoftFoundry during connection updates with a compatibility exception for older AzureOpenAI workflows. |
| libs/designer/src/lib/common/utilities/Utils.ts | Renames the MicrosoftFoundry model type display string used in the connection picker/tagging. |
| libs/designer/src/lib/common/utilities/test/Utils.test.ts | Updates unit tests to match the updated MicrosoftFoundry display string. |
| libs/designer-v2/src/lib/ui/panel/connectionsPanel/selectConnection/selectConnection.tsx | Same as Designer v1: tagging/filtering updates for MicrosoftFoundry default. |
| libs/designer-v2/src/lib/core/actions/bjsworkflow/connections.ts | Same as Designer v1: connection update defaults + AzureOpenAI back-compat logic. |
| libs/designer-v2/src/lib/common/utilities/Utils.ts | Same as Designer v1: updates MicrosoftFoundry display string. |
| libs/designer-v2/src/lib/common/utilities/test/Utils.test.ts | Same as Designer v1: updates unit tests for the new display string. |
| @@ -88,7 +88,9 @@ export const SelectConnectionWrapper = () => { | |||
| }; | |||
|
|
|||
| // For A2A, hide the foundry connection from the list | |||
There was a problem hiding this comment.
The inline comment says "hide the foundry connection", but the filter condition is now allowing MicrosoftFoundry connections for A2A and still hiding FoundryService/APIM. Please update the comment to reflect what is actually being filtered (e.g., hide Foundry project/APIM connections for A2A).
| // For A2A, hide the foundry connection from the list | |
| // For A2A, hide Foundry project/service and APIM connections from the list. |
| @@ -88,7 +88,9 @@ export const SelectConnectionWrapper = () => { | |||
| }; | |||
|
|
|||
| // For A2A, hide the foundry connection from the list | |||
There was a problem hiding this comment.
The inline comment says "hide the foundry connection", but the filter condition is now allowing MicrosoftFoundry connections for A2A and still hiding FoundryService/APIM. Please update the comment to reflect what is actually being filtered (e.g., hide Foundry project/APIM connections for A2A).
| // For A2A, hide the foundry connection from the list | |
| // For A2A, hide Foundry project/APIM connections from the list |
| // Fallback: detect Foundry connections by cognitiveServiceAccountId resource pattern | ||
| if (!agentModelTypeValue) { | ||
| const cognitiveServiceId = connection.properties.connectionParameters?.cognitiveServiceAccountId?.metadata?.value ?? ''; | ||
| if (foundryServiceConnectionRegex.test(cognitiveServiceId)) { | ||
| agentModelTypeValue = 'FoundryAgentService'; | ||
| } else { | ||
| agentModelTypeValue = 'AzureOpenAI'; | ||
| agentModelTypeValue = 'MicrosoftFoundry'; | ||
| } |
There was a problem hiding this comment.
agentModelTypeValue fallback logic only checks foundryServiceConnectionRegex and otherwise defaults to 'MicrosoftFoundry'. This becomes incorrect when the incoming connection already carries a manifest-style model type (e.g. 'APIMGenAIGateway') or when the connection is an APIM/V1 connection but DisplayNameToManifest mapping fails.
To make this robust:
- If
rawModelTypeis already a known manifest value (e.g. present inAgentUtils.ManifestToDisplayName), treat it as the manifest value directly (skip display-name mapping). - Extend the fallback detection to match the picker logic (detect APIM via
apimanagementRegex, detect V1 when no cognitiveServiceAccountId is present) before defaulting to 'MicrosoftFoundry'.
| // Fallback: detect Foundry connections by cognitiveServiceAccountId resource pattern | ||
| if (!agentModelTypeValue) { | ||
| const cognitiveServiceId = connection.properties.connectionParameters?.cognitiveServiceAccountId?.metadata?.value ?? ''; | ||
| if (foundryServiceConnectionRegex.test(cognitiveServiceId)) { | ||
| agentModelTypeValue = 'FoundryAgentService'; | ||
| } else { | ||
| agentModelTypeValue = 'AzureOpenAI'; | ||
| agentModelTypeValue = 'MicrosoftFoundry'; | ||
| } |
There was a problem hiding this comment.
agentModelTypeValue fallback logic only checks foundryServiceConnectionRegex and otherwise defaults to 'MicrosoftFoundry'. This becomes incorrect when the incoming connection already carries a manifest-style model type (e.g. 'APIMGenAIGateway') or when the connection is an APIM/V1 connection but DisplayNameToManifest mapping fails.
To make this robust:
- If
rawModelTypeis already a known manifest value (e.g. present inAgentUtils.ManifestToDisplayName), treat it as the manifest value directly (skip display-name mapping). - Extend the fallback detection to match the picker logic (detect APIM via
apimanagementRegex, detect V1 when no cognitiveServiceAccountId is present) before defaulting to 'MicrosoftFoundry'.
📊 Coverage CheckThe following changed files need attention:
Please add tests for the uncovered files before merging. |
Commit Type
Risk Level
What & Why
Changes the default
agentModelTypefromAzureOpenAItoMicrosoftFoundryacross the agent loop manifest, connection tagging, and connection update logic (both designer v1 and v2). Since the underlying connection is the same for both types, this reclassifies connections with acognitiveResourceId(that aren't Foundry Service or APIM) asMicrosoftFoundry. Completes the deprecation started in PR #9012.Also renames the connection picker display label from "Foundry Models" to "MicrosoftFoundry (OpenAI)".
Backward compatibility: preserves
AzureOpenAIfor existing workflows that lackdeploymentModelProperties.Impact of Change
MicrosoftFoundry. Connection picker shows "MicrosoftFoundry (OpenAI)" tag. Existing AzureOpenAI workflows without deploymentModelProperties are preserved.Test Plan
pnpm run build:lib(9/9 success),pnpm run test:lib(3548+ tests passed)Contributors
Screenshots/Videos
Recording.2026-04-07.163829.mp4