Dataverse Modeldriven Azure Functions Llm

Dataverse Model-Driven -> Azure Functions -> LLM

Follow this workflow whenever the request is about invoking Azure Functions from Dataverse/Dynamics 365 model-driven experiences.

1) Classify invocation path first

MANDATORY: Load references/integration-patterns.md before selecting a pattern. Do NOT load it if the request is purely about security or language implementation details.

Before picking, ask:

• Is the user waiting on-screen for a result? → Interactive client path. If yes, can it complete in under 5 seconds reliably? If not, reconsider.
• Is this triggered by a Dataverse record event? → Server-side event path. Should almost always be async.
• Does it need approval, polling, or variable wait time? → Orchestrated path.

Pick one primary pattern before writing code:

• Interactive client path: model-driven form script, custom page, or PCF calls a protected API endpoint (prefer APIM + custom connector or a well-controlled direct function endpoint).
• Server-side event path: Dataverse event framework step (or Webhook or Service Bus endpoint) emits context and function app processes asynchronously.
• Orchestrated path: Power Automate or queue mediator calls function app and updates Dataverse later.

Default recommendations:

• Use asynchronous processing unless business rules require inline blocking behavior.
• Keep Dataverse synchronous operations small and deterministic.
• Put long-running LLM work outside Dataverse transaction boundaries.

2) Decide where business logic lives

Use this placement policy:

• Dataverse PreValidation: reject invalid requests early with clear errors.
• Dataverse PreOperation: mutate input fields only when transaction coupling is required.
• Dataverse PostOperation Async or outbound event: call Azure Functions for LLM workloads.
• Azure Function: external API calls, prompt assembly, response shaping, retries, and observability.

Avoid:

• Long HTTP calls from synchronous plugin stages.
• Re-entrant update loops from PostOperation updates.

3) Enforce security model before implementation

MANDATORY: Load references/security-and-secrets.md before writing any auth or secret-handling code.

Apply all of these:

• Require HTTPS only.
• Protect function endpoints with Entra or APIM policy; avoid anonymous endpoints for production.
• Store secrets in Key Vault references; never hardcode API keys in scripts, plugins, or source.
• Prefer managed identity for Azure service-to-service calls when provider supports it.
• Restrict CORS to explicit origins only; never wildcard in production.

For Power Platform custom connectors via APIM, configure origin policy for https://make.powerapps.com and set matching Origin header policy in connector.

When APIM is unavailable: use function-level API key stored as an app setting (never in source), add IP restriction rules in the function app networking settings, and document the deviation in an ADR noting the accepted exposure increase. Revisit when APIM is available.

4) Language-specific implementation rules

C# function apps

MANDATORY: Load references/csharp-isolated-patterns.md and sample_codes/csharp/ before writing C# implementation code. Do NOT load references/typescript-v4-patterns.md.

Use .NET isolated worker model for new work.

• Configure dependency injection in Program.cs.
• Use IHttpClientFactory or typed clients for outbound calls.
• Add explicit request timeout, retry, and cancellation token handling.
• Emit structured logs with correlation IDs from Dataverse context.
• Validate all incoming payloads before LLM call.

TypeScript function apps

MANDATORY: Load references/typescript-v4-patterns.md and sample_codes/typescript/ before writing TypeScript implementation code. Do NOT load references/csharp-isolated-patterns.md.

Use Node.js v4 programming model.

• Register functions in code with app.http(...).
• Use async and await everywhere.
• Keep shared clients in module scope (no per-request construction).
• Validate request schema and size limits up front.
• Return explicit status codes and machine-readable error bodies.

5) LLM request design guardrails

Implement these minimum controls:

• Idempotency key from Dataverse operation or record version.
• Token and payload size limits.
• Prompt and response logging with sensitive field redaction.
• Retry policy only for transient classes; never blind retry on 4xx.
• Circuit-breaker or fallback behavior when provider latency spikes.

6) Anti-pattern checks (always run)

Reject or refactor if any are present:

• API keys in client-side JavaScript or Dataverse table fields without secret controls.
• Synchronous plugin waiting on LLM response.
• Wildcard CORS and anonymous function auth for business endpoints.
• C# in-process model for net-new function projects.
• Mixing Node v3 and v4 function models in one app.
• No timeout, no correlation IDs, or no retry/backoff discipline.

7) Output contract for user responses

When asked to design or implement, produce:

• Architecture decision: invocation path and rationale.
• Security posture: authN/authZ, secret flow, and CORS boundaries.
• C# and TypeScript implementation guidance (both if requested).
• Failure-mode plan: retries, dead-letter strategy, and user-visible behavior.
• Test list: unit, integration, and failure injection scenarios.

Reference files

Load conditionally — do not load all files at once:

| Situation | Load | Do NOT load | |---|---|---| | Selecting invocation path (step 1) | references/integration-patterns.md | Language refs until step 4 | | Any security or secret handling (step 3) | references/security-and-secrets.md | — | | C# implementation (step 4) | references/csharp-isolated-patterns.md, sample_codes/csharp/ | references/typescript-v4-patterns.md | | TypeScript implementation (step 4) | references/typescript-v4-patterns.md, sample_codes/typescript/ | references/csharp-isolated-patterns.md | | Anti-pattern review (step 6) | references/anti-patterns.md | — | | Navigating available references | references/source-map.md | — |

Sample code

Use as starting points only:

• sample_codes/csharp/llm-proxy-function.cs
• sample_codes/typescript/llmProxyFunction.ts

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: RyanMakesAndBreaksStuff
• Source: RyanMakesAndBreaksStuff/Custom-Codex-Claude-Plugins-and-Skills
• License: MIT

Install and usage instructions live in the source repository linked above.