{"meta":{"title":"Automations in your enterprise","intro":"Learn how GitHub Apps, external services, and GitHub Actions work together to automate processes in your enterprise.","product":"Enterprise administrators","breadcrumbs":[{"href":"/en/enterprise-server@3.22/admin","title":"Enterprise administrators"},{"href":"/en/enterprise-server@3.22/admin/concepts","title":"Concepts"},{"href":"/en/enterprise-server@3.22/admin/concepts/enterprise-fundamentals","title":"Fundamentals"},{"href":"/en/enterprise-server@3.22/admin/concepts/enterprise-fundamentals/automations-in-your-enterprise","title":"Automations"}],"documentType":"article"},"body":"# Automations in your enterprise\n\nLearn how GitHub Apps, external services, and GitHub Actions work together to automate processes in your enterprise.\n\nAutomation on GitHub typically involves multiple components working together. The most important GitHub native components are:\n\n* **GitHub Actions workflows**, which provide a runtime for executing automation logic. Out of the box, they work within a single repository, but they can be extended to automate across or even outside of repositories.\n* **GitHub Apps**, which do not have a runtime. Instead, they provide identity, permissions, and event delivery so your automations, whether external services or workflows, can authenticate and act securely.\n\nMost enterprise automation use GitHub Apps and GitHub Actions together. For example, a workflow running in GitHub Actions may use a GitHub App to obtain a short-lived token that allows it to perform tasks across repositories or organizations.\n\nThis guide explains how GitHub Apps, external automations, and GitHub Actions complement each other, and when to use each in your enterprise.\n\n## GitHub Apps\n\nA GitHub App provides the **identity, permissions, and webhook events** required for automation on or across repositories, organizations, or your enterprise. GitHub Apps themselves do **not** execute logic, they enable other systems to do so.\n\nGitHub Apps support enterprise automation by offering:\n\n* **Granular permissions** to follow least-privilege principles\n* **Scoped installations** at the enterprise, organization, or repository level\n* **Short-lived tokens** for secure access\n* **Distinct identities** with full auditability\n* **Delegated administration** through the GitHub App manager role\n* **Consistency at scale** when owned by the enterprise account\n\n### What do GitHub Apps enable?\n\nGitHub Apps allow **automations you write elsewhere**—such as external services or workflow steps—to act on GitHub APIs within the permissions you grant. For example:\n\n* Receiving webhook events and triggering external services\n* Enabling a workflow to act outside its default repository scope\n* Integrating GitHub with third-party systems\n* Coordinating changes across many repositories\n* Running long-lived bots or services that monitor enterprise-level activity\n\n> \\[!NOTE]\n> Enterprise-installed GitHub Apps cannot call every API endpoint. See [Installing a GitHub App on your enterprise](/en/enterprise-server@3.22/apps/using-github-apps/installing-a-github-app-on-your-enterprise#what-enterprise-installed-apps-can-do).\n\n## GitHub Actions\n\nGitHub Actions provide GitHub’s built-in **runtime** for executing automation logic inside repositories. Workflows run on self-hosted runners and are ideal for tasks tied to code changes or repository events.\n\nUse GitHub Actions for:\n\n* CI/CD (build, test, deploy)\n* Pull request checks and validations\n* Repository-level maintenance tasks\n* Event-driven workflows responding to pushes, tags, or issue updates\n* Scheduled jobs with cron\n\n### How GitHub Actions uses GitHub Apps\n\nGitHub Actions and GitHub Apps are deeply connected:\n\n* Workflow permissions map directly to GitHub App permissions.\n* Workflows can authenticate as a specific GitHub App using `actions/create-github-app-token`.\n* GitHub Apps can trigger workflows through events such as `repository_dispatch`.\n\n## External automations and services\n\nExternal automations run outside GitHub on your own infrastructure. These services typically:\n\n* Receive webhook events from a GitHub App\n* Use the GitHub App to request short-lived installation tokens\n* Execute long-running or cross-enterprise logic\n* Integrate with external business systems\n\nExamples include:\n\n* Organization-wide configuration management\n* Policy enforcement services\n* Multi-repository code or metadata synchronization\n* Compliance report generation\n* Cross-organization issue or pull request management\n\nAll of these rely on GitHub Apps for authentication, identity, and events—**not** for execution.\n\n## How these components work together\n\nMost enterprise automation uses a combination of GitHub Apps, external services, and GitHub Actions to achieve robust, scalable workflows.\n\nFor example:\n\n1. An enterprise GitHub App receives a webhook when a new repository is created, and sends the webhook payload to a server where an external service is running.\n2. The external service standardizes required settings and provisions resources.\n3. The service triggers a GitHub Actions workflow in the repository.\n4. The workflow performs CI, deploys templates, or configures scanning.\n\nEach component handles a different layer of automation.\n\n## When to use each type of automation\n\nUse **a GitHub App** when you need:\n\n* Authentication or permission to act across many repositories\n* Integration with external systems\n* Webhook-driven automations\n* Long-lived or enterprise-wide workflows\n* Auditability and identity separation\n\nUse **external automations** when you need:\n\n* Logic that runs continuously or outside GitHub\n* Integration with internal systems\n\nUse **GitHub Actions** when you need:\n\n* CI/CD pipelines\n* Repository-scoped automation\n* Automated checks tied to repository events\n* Execution of logic using GitHub’s runner infrastructure\n\nUse **GitHub Apps and GitHub Actions together** when:\n\n* A workflow must act beyond the repository’s default permissions\n* A GitHub App needs to trigger a workflow\n* External logic orchestrates in-repo execution\n* Enterprise-wide policies or workflows require both identity and runtime"}