Skip to main content
Service accounts are dedicated automation accounts that run automations independently of individual users. This guide covers how to use service accounts specifically for automations. For complete documentation on creating and managing service accounts, see Service Accounts.

​
Why Use Service Accounts for Automations

A service account provides:
  • Identity in your SCM - Automations appear as the service account in commits, PRs, and comments
  • Separation of agent and human activity - Clearly differentiate between automation work and human work
  • Consistent permissions - Automations run with predictable access regardless of individual user availability
Best practice: Run pull request and time-based automations as service accounts to ensure they continue working regardless of individual user availability.

​
When to Use Service Accounts

ScenarioRecommended Account
Event-driven automations (PR triggers)Service account
Time-based automations (scheduled jobs)Service account
Shared ownership automationsService account
Organizational processesService account
Personal workflowsYour user account
One-time tasksYour user account
Testing automationsYour user account

​
Configuring an Automation to Use a Service Account

When creating or editing an automation:
  1. In the Run as section, select the service account from the dropdown
  2. Ensure the service account has Git authentication configured
  3. Save the automation

Selecting a service account for an automation

The automation will now run using the service account’s identity and credentials.

​
Requirements

Before using a service account for automations:
  1. Create the service account - See Creating a Service Account
  2. Configure Git authentication - The service account needs a Personal Access Token for your SCM. See Git Authentication
  3. Verify permissions - Ensure the service account has access to the target repositories
  4. Check email verification policies (GitLab) - If your organization requires verified emails for commits, see Platform-Specific Considerations
GitLab users: If your organization requires verified company domain emails for Git commits, GitLab service accounts will not work. You must use a PAT from a dedicated real GitLab user account with a verified email. See GitLab Email Verification Limitation for details.

​
Troubleshooting

​
Automation Fails with Authentication Errors

  1. Verify the service account has Git authentication configured
  2. Check the Personal Access Token is still valid
  3. Ensure the token has required scopes (repo, read:user, user:email, workflow for GitHub)

​
Service Account Not Appearing in Dropdown

  1. Verify you have permissions to view service accounts
  2. Check the service account was created successfully
  3. Refresh the page

​
Permission Denied on Repository

  1. Verify the Personal Access Token has access to the target repository
  2. Check the token scopes include write permissions
  3. Ensure the service account is in a group with runner access

​
Commits Rejected Due to Email Verification (GitLab)

Symptoms: GitLab rejects pushes with errors about unverified emails, email domain policies, or commit author validation. Cause: Your organization has policies requiring verified company domain emails for all commits. GitLab service accounts cannot have verified emails, so commits from these accounts are rejected. Solution:
  1. Create a dedicated real GitLab user account with a company email (e.g., [email protected])
  2. Sign in to GitLab and verify the email address
  3. Generate a Personal Access Token from this dedicated account
  4. Update your Ona service account’s Git authentication to use this new PAT
See GitLab Email Verification Limitation for more details. For more troubleshooting guidance, see Service Accounts Troubleshooting.

​
Next Steps