revert(designer): Add HL7 manifest back

[Eric-B-Wu]

This PR caused a revert on HL7 manifests: #9142

[github-actions]

🤖 AI PR Validation Report

PR Review Results

Thank you for your submission! Here's detailed feedback on your PR title and body compliance:

✅ PR Title

• Current: revert(designer): Add HL7 manifest back
• Issue: None — the title is clear, specific, and correctly indicates this is a revert.
• Recommendation: No change needed.

---

✅ Commit Type

• Properly selected as a revert-style change in the title/body context; although the template checkbox is not filled, this is acceptable because the PR is explicitly a revert PR.
• Note: No action needed.

---

✅ Risk Level

• The submitter did not select a risk label, and this PR also has no risk label. Based on the diff, the advised risk level is Low because the change is limited to re-adding two built-in HL7 operation manifests and associated metadata.
• Recommendation: Add the matching label risk:low.

---

✅ What & Why

• Current: This PR caused a revert on HL7 manifests: https://github.com/Azure/LogicAppsUX/pull/9142
• Issue: Brief but sufficient for a revert PR.
• Recommendation: Optional improvement: mention that this restores hl7decode and hl7encode support in the built-in manifest registry.

---

⚠️ Impact of Change

• The body does not fill in the impact fields, which is acceptable for a small revert, but adding a short impact summary would improve clarity.
• Recommendation:
  • Users: State that HL7 decode/encode actions will be available again.
  • Developers: Note that built-in manifest registration was restored for HL7 operations.
  • System: Indicate this is a low-risk manifest-only change with no expected runtime behavior impact beyond re-enabling the operations.

---

✅ Test Plan

• The diff shows code changes only; there are no explicit unit or E2E tests added, but for this small manifest-only revert, the change is straightforward and does not appear to require new automated tests. Since this is a revert PR and the body explains the cause, the test plan is acceptable.

---

⚠️ Contributors

• No contributors are listed.
• Recommendation: Optional, but if anyone helped diagnose the HL7 regression, please add them here for credit.

---

⚠️ Screenshots/Videos

• Not required; this is not a visual/UI change.
• Recommendation: None needed.

---

Summary Table

Section	Status	Recommendation
Title	✅	No change needed
Commit Type	✅	Optional: explicitly check the revert/fix category if your workflow requires it
Risk Level	⚠️	Add label risk:low
What & Why	✅	Optional: mention restored HL7 operations
Impact of Change	⚠️	Fill in brief impact bullets for clarity
Test Plan	✅	No additional tests required for this revert-style manifest change
Contributors	⚠️	Add any contributors if applicable
Screenshots/Videos	✅	Not needed

---

Passes overall. Recommended risk level is Low, which is not higher than the change suggests. Please add the risk:low label and optionally fill in the impact section for completeness.

---

Last updated: Thu, 04 Jun 2026 02:28:31 GMT

[github-actions]

📊 Coverage Check

No source files changed in this PR.

[Copilot]

Pull request overview

This PR restores HL7 operation support in the shared operation-manifest layer by reintroducing HL7 encode/decode as recognized built-in manifest types and mapping them to the HL7 built-in connector group.

Changes:

• Add hl7decode / hl7encode to the supported base manifest types list.
• Treat HL7 encode/decode as built-in operations (isBuiltInOperation) so operation info can be resolved consistently.
• Add built-in operation metadata entries mapping HL7 encode/decode to connectionProviders/hl7Operations.