Overview

This document provides comprehensive, deterministic design rules for Azure Logic Apps Standard enterprise integrations, prioritizing production-readiness, review-safety, and operational observability through explicit thresholds, mandatory patterns, and automated quality gates.

Design Philosophy

Deterministic Decision-Making

Clear, binary evaluation criteria for architectural choices with mandatory justification for exceptions.

Production-Readiness by Default

Security, reliability, and observability built-in from the start, not as afterthoughts.

Review-Safe Architecture

Explicit documentation of decisions, trust boundaries, and data flows for efficient review cycles.

Operational Observability

Comprehensive telemetry with actionable alerts and quantified SLOs for proactive operations.

Design Philosophy & Quality Attributes

Core Principles

Deterministic Decision-Making

Eliminates ambiguity from architectural choices by establishing clear, binary evaluation criteria for every significant design decision. When developers encounter integration scenarios, they must be able to apply predefined rules that yield consistent, predictable outcomes regardless of who makes the decision or when it is made.

Example: Stateless vs Stateful Decision Matrix

Use Stateless only if ALL conditions are met:

  • • Execution time < 5 seconds
  • • Payload size < 64KB
  • • No external waiting
  • • No compensation logic

Otherwise, use Stateful (recommended default) Jump to section

Production-Readiness by Default

Every design decision, code pattern, and configuration choice must satisfy enterprise production requirements without additional retrofitting. Security controls, reliability mechanisms, observability instrumentation, and operational procedures are intrinsic to the initial implementation rather than afterthought additions.

Non-Negotiable Requirements
  • • Managed Identity for all connectors #
  • • Private endpoints for sensitive resources #
  • • Structured logging with explicit field allowlists #
  • • Comprehensive retry policies with exponential backoff #

Output Quality Standards

Deployment-Ready Deliverables

  • Environment-agnostic artifacts with externalized configuration
  • Explicit rollback provisions with blue/green or staged strategies
  • Version tagging for precise artifact identification

Testable Components

  • Local execution capability with mocked dependencies
  • 80% minimum branch coverage requirement
  • 11 mandatory test scenarios covering failure modes #

Global Architectural Decision Rules

Loose Coupling Default Pattern

Async Messaging Triggers (Mandatory When)

Latency > 300ms

Beyond user-perceived responsiveness boundary

Unreliable Dependency

Prevents cascading failures

Burst Traffic Expected

Enables elastic capacity

Synchronous HTTP Exceptions (All Conditions Required)

  • • Explicit business requirement for blocking behavior
  • • End-to-end latency < 500ms (validated through empirical measurement)
  • • Downstream SLA validated and reliable Ref

Workflow Decomposition Mandate

Required Workflow Types

Ingress Workflow

Request reception, validation, command publication

Command Handler

Business logic, downstream integration

Egress/Publisher

Result distribution, notification

DLQ Reprocessor

Failure analysis, selective retry

Monolith Prohibition

No monolith workflows allowed unless explicitly justified and approved through architectural review.

  • • Explicit justification required
  • • Architectural review gate
  • • Documented exception approval

Security Enforcement Rules

Identity and Secrets Management

Managed Identity Mandate

Required For
  • • All Logic Apps connectors
  • • Key Vault access
  • • Resource-to-resource communication
Prohibited
  • • Connection strings in workflow.json
  • • Secrets in app settings
  • • Hardcoded credentials
RBAC Documentation Requirements

Follow least privilege principle with explicit permission mapping:

  • • Document business justification for each permission
  • • Regular review and cleanup of unused permissions
  • • Avoid broad roles like Contributor/Owner

Ingress Security Controls

API Management Placement

Mandatory for all public HTTP ingress – never expose Logic Apps runtime directly

OAuth2/JWT Validation

Enforce token validation with signature verification, expiration checking, and issuer trust

Rate Limiting

Numeric specification required with burst allowances for legitimate traffic patterns

Request Size Limits

Explicit limits with claim-check pattern for larger payloads

Network Security Architecture

Private Endpoint Mandates

Service Bus

Message traffic on private network paths

Key Vault

Secret access protection from network interception

Storage

Claim-check pattern data transfer on private networks

Logging Restrictions

🚫 Prohibited Content

  • • Raw payloads (may contain PII/sensitive data)
  • • Secrets (passwords, tokens, keys)
  • • Authentication tokens or session identifiers

✅ Permitted Fields

correlationId tracing
causationId event sourcing
messageId deduplication
businessKey operational queries
integrationStep flow tracking
status outcome
dependencyName mapping
latencyMs performance

Naming Conventions

Azure Resource Naming

Pattern Structure

<abbr>-<org>-<domain>-<capability>-<env>-<region>-<nn>
abbr

Service type

logic, sb, kv

org

Business unit

corp, fin, hr

domain

System boundary

orders, payments

capability

Function

ingest, process

Abbreviation Standards

Core Services
  • logic Logic App
  • sb Service Bus
  • kv Key Vault
  • st Storage
Monitoring
  • ai Application Insights
  • apim API Management
Infrastructure
  • rg Resource Group

Workflow Naming

Pattern: wf_<domain>_<capability>_<verb>

wf_orders_ingest_receive
domain

Business domain from resource naming

capability

Function within domain

verb

Action orientation

Examples
wf_orders_ingest_receive
wf_payments_validate_process
wf_inventory_update_notify

Action Naming

Pattern: <Prefix>_<MeaningfulName>

Common Prefixes
Validate_ Schema validation
Transform_ Data conversion
Get_ Retrieval operations
Upsert_ Create/update
Publish_ Event publication
Examples
Validate_OrderSchema
Transform_ToCanonical
Get_CustomerDetails
Upsert_OrderRecord
Publish_OrderCreated

Connection Naming

Pattern: conn_<service>_<purpose>_<env>

conn_servicebus_commands_prod
service

Target service type

servicebus, keyvault, sql

purpose

Usage context

commands, events, secrets

env

Environment

dev, test, prod

Reliability Engineering Rules

Retry Policy Specification (Mandatory)

Configuration Parameters

Retry count 5
Backoff type Exponential
Initial interval 5 seconds
Maximum interval 60 seconds

Transient Errors (Retry)

429
Too Many Requests
500
Internal Server Error
502
Bad Gateway
503
Service Unavailable
504
Gateway Timeout
timeout
Request timeout

Non-Transient Errors (No Retry)

400
Bad Request
401
Unauthorized
403
Forbidden
404
Not Found
422
Unprocessable Entity

409 Conflict is non-transient unless explicitly defined as retryable Ref

Dead Letter Queue Management

Message Enrichment Requirements

reasonCode property Mandatory inclusion
Deterministic taxonomy Standardized values

Reason Code Taxonomy

Validation Failures
SCHEMA_INVALID Missing required field
TRANSFORM_ERROR Mapping not found
BUSINESS_RULE_VIOLATION Order amount exceeds limit
System Failures
DOWNSTREAM_TIMEOUT Payment service unresponsive
DOWNSTREAM_ERROR HTTP 500 from dependency
IDEMPOTENCY_CONFLICT Duplicate processing detected

Idempotency Implementation

Deduplication Store

Mandatory persistent storage (Cosmos DB, Table Storage, or SQL)

Explicit Key Formula

Documented formula ensuring consistent key generation

Single Execution

All external state changes conditional on deduplication check

Observability Requirements

Telemetry Emission Standards

Structured Logging

  • JSON-formatted with consistent schema
  • Tracked properties limited to minimal allowlist
  • Dependency telemetry with target, latency, outcome

Metric Emission

  • Latency metrics with percentile distributions
  • Workflow and action granularity
  • Success rate and throughput tracking

Required KQL Queries

Mandatory Monitoring Scenarios

DLQ growth detection

Identify accumulating unprocessed messages

429 spike identification

Detect rate limiting patterns

Retry exhaustion monitoring

Messages approaching retry limits

Average latency calculation

Track performance trends and SLO compliance

Backlog depth measurement

Monitor queue-based load for scaling decisions

Alerting Framework

1

Sev1 (Critical)

Complete service stop, data loss risk

Response: 15 minutes
2

Sev2 (High)

Significant degradation, workaround available

Response: 1 hour
3

Sev3 (Medium)

Anomaly requiring investigation

Response: 4 hours

Numeric Threshold Specification Required

All alerts must include quantified triggers with clear pass/fail conditions. Qualitative assessments are insufficient for automated response. #

SLO/SLI Definition

Service Level Indicators & Objectives

Success Rate

Completed executions / total executions

99.9%
Target
Latency

P95 < 2s (sync), < 30s end-to-end (async)

2s / 30s
Target
Backlog Age

99% processed within 5 minutes

5 min
Target
DLQ Count

< 0.1% of messages

0.1%
Max

Contract & Schema Governance

Inbound Schema Enforcement

❌ Rejection Criteria

  • Messages failing JSON schema validation
  • Unknown schemaVersion values
  • Breaking changes without version bump

✅ Versioning Requirements

  • Parallel processing of v1, v2, etc.
  • 6-month minimum version overlap
  • Additive changes only for backward compatibility

Mandatory Envelope Schema

JSON Schema

{
  "correlationId": "GUID",
  "causationId": "GUID",
  "messageId": "GUID",
  "schemaVersion": "v1",
  "eventType": "string",
  "producer": "string",
  "timestampUtc": "ISO8601",
  "businessKey": "string"
}

Field Documentation

correlationId End-to-end tracing
causationId Event lineage
messageId Unique identification
businessKey Business transaction

Contract Testing

CI-Integrated Validation

Automated schema validation on every build with pipeline integration

Version Bump Requirement

Breaking changes must increment major version with explicit approval

Build Failure Enforcement

Pipeline rejection of incompatible schema changes without explicit override

Performance & Cost Optimization

Payload Management

Claim-Check Pattern Trigger

Payload size > 128KB requires Blob Storage with message reference

Cost Estimation Formula

Action Count × Executions × Connector Pricing

Enables scenario-based cost modeling and optimization identification

Concurrency Controls

Workflow Concurrency

Limits simultaneous workflow instances to prevent resource exhaustion

Default: 10-100 depending on complexity

Maximum Parallelism

Controls concurrent action execution within workflows

Configure based on downstream capacity

Action Optimization Guidelines

Avoid

  • • Large inline Compose actions
  • • Excessive trackedProperties
  • • Unbounded loops or recursion

Recommended

  • • Externalize configuration to storage
  • • Limit trackedProperties to operational necessity
  • • Use batch operations where possible

DevOps and Deployment Standards

Infrastructure as Code

  • • Bicep or Terraform required
  • • Environment parameter externalization
  • • No hardcoded environment values
  • • Resource dependency management

Deployment Strategy

Blue/Green

Parallel environments with instant traffic switching

Staged Rollout

Gradual exposure with automated rollback triggers

Rollback Strategy

Documented, tested procedure for rapid recovery

Version Control

  • • Semantic versioning required
  • • Version tagging for all deployments
  • • Traceability to source commits
  • • Release documentation standards

Key Requirements

Prohibited Practices

  • • Environment values in workflow.json
  • • Manual resource creation without IaC
  • • Deployment without rollback strategy

Mandatory Practices

  • • Environment parameter externalization
  • • Infrastructure dependency validation
  • • Version tagging and documentation

Testing and Quality Assurance

Test Execution Requirements

  • Local execution capability without pipeline dependency
  • CI pipeline integration with automated execution
  • External dependency mocking for isolated testing
  • JUnit/TRX output format for build system integration

Coverage Standards

Branch Coverage

Minimum requirement

80%
Test Pass Rate

Required for deployment

100%

Mandatory Test Scenarios

The following 11 scenarios must be covered by unit tests to validate production readiness:

Input Validation

Invalid JSON handling
Schema mismatch detection
Duplicate messageId processing

Failure Scenarios

Retry scenario validation
Non-retry scenario validation
DLQ routing verification

Data Handling

Claim-check path testing
Correlation propagation
Redaction enforcement

Operational Concerns

Concurrency behavior

CI Quality Gates

Build Failure Conditions

The CI pipeline must fail if any of the following conditions are detected:

Missing Parse JSON on ingress
Missing Try/Catch/Finally structure
Missing idempotency step
Inline secret detected
Managed Identity not used
Retry policy missing

Deliverable Structure

Mandatory Output Sequence

Every integration implementation must be documented following this exact sequence to ensure consistent review and operational handover.

A
Assumptions Documented context and rationale
B
Architecture Overview High-level solution description
C
Component Inventory Table Asset management listing
D
Workflow Inventory Table Operational navigation catalog
E
Naming Plan Applied naming conventions
F
Security Plan RBAC, network, and secrets
G
Reliability Plan Retry, DLQ, and idempotency
H
Observability Plan Logging, metrics, and alerting
I
Implementation Blueprint Detailed workflow design
J
Anti-Pattern Checklist ≥25 verified exclusions
K
Unit Testing Plan Test strategy and coverage

Project Initiation Requirements

Required Input Information

The following 11 information items must be provided or explicitly assumed before proceeding with design. Missing information requires documentation in Section A (Assumptions).

Business goal Justification and success criteria
Trigger source(s) Integration boundary definition
Downstream systems Dependency identification
Latency requirement Architecture pattern selection
Expected volume Capacity planning
Payload size (typical/max) Storage and processing optimization
PII involvement Security and compliance requirements
Networking constraints Connectivity architecture
Environment specifications Deployment planning
Conformance standards Regulatory and policy compliance

Missing Information Protocol

1
Minimal Assumption Listing

Document minimum necessary assumptions for deterministic design

2
Section A Documentation

Capture all assumptions in mandatory deliverable section with explicit rationale