Introducing the Logic Apps local CLI: develop Standard workflows from your terminal
We're introducing the public preview of the Logic Apps Standard extension for the Azure command-line interface (CLI). It brings local project creation, connector discovery, connection configuration, runtime management, and execution diagnostics into az logicapp . Why a CLI for Logic Apps Standard? The designer remains useful for understanding and editing workflows visually. The CLI gives you another interface to the development work around that workflow: checking dependencies, discovering operations, validating definitions, starting the local host, and inspecting runs without switching tools at every step. You can use those commands yourself, put them in a script, or let a coding agent invoke them with your approval. Existing Azure CLI app-management and app-settings commands remain a separate part of the same CLI surface. This extension adds Standard developer workflows; it doesn't replace the designer or reinterpret existing resource-management commands. Your coding agent needs more than workflow JSON A coding agent can propose a plausible connector action. Plausible isn't authoritative. The operation identifier, required inputs, and authentication parameters need to come from the connector catalog for your target, not from the agent's recollection of a similar example. That's where deterministic tools matter. The CLI gives the agent a defined operation to execute and evidence to inspect: discover the connector, read its operation schema, author the workflow, validate it, then examine execution results. It reduces guesswork and avoids making the agent reconstruct platform calls it doesn't have available by default. The CLI doesn't make the agent's decisions deterministic, and a successful command doesn't prove your business process is correct. You still review the workflow and its effects. But now that review is grounded on the same type of information the extension and runtime's have. Install the public preview The preview package is logicapp version 1.0.0b1 . It declares Azure CLI 2.67.0 or later and Python 3.10 or later for the interpreter hosting Azure CLI. Install it through the public Azure CLI extension mechanism: az extension add --name logicapp --allow-preview true az extension show --name logicapp --query version --output tsv az logicapp --help For later releases, use az extension update --name logicapp --allow-preview true . Local runtime dependencies are separate from extension installation. What can you do with the extension? The preview registers 59 extension-owned commands. Every group below follows az logicapp ; inherited core commands aren't included. Group Commands Purpose project create Scaffold a local Standard project. context create, use, list, show, update, delete Save target coordinates. workflow create, validate, list, show, export, set, delete, enable, disable Author, inspect, and manage workflows. dependency check, install, uninstall Manage supported local tools. runtime doctor, start, show, stop Diagnose and operate local hosts. connector , connector operation list, show in each Discover runtime connectors and operations. connector managed , connector managed operation list, show in each Discover regional managed APIs. connection create, list, show, test, delete Create local service-provider wiring; inspect and manage deployed connections. connection managed create Create, authorize, and wire a deployed managed connection. connection acl list, show, add, remove Manage connection access policies. identity assign, show, remove Manage deployed app identities. run start, list, show, wait, cancel, resubmit Invoke, observe, and control supported executions. run action list, show, show-content Inspect action results. trigger history resubmit Replay an exact retained trigger event. deployment package Build a deterministic ZIP. test create, plan, run Scaffold, plan, and execute tests, with limitations described below. test results show Inspect test results. Walkthrough: save email attachments to Blob Storage Use Office 365 Outlook as the managed connector and Azure Blob Storage as the in-process service-provider connector. The workflow runs on your workstation; the mailbox, managed connection, and storage account remain in Azure and Microsoft 365. Local doesn't mean offline. Use a test mailbox, a storage container, and an existing non-production Standard app with an assigned identity and valid connections.json . You need permissions for connection creation, consent, access policies, and storage data access. The PowerShell examples use placeholders: replace them before execution. Don't run them against production. 1. Create the project and check the environment From a new solution directory, keep the host under app and create a sibling artifacts folder for exports and packages. az logicapp project create --path .\app --workflow save-attachments --workflow-kind Stateful az logicapp context create --name attachments-local --path .\app --port 7071 --use az logicapp dependency check --path .\app az logicapp runtime doctor --path .\app --port 7071 Install only missing supported tools with dependency install --kind <kind> . The command doesn't install the .NET SDK. Read the doctor's findings: exit code 2 can mean compatibility is unknown, not that everything needs reinstalling. Contexts save coordinates, not your Azure subscription or credentials. 2. Discover both connector catalogs Use az login and check az account show before querying the Azure catalog. These are standard Azure CLI commands. az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90 az logicapp runtime show --port 7071 az logicapp connector list --local --port 7071 az logicapp connector show --local --port 7071 --connector "<blob-connector-id>" az logicapp connector operation list --local --port 7071 --connector "<blob-connector-id>" --search "upload" az logicapp connector managed show --location "<region>" --connector office365 az logicapp connector managed operation list --location "<region>" --connector office365 --kind trigger az logicapp connector managed operation show --location "<region>" --connector office365 --operation OnNewEmailV3 az logicapp connector operation show --local --port 7071 --connector "<blob-connector-id>" --operation uploadBlob Take the Blob connector identifier from connector list . Runtime catalogs describe the service provider; the regional managed catalog describes Outlook. They aren't interchangeable. Use each family's operation show command to inspect the selected operation before authoring it. This is a useful agent task: "Read both connector schemas. Identify an email trigger, attachment retrieval, and Blob upload. Show me the required inputs and authentication before changing the workflow." The Outlook reference documents attachment retrieval through GetAttachment_V2 ; the Blob service-provider reference documents uploadBlob . 3. Create Outlook access, then wire the local project Stop the discovery host with az logicapp runtime stop --port 7071 before changing settings. Then create the managed connection: az logicapp connection managed create --resource-group "<group>" --logic-app-name "<nonproduction-app>" --name outlook-local --connector office365 --location "<region>" --auth-mode oauth az ad signed-in-user show --query id --output tsv az logicapp connection acl add --resource-group "<group>" --connection outlook-local --object-id "<developer-object-id>" --tenant-id "<tenant-id>" Approve mailbox consent in the browser. Creation also adds the app's access policy and changes the deployed app's connection wiring. The additional policy authorizes your local developer principal. These are real Azure changes, even though the example workflow stays local. Failed creation can retain resources; inspect them and the wiring before retrying. The CLI doesn't write local managed-connector wiring. Read the created entry with connection show against that app and deliberately use --show-runtime-urls for this setup step. Manually merge its API identifier, connection identifier, runtime endpoint, and ManagedServiceIdentity authentication into the local managedApiConnections.outlook-local entry. Keep the runtime endpoint in a private app setting, referenced with @appsetting('OUTLOOK_RUNTIME_URL') ; don't paste returned URLs into the post or shared logs. The documented local identity feature requires the Standard VS Code extension 5.961.19 or later and workflow bundle 1.165.52 or later. Merge this value into both the project's local.settings.json and its workflow-designtime\local.settings.json , preserving existing settings: "WORKFLOWS_AUTHENTICATION_METHOD": "managedServiceIdentity" After completing the connection configuration, start the local runtime as shown in step 5 so it loads the updated settings. Make sure the local runtime authenticates as the developer identity you granted access to the managed connection. 4. Configure Blob access without an account key Read the service provider's managed-identity parameter set and endpoint parameter from discovery. Don't reuse the managed Blob connector's parameter-set name. Substitute those discovered values in this local wiring command: az logicapp connection create --path .\app --name blob-local --connector "<blob-connector-id>" --parameter-set "<discovered-identity-set>" --% --parameter "<endpoint-parameter>=@appsetting('BLOB_ENDPOINT')" authProvider.Type=ManagedServiceIdentity --app-setting BLOB_ENDPOINT=https://<storage-account>.blob.core.windows.net Keep this PowerShell command on one line. The --% marker preserves the app-setting expression through az.cmd ; variables don't expand after it. Review the discovered identity fields before using the command. Grant the local developer Storage Blob Data Contributor at the intended container scope, using your approved Azure role-assignment process. In Azure, grant the app's managed identity its own required access. A workstation doesn't impersonate that identity, and assigning an identity to an app doesn't grant storage permissions. 5. Author and validate the workflow Replace the scaffold's starter definition with Outlook's polling When a new email arrives (V3) trigger, OnNewEmailV3 , an attachment loop, GetAttachment_V2 , and the Blob upload action. Configure the trigger's recurrence and message splitting from its schema. Bind Outlook operations to outlook-local and Blob operations to blob-local . Set includeAttachments to false and retrieve attachments separately. Map each message and attachment identifier explicitly. For uploadBlob , supply containerName , blobName , and content . Decode Outlook's base64 contentBytes before writing binary content; use a unique blob name so repeated filenames don't overwrite unrelated attachments. These are workflow-authoring decisions, not generated business logic from the CLI. For an attachment action named Get_attachment , the upload content expression is @base64ToBinary(body('Get_attachment')?['contentBytes']) . Match action names to your authored definition. Validate offline, restart with the new settings, then validate against that host: az logicapp workflow validate --path .\app --workflow save-attachments az logicapp runtime start --path .\app --port 7071 --background --ready-timeout 90 az logicapp runtime show --port 7071 az logicapp workflow validate --path .\app --all --with-runtime --local --port 7071 Check that the host is running, readiness.managementEndpointReachable is true, and the workflow is registered. Validation doesn't establish connector authorization or business correctness. Static reference warnings can remain after runtime validation and block --fail-on-warning ; don't remove configuration references to manufacture a pass. 6. Send a test email and inspect the run Send a synthetic email with one harmless attachment. Identify the matching execution by timing and message correlation, not by assuming the newest run is yours. az logicapp run list --local --port 7071 --workflow save-attachments --max-items 10 --query "value[].{runId:runId,status:status,startTime:startTime}" --output table az logicapp run wait --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --timeout 300 az logicapp run action list --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" az logicapp run action show-content --local --port 7071 --workflow save-attachments --run-id "<actual-run-id>" --action "<actual-action-name>" --max-bytes 16384 For Stateful runs, run wait exits 0 only after observing success. Its timeout doesn't cancel execution. If outputs are absent, use run action show for failure metadata. Bounded content can still contain private data. Verify the saved blob's bytes independently; a green status isn't an attachment-integrity check. 7. Stop and package az logicapp runtime stop --port 7071 az logicapp deployment package --path .\app --output-path .\artifacts\attachments.zip Verify shutdown, including unshared CLI-owned Azurite processes. Review the package manifest and ZIP: exclude local settings, design-time files, editor content, reports, and private fixtures through .funcignore . Don't confuse it with .gitignore . Packaging is deterministic archive creation, not validation, deployment, or a guarantee that no secrets exist. Add the Logic Apps skill to GitHub Copilot The azure-logic-apps-standard-cli skill is now available on Awesome Copilot. It gives Copilot procedures for using the CLI: inspect the project first, discover connector schemas, preserve existing layouts, prefer managed identity for new connections, and distinguish validation from actual execution. It covers Logic Apps Standard, not Consumption-only development. Install the complete skill package With GitHub CLI 2.90.0 or later, preview the skill and review its bundled references before installing. The following commands install it for your personal Copilot use across projects: gh skill preview github/awesome-copilot azure-logic-apps-standard-cli gh skill install github/awesome-copilot azure-logic-apps-standard-cli --agent github-copilot --scope user For a repository-specific installation, run the install command from that repository with --scope project instead. The installer places the package in the appropriate skills directory. Alternatively, download the complete skill folder and place it under .github\skills in your repository or .copilot\skills in your home directory. Keep SKILL.md , README.md , and all five references files together; copying only SKILL.md leaves required procedures unavailable. The skill is guidance, not the Azure CLI extension or a runtime installer. Install the extension separately as described above; runtime and test dependencies still need their own checks and approval. Use it in Copilot CLI Start copilot from your project directory. If a session is already open, reload skills, then check that the package is available: /skills reload /skills info azure-logic-apps-standard-cli Copilot can select relevant skills automatically. To request this one explicitly, name it in your prompt: Use the /azure-logic-apps-standard-cli skill to inspect this existing Standard project and validate its workflows offline. Preserve its layout, workflow kinds, and authentication. Do not start a host, install dependencies, or access Azure. Report any checks you cannot complete. To approach the attachment walkthrough with Copilot, begin with a plan rather than authorizing every operation at once: Use the /azure-logic-apps-standard-cli skill to plan an Outlook-to-Blob workflow for this project. Identify the connector discovery steps, authentication requirements, and permissions needed. Separate offline work from host startup and Azure changes, and wait for approval before those operations. Review proposed commands and their effects before approving them. The skill requires operation-specific bundled procedures and explicit authorization for cloud changes, replay, and native-test prerequisites; it doesn't replace Copilot's permission controls or prove that a workflow works. See GitHub's Copilot CLI skills guide for installation and usage details. Beyond this walkthrough Use workflow list/show/export against a running host to inspect or save a definition. Against Azure, connection list/show/test , connection acl list , and identity show expose wiring and access. A connection with no available test remains unverified. For compatible callable triggers, run start invokes a workflow; it doesn't manufacture an incoming Outlook email. Cancellation and replay are explicit operations with external effects. Guarded workflow replacement and state changes also need deliberate approval; they aren't transactional shortcuts. Before you build: preview realities and what comes next Commands and outputs can change during preview. Testing commands already provide scaffolding, planning, approved SDK execution, and result inspection, but the current SDK/engine combination has a reported typed-output limitation. They aren't part of this walkthrough. Proposed improvements include testing, local connection inspection, trigger/history discovery, and managed-connection deployment export. These are areas of work, not delivery commitments or commands you can use today. Try it with a workflow you know Take a non-production workflow and ask your coding agent to discover its connectors before editing it. Compare the proposal with the catalog, then inspect the actual execution. If a command is missing or the results don't help you diagnose a failure, tell us which step broke and what you needed instead. Giving us feedback early will help us getting the features ready to you faster!
