Privacy Policy for the Azure DevOps Extension – "Automations"
Effective Date: September 3, 2026
Last Updated: 15 October 2026
Thank you for using the "Automations" extension for Azure DevOps (the "Extension"). This Privacy Policy describes how data is handled and protected when you use the Extension and the Documentero hosted services that run your automations (together, the "Service"). It applies only to the Automations Extension; other Documentero products have their own policies. The Extension is currently offered in Preview and free of charge.
An organization uses one identity at a time. A Project Collection Administrator completes either Setup Automation User or Connect an Entra app, and must Disconnect before choosing the other setup. A contact email is required before either setup starts. Automations let your team define a trigger (an Azure DevOps work item event, a pipeline run or stage event, or a schedule), optional conditions, and a chain of actions (for example: create or update work items, add comments, copy fields, update tags, run a shared query, queue a pipeline, load work items linked to a pipeline run, or send a customized email). When an event or schedule matches, our hosted backend runs those actions in your Azure DevOps organization as the identity chosen for that organization (the "Automation Identity"), not as the person who later edits the automation.
Run state changed matches a pipeline run in the project when it starts, is canceling, or finishes. The customer can match every pipeline in that project or only selected ones, and can filter by state, result, and branch. YAML and classic builds both match. A finished run starts the automation once. Stage state changed matches one pipeline, one stage or any stage, with optional state, result, and branch filters. It is for YAML pipelines that have stages. Classic designer builds have no stages and use Run state changed instead. Service hooks for these events are created and removed automatically when the automation is enabled or disabled, the same way work-item hooks are. Delivery of a pipeline event is not guaranteed.
Run pipeline queues an existing Azure DevOps pipeline and continues without waiting for that run to finish. YAML and classic builds both work. The customer can set a branch and template parameters. The repository stays the one already saved on that pipeline. Queuing the same pipeline that triggered the current run is refused. Get pipeline work items loads the work items shown as related on that run. If that list is empty, it reads the work items linked to the run's changes through the Azure DevOps build API. It does not read the code repository, commits, or pull requests. Work items in another project are left out. If those changes are not ready and the run is still in progress, the step waits until the run finishes, for at most 6 hours. Later steps can update, comment, or tag the loaded work items. Comments and emails can insert fields from the triggering run: pipeline name, run id, result, state, run URL, branch, stage name, and stage result. Queuing a pipeline whose source is GitHub, Bitbucket, or another host still happens inside Azure DevOps. Checkout uses the service connection already saved on that pipeline. The Service does not authorize itself to GitHub or Bitbucket, does not start GitHub Actions or Bitbucket Pipelines, and does not store a repository URL, service-connection secret, or personal access token.
Setup Automation User. A Project Collection Administrator sets the contact email, then a work or school account signs in with Microsoft. The Azure DevOps organization does not need to be connected to Microsoft Entra ID. Microsoft personal accounts cannot authorize Azure DevOps and are not supported for this setup. Automations run as that signed-in work or school account, not as a service principal. There is no project list and no Manage projects. Runs are possible in every project that account can already use. The account should be a Project Administrator in each project where automations will run, because turning an automation on creates that project's Service Hook. This setup does not add an Azure DevOps user, does not consume a Stakeholder seat for an app, and does not create an Enterprise application. The sign-in always includes openid, profile, offline_access, and Azure DevOps delegated vso.work_write, which covers the current work-item actions and Service Hook management. It can also include Read pipelines (vso.build) and Run pipelines (vso.build_execute). Run pipelines includes Read pipelines. Code, wiki, and classic Release Management are not part of this sign-in. Section 5 describes how those pipeline scopes are chosen.
Connect an Entra app. This setup requires the Azure DevOps organization to be connected to Microsoft Entra ID. The directory used for Connect must be that same directory. When the organization is not connected, this choice stays unavailable. A Project Collection Administrator signs in to Documentero's multi-tenant Microsoft Entra application. That one-time authorization adds the Workflow Automation service principal as a Stakeholder user and grants Project Administrators on the projects the administrator selects. The service principal is not made a Project Collection Administrator. The administrator token is then discarded and is not stored. Automations run as that service principal. Runtime tokens for this identity are short-lived tokens from the Microsoft Entra client credentials flow and are not persistently stored. This identity acts through its Project Administrators membership.
The Extension's user interface runs inside Azure DevOps. Receiving events (Azure DevOps Service Hooks), executing automations, and sending emails are hosted services operated by Documentero on Google Cloud Platform in the European Union.
We process Azure DevOps data only to run the automations your organization has configured and to operate, secure, and support the Service. We do not sell your data. Key points:
Changes stay in your Azure DevOps organization: Work item updates, comments, and queued pipeline runs performed by automations are written directly to your Azure DevOps organization through Microsoft APIs, using the Automation Identity. We do not keep a copy of your work items, source code, pipeline logs, or artifacts.
Event data is processed transiently: Work-item events and pipeline run and stage events sent by Azure DevOps are used to match your automations and queue a run, then discarded. Only short-lived duplicate-detection markers and compact Execution Logs are kept. A pipeline marker may include the run id, state, and result, for up to 7 days.
Connect an Entra app does not store a user token: The one-time administrator authorization used when connecting the organization or changing its selected projects is discarded. We do not store that authorization or any user token for this identity. Runtime tokens are short-lived tokens from the Microsoft Entra client credentials flow and are not persistently stored.
Setup Automation User stores one refresh token: After the work or school account signs in, the callback stores one refresh token per organization in Google Cloud Secret Manager. It is not stored in the application database and is not written to logs. Access tokens are minted from that refresh token when a run needs them and are kept in memory only. Neither path stores access tokens. We do not collect or store Azure DevOps passwords or Personal Access Tokens.
Extension sign-in uses your Azure DevOps session: The Extension user interface uses a short-lived Azure DevOps access token from your session to identify you, your organization, and your project. This token is not stored as an organization credential and is not used to execute automations.
The table below summarizes the data processed by the Service, where it comes from, why it is processed, and how long it is kept.
| Category | Source | Purpose | Retention |
|---|---|---|---|
| Organization ID and name, project ID and name | Azure DevOps | Tenant isolation, scoping of automations, settings, and logs | Until your organization stops using the Extension or requests deletion |
| Microsoft Entra tenant ID and Automation Identity summary | Setup Automation User or Connect an Entra app, and Microsoft APIs | Record which identity is in use. For Connect an Entra app, the tenant is the Microsoft Entra directory connected to the Azure DevOps organization. For Setup Automation User, the tenant is the signed-in work or school account's tenant, including when the organization is not connected to Microsoft Entra ID. | Until Disconnect |
| Project scope and connection status | Connect an Entra app, or Setup Automation User | For Connect an Entra app, limit execution to the projects a Project Collection Administrator selects. Setup Automation User has no selected-project list. Runs are possible in every project the signed-in account can already use. | Until Disconnect; project references may also remain with stored automations and settings |
| Refresh token (Setup Automation User only) | Microsoft sign-in | Mint access tokens to run automations as the signed-in work or school account | One token per organization in Google Cloud Secret Manager until Disconnect |
| User identifiers (Azure DevOps user descriptor, display name) | Extension session | Authenticate the Extension UI, apply access settings, record who last changed settings | Session; "last modified by" on settings |
| Organization contact email | Entered by an Organization Administrator | Operational notices (e.g. connection problems, important service notices) | Until changed or removed |
| Automation definitions | Authored by your users | Run your workflows | Until deleted by you |
| Project access settings (Azure DevOps group references) | Project Administrators | Control which additional groups may manage Automations and who may view Automations and Logs | Until changed |
| Execution Logs (status, timestamps, step summaries, identifiers and fields of work items used in the run, and, when a pipeline is involved, pipeline name, run id, result, state, branch, stage name, and run URL, errors) | Generated by the Service | Run history, troubleshooting | Approximately 30 days. Pipeline logs, artifacts, and source are not kept |
| Service Hook subscription references | Generated by the Service | Track subscriptions created in your organization | While the subscriptions are needed |
| Event data (Service Hook payloads) | Azure DevOps | Match automations, queue runs | Transient; duplicate-detection and loop-protection markers up to 7 days. A pipeline marker may include the run id, state, and result |
| Usage counters (daily execution counters, run counts per automation, pipeline runs queued per project) | Derived | Quota enforcement and display in the automation list. A project can queue at most 20 pipeline runs per UTC day. The same work item cannot queue the same pipeline again for one hour | Daily execution counters: current day (UTC); run counts: with the automation; pipeline queue counter: about 2 days |
| Email content and recipients | Your automation configuration and resolved values | Deliver the email | Transmitted to our email provider; no archive kept in our database; provider retains delivery logs per its terms |
| Operational and error diagnostics | Cloud logging | Reliability, security | Typically 30–90 days |
Automation definitions may include email subjects and bodies, recipient addresses, search conditions, references to shared queries, field values entered by your users, a pipeline id and name, a stage name, a branch name or path, and template parameter names and values. They do not store repository contents or pipeline logs. Please avoid placing secrets or unnecessary personal data in automation configuration.
The "Send customized email" action sends messages from notifications@documentero.com to the recipients configured in your automation, with the subject and body defined by your automation (including any work item fields, pipeline fields, or other Smart Values inserted into the message). Your organization decides who receives these emails and what they contain, and is responsible for having a lawful basis to contact each recipient. The action is intended for operational notifications related to your Azure DevOps work, not for marketing or bulk messaging. Emails are transmitted through our email delivery provider (see Section 6); we do not keep an archive of sent messages. We may rate-limit, filter, or suspend email sending to prevent misuse.
The Extension works with two identities:
The signed-in user (Extension scopes): While you use the Extension inside Azure DevOps, it can only read Azure DevOps resources that you can already see. These scopes support the user interface, including the automation builder, identity and group selection, project context, and organization settings. They are not used to execute automations.
The Automation Identity: The organization uses one identity at a time. Setup Automation User runs automations as the signed-in work or school account, in every project that account can already use. There is no project list. The account should be a Project Administrator in each project where automations will run, because turning an automation on creates that project's Service Hook. The sign-in always includes openid, profile, offline_access, and Azure DevOps delegated vso.work_write. It can also include Read pipelines (vso.build) and Run pipelines (vso.build_execute). Run pipelines includes Read pipelines. A first sign-in starts with Work items and Run pipelines selected. The person can turn Run pipelines off before continuing. An organization that already signed in with only work items must sign in again before a pipeline automation can be saved. Read pipelines is required to use a pipeline trigger or Get pipeline work items. Run pipelines is required to queue a run. Code, wiki, and classic Release Management are not part of this sign-in and are not current actions. Connect an Entra app runs automations as the Workflow Automation service principal on the projects where a Project Collection Administrator has granted it Project Administrators membership. This identity acts through that membership. It does not grant vso.work_write, vso.build, or vso.build_execute as delegated scopes. Pipeline calls use that Project Administrators membership on the selected projects.
Manage projects applies only to Connect an Entra app. It uses the same one-time administrator sign-in to add, pause, or resume selected projects. This provisioning permission belongs to Documentero's Microsoft Entra application and is separate from the Extension UI scopes listed below. Setup Automation User has no project list and no Manage projects. Project Administrators may manage Automations by default and may allow additional groups; project members may view Automations and Logs unless that access is restricted.
Service Hook subscriptions, including those for pipeline run and stage events, are created and removed by the Service automatically as automations are enabled or disabled. Because subscriptions are project-scoped, you can review them for the relevant project under Azure DevOps Project Settings → Service Hooks. The Extension's organization settings page also shows their status. Delivery of those events is not guaranteed.
The signed-in user's Extension scopes are grouped as follows:
Work and project context (vso.work, vso.project): read work items, queries, fields, states, projects, and teams needed by the builder.
Identity and settings (vso.identity, vso.graph, vso.hooks, vso.features_write, vso.memberentitlementmanagement): support identity and group selection, access checks, Service Hook status, navigation visibility, and organization user visibility.
Pipeline picker (vso.build): used by the pipeline picker in the Extension interface. The picker shows only definitions the signed-in user can already see. This scope is not used to execute automations. vso.wiki and vso.release remain unused reserved scopes. The Extension does not request vso.code.
We use subprocessors (third-party services) to assist in providing the Service. They are subject to contractual data-protection and confidentiality obligations appropriate to their role. Currently, the following subprocessors are used:
| Subprocessor | Role | Data Involved |
|---|---|---|
| Google Cloud Platform (including Firebase) | Hosting, database, serverless compute, task queues, secret and key management, operational logging. Located in the European Union. | Organization, tenant, project and connection records, one Setup Automation User refresh token per organization (Google Cloud Secret Manager), automation definitions, execution logs, and operational logs |
| Brevo | Outbound email delivery for the "Send customized email" action | Recipient addresses, subject, and message body as configured by your automation |
Microsoft (Azure DevOps, Microsoft Entra ID) provides your own Azure DevOps organization and identity platform. The Service calls Microsoft APIs on your behalf to read and update your work items, run queries, read and queue pipelines, and manage Service Hook subscriptions. Microsoft processes this data under your organization's agreement with Microsoft, not as our subprocessor.
We do not share your data with third parties for their own purposes. We may disclose data where required by law or to protect the rights, safety, or security of the Service, our users, or third parties. The subprocessor list on this page may be updated from time to time.
Retention periods for each category of data are listed in Section 3. Uninstalling the Extension does not stop automations. Disconnect does. Before uninstalling the Extension, we recommend using Disconnect in the Extension's organization settings. You may also disable or delete your automations. Stored automations remain but do not run until setup is completed again.
Setup Automation User. Disconnect deletes the refresh token stored for the organization and removes Service Hooks created by Documentero. You do not need to remove Automations from the signed-in account's Microsoft apps. There is no app user to delete.
Connect an Entra app. Disconnect clears Documentero's connection state and removes Service Hooks created by Documentero. It does not remove the service-principal user from Azure DevOps Users and does not remove the Enterprise application from your Microsoft Entra directory. Delete the Azure DevOps user to release its Stakeholder seat; you may also disable or remove the Enterprise application. A leftover user can block a later Connect.
To request deletion of remaining organization data, contact support@documentero.com.
All backend processing and storage for the Extension take place in Google Cloud regions located in the European Union (primary region: europe-west1, Belgium). The Extension currently does not offer a selectable processing location. Your Azure DevOps data itself remains in the Microsoft region chosen for your organization. Current processing locations are described in the version of this Policy then in effect.
Data is encrypted in transit (HTTPS/TLS) and at rest. Service credentials are protected server-side. Connect an Entra app discards the administrator authorization and does not store a user token; its runtime tokens are not persistently stored. Setup Automation User stores one refresh token per organization in Google Cloud Secret Manager. Neither path stores access tokens. Inbound events are authenticated, and changes to automations and settings go through authenticated server-side functions. For Setup Automation User, Disconnect deletes the stored refresh token. For Connect an Entra app, Disconnect does not remove the service-principal user or the Enterprise application. Uninstalling the Extension does not stop automations. Disconnect does. We recommend Disconnect before uninstall. Section 7 describes those steps. Details are in our Security & Data Protection Statement.
Where required by applicable law or an applicable Data Processing Addendum, we will notify affected organizations without undue delay after confirming a personal data breach affecting their data. Notices may be sent to the contact email provided in the Extension or through other appropriate channels and will contain the information reasonably available at that time.
The Service is intended for business use and is not directed at children. It is not intended for processing special categories of personal data. Work item fields that your organization includes in automations or emails may contain personal data (for example assignee names or email addresses); your organization is responsible for the content of its Azure DevOps work items and automation configuration.
Where the General Data Protection Regulation (GDPR) applies, the following roles and controls apply:
Roles: Your organization is the data controller for the Azure DevOps content and automation configuration processed by the Service; Documentero acts as a data processor on your organization's instructions. For limited operational data such as the organization contact email and usage statistics, Documentero acts as a controller for the purpose of operating and securing the Service. A Data Processing Addendum covering the Extension is available on request.
Data Subject Rights: You have the right to access, rectify, and erase your personal data. You can exercise these rights by contacting us at support@documentero.com. Where we act as a processor, requests should generally be directed to your organization; Documentero will assist as required by applicable law or an applicable Data Processing Addendum.
Your Controls: Organization Administrators can change the contact email and use Disconnect. Manage projects applies only to Connect an Entra app. Full revoke of Setup Automation User is Disconnect. Authorized users can edit, disable, or delete automations according to project access settings. Execution Logs expire automatically. Complete offboarding steps are described in Section 7.
Data Transfer: The Service is hosted in the European Union. We do not transfer your personal data to regions not providing an adequate level of data protection unless adequate safeguards are in place.
The Extension is currently offered free of charge while in Preview, and we do not collect payment or card information for it. If paid plans are introduced, any payment-data processing will be governed by the privacy disclosures in effect when that data is collected.
If you have any questions or concerns regarding this Privacy Policy or the data processing practices of our Azure DevOps extension, or if you would like to request a data flow diagram describing how data moves between Azure DevOps, the Extension, our backend, and our subprocessors, please contact us at support@documentero.com.
We may update this Privacy Policy from time to time to reflect changes in our practices (including when the Extension leaves Preview, when new regions or features become available, or when subprocessors change) or for other operational, legal, or regulatory reasons. Changes take effect when posted or on any later date stated in the updated Policy, subject to applicable law. The Last Updated date identifies the current published version.
Security & Data Protection Statement | End-User License Agreement | Support Policy