Azure Cards lets users import and sync Azure Boards work items with Miro boards. This guide covers the integration's technical implementation, security model, data handling, and the Microsoft consent flow for admins evaluating or configuring the integration. For the full feature walkthrough and end-user setup steps, see Azure Cards.
Requirements and limitations
- Card customization (choosing which attributes display on a card) isn't supported.
- Importing a card by pasting a task URL from the clipboard isn't supported.
Technical implementation
Miro integrates with Azure Boards through the Azure DevOps REST API, and subscribes to Azure DevOps service hooks to receive work item updates in real time.
Data flows
Data flows in both directions between Azure DevOps and Miro.
Azure DevOps → Miro:
- The work item list shown in the Azure DevOps work item picker. This list only includes work items the requesting user can access in Azure DevOps, and carries the ID, type, title, assignee, and state.
- Work item details shown on an Azure Card: ID, title, project, type, state, description, parent work item, assignee, priority, area, iteration, story points, and the Azure Boards work item URL. This arrives with every update to the corresponding item in Azure Boards. Azure DevOps sends other work item fields alongside these, but Miro discards anything outside this list.
Miro → Azure DevOps:
- Work item info used to create an Azure card: title, project, type, state, description, parent work item, assignee, priority, area, iteration, and story points.
- Search strings used to filter picker results, and to filter assignees, areas, iterations, and parent work items when creating a card.
Data in transit
Data exchanged between Azure DevOps and Miro is encrypted using TLS.
Data retention
Miro retains the work item data added to a board for as long as the card remains on the board, and keeps it updated if service hooks are configured. There's no fixed retention limit for this data; standard Miro account security protocols apply.
Authentication and authorization
Users authenticate their Azure account using an OAuth 2.0 authorization code grant, exchanging an authorization code for an access token. See Microsoft's OAuth documentation for details on how Azure DevOps OAuth works.
Each Miro user who authorizes Azure Cards gets their own separate access token — access isn't shared across users.
Required authorization scopes
-
vso.identity— read identities and groups. -
vso.graph— read user, group, scope, and group membership information. -
vso.memberentitlementmanagement— read users, their licenses, and the projects and extensions they can access. -
vso.project— read projects and teams. -
vso.work_full— full access to work items, queries, backlogs, plans, and work item tracking metadata; also required to receive work item event notifications through service hooks. This scope grants broader access than Miro uses — Azure DevOps doesn't offer a narrower scope limited to work items only, and Miro only reads and writes work item data.
See Microsoft's scope reference for details.
What's stored in Miro and how
Only access tokens are used during integration operation — Miro doesn't retain request tokens or other OAuth secrets beyond the access token. Access tokens are stored securely in Miro's database and used only on the server side.
Service hook security
Miro generates a unique service hook URL, containing a secret key, for every team that sets up the integration. Each Azure DevOps instance calls its own unique service hook URL to notify Miro of work item changes.
Requests are sent over an encrypted connection, so the URL itself isn't exposed in transit. The main way a service hook URL could reach an unauthorized third party is if an Azure DevOps admin shares the key outside the organization, whether intentionally or by mistake.
Consent scenarios when connecting or reconnecting
Connecting or reconnecting the Azure DevOps instance (for example, after Miro updates the registered Azure Cards app) sends the admin through Microsoft's consent flow. What the admin sees depends on the Microsoft Entra tenant's consent settings (see Microsoft's admin and user consent overview):
- If Entra admin approval is required, and the admin connecting the integration has the right permissions: they can check Consent on behalf of your organization on the Microsoft consent screen. This approves the app for every user in the Entra tenant at once.
- If user consent is allowed: the admin connecting the integration consents only for themselves. Each other user then consents individually the first time they use the integration.
- If the admin connecting the integration doesn't have permission to approve: they see Need admin approval and must ask a Microsoft Entra admin to grant consent — either by submitting a request from the consent screen (if their tenant allows it) or by contacting an Entra admin directly.
Reconnect at the Enterprise or Organization level
Requires both Company admin permissions in Miro and Project Collection Admin group permissions in Azure Boards.
- In Miro, go to Company settings > Apps & integrations > Apps > Manage apps > Azure Cards > Settings.
- Select Disconnect next to the existing Azure DevOps instance.
- Select Connect to reconnect the Azure DevOps instance. You're redirected to Microsoft to sign in.
- After signing in, you see the consent screen for the Miro Azure Cards app. What happens next depends on your Entra permissions and your tenant's consent settings — see the scenarios above.
Reconnect at the Enterprise team level, or on the Business plan
Requires both Team admin permissions in Miro and Project Collection Admin group permissions in Azure Boards.
- In Miro, go to Team settings > Apps > Azure Cards.
- Select Disconnect next to the Azure instance.
- Select Disconnect next to the Microsoft account.
- Select Connect to reconnect the Microsoft account. You're redirected to Microsoft to sign in.
- After signing in, you see the consent screen for the Miro Azure Cards app. What happens next depends on your Entra permissions and your tenant's consent settings — see the scenarios above.
- Back in Miro, select Connect next to the Azure instance to reconnect it.
- Repeat these steps for every team that uses the Azure Cards integration.