I'm trying to standardize and automate more of our IT operations. We're a roughly 15-person IT team using Microsoft Entra ID, Exchange Online, SharePoint Online, Teams, and on-premises Active Directory synchronization. We have scattered scripts and a lot of undocumented GUI-based processes, so I created an Azure DevOps repository for our scripts and am now working out how the team should run them without everyone downloading scripts and executing them locally. We also use a cloud workflow platform across the organization. I'm considering Azure Automation, triggered by structured form data or webhooks, for processes such as onboarding, offboarding, and Teams management. Before building too much, I'd like to hear how other teams structure source control, approvals, triggers, credentials, scheduling, and execution for this kind of automation.
4 Answers
A practical pattern is to expose a small front end or form that sends validated data to an Azure Function, Logic App, or Azure Automation webhook. Use Functions when you need application-style code and Azure Automation for scheduled or PowerShell-oriented jobs. Tools such as Adaxes can also cover common directory tasks, while ordinary PowerShell remains useful for smaller administrative helpers.
Azure Automation with source-control synchronization and hybrid workers is a good fit. Keep the scripts in Azure DevOps or another Git repository, let changes sync into the automation account, and run them on a schedule or on demand. Hybrid workers are useful when a job needs to reach on-premises servers. You can also have a controller runbook schedule other runbooks, retry known transient failures, and send results to a central location.
Azure DevOps plus Automation Accounts and runbooks is a nice balance of cost and complexity. Azure Functions running PowerShell 7 are another option when you need more control, although the source-control integration has some limitations. Microsoft Graph and Exchange Online modules can be awkward, but they’re workable with careful testing.
The platform matters less than setting a minimum standard for every automation. Require a repository and pull-request review, use a managed identity or service account instead of personal credentials, store secrets in Key Vault, and assign an owner plus a backup owner. Each project should document its trigger, inputs, outputs, rollback plan, logging, and failure alerts. Every execution should write a result somewhere the team can inspect. For onboarding and offboarding, make the submitted form create a request record first, then have automations act on that record so there’s one shared source of truth.
For cloud-heavy environments, an integration platform such as Workato, Make, or n8n can handle much of the work through APIs. A typical workflow receives a structured request or webhook, validates the data, calls the relevant service APIs, records the result, and alerts someone when approval or manual intervention is needed. That usually scales better than relying on email, chat messages, or people manually launching scripts.
That’s close to the direction I’m considering. I’m especially interested in how you pass data into the runbooks and structure the retry or rescheduling logic.