I'm taking responsibility for standardizing and automating operational processes at work. Our environment is heavily based on Microsoft 365, including Entra ID, Exchange Online, SharePoint Online, and Teams, with synchronization to on-premises Active Directory. We currently have scattered scripts and limited documentation for tasks performed through graphical interfaces.
Our IT department has about 15 people. I've created an Azure DevOps repository for our scripts, but I'm trying to determine the best way for the team to run them without everyone downloading scripts and executing them locally. We also use a cloud workflow platform across the organization, and I'm considering Azure Automation as a way to receive form or workflow data for processes such as onboarding employees, handling departures, and managing Teams.
What tooling, workflow, and governance practices have worked well for other teams? I'm especially interested in how you handle source control, approvals, credentials, triggers, logging, and handoffs between systems.
4 Answers
Azure Automation, Functions, or Logic Apps triggered by webhooks from your existing workflow system are all reasonable patterns. The best choice depends on whether the job is primarily scheduled PowerShell, event-driven integration, or more involved application logic.
For straightforward administrative tasks, centrally managed runbooks are usually easier for a small team to operate than a collection of local scripts. Keep the permissions narrow, log every action, and test changes against a nonproduction scope where possible.
Azure Automation with source-control synchronization is a solid fit. We keep the runbooks in a repository, sync them into the Automation account, and run them on a schedule or manually when needed. For jobs that need access to on-premises resources, hybrid workers handle execution on internal servers.
A useful pattern is to have one runbook coordinate other runbooks. It can reschedule jobs after known transient failures or wait until a maintenance window when a dependency is available.
Azure DevOps plus Automation Accounts and runbooks gives a good balance of cost and complexity. Azure Functions running PowerShell 7 are another option when you need more flexibility, although the source-control integration has some limitations around PowerShell versions.
I’d establish operating standards before choosing the execution platform. Every automation should live in a repository, require a pull request review, use a managed identity or service account instead of personal credentials, and keep secrets in Key Vault.
Give each process an owner and backup owner. Document its trigger, inputs, outputs, rollback steps, logging, and failure alerts. Every run should write a result somewhere the team can inspect. Local execution should be reserved for documented break-glass situations.
For onboarding and offboarding, have the form create a request record first. Automations should act on that record rather than directly on an email or chat message, giving HR, help desk, and security a shared source of truth.
That makes sense. I’m less focused on picking one specific product than on designing a reliable workflow and process for building and operating the automations.
If most of your systems expose APIs, an integration platform can simplify the work. Tools such as iPaaS products or a self-hosted workflow engine can connect cloud services without requiring every process to be a custom script. The general pattern is to validate the request, call the relevant APIs, record the result, and alert someone when a step fails.
For more specialized logic, a small function app with a simple configuration interface can work well, especially when you need to connect several internal APIs.
A typical workflow starts with a structured request, validates the data, calls the destination APIs, and stores status and errors for review. Using APIs instead of manual copy-and-paste usually makes the process much easier to audit.
That’s close to what I’m trying to build. How do you pass input data into the runbook to start a job? I’m also interested in how you structure the retry and rescheduling logic.