Why automate PR notifications to DingTalk?

Keeping your engineering team aware of new pull requests is essential for fast reviews and shorter cycle times. If your organization uses Azure DevOps for source control and DingTalk for team communication, bridging the two with an automation platform like n8n lets you:

• Send contextual PR messages to group chats
• Automatically @mention the right reviewers
• Customize message formatting with markdown/HTML
• Maintain a centralized mapping between Azure users and DingTalk accounts

Overview of the provided n8n template

The template implements a compact workflow that listens for Azure DevOps pull request events and forwards a formatted message to a DingTalk group robot. The nodes in the flow are:

1. PR Webhook Trigger — n8n webhook that receives Azure DevOps Service Hook POSTs when a PR is created.
2. Load Account Map — a MySQL node that loads a mapping table linking Azure accounts to DingTalk mobile numbers and display names.
3. Build DingTalk Payload — a code node that parses the PR event, maps reviewers to DingTalk users, and builds the final markdown message and @ list.
4. Send DingTalk Webhook — an HTTP Request node that posts the message to the DingTalk robot webhook URL.

Prerequisites

• An n8n instance where you can import and run workflows
• An Azure DevOps project with permission to create service hooks
• A DingTalk group robot webhook (custom bot) with an access token
• A MySQL database to store the user mapping table

Database schema (MySQL)

Create a simple table to map Azure DevOps accounts to DingTalk contact info. Example schema:

CREATE TABLE tfs_dingtalk_account_map (
  TfsAccount VARCHAR(255) NOT NULL,
  UserName   VARCHAR(255),
  DingTalkMobile VARCHAR(255)
);

Fields:

• TfsAccount — Azure DevOps uniqueName or email-like domain used to match reviewer entries in the webhook payload.
• UserName — optional human-friendly name in DingTalk to show in the message.
• DingTalkMobile — phone number used to @ mention a DingTalk user (group robot expects mobiles for mentions).

How the mapping and message-building works

The code node (Build DingTalk Payload) performs these steps:

1. Reads the PR webhook payload from the trigger node.
2. Loads account mappings returned by the MySQL node.
3. Attempts to map the PR creator and each reviewer to DingTalk display names and mobile numbers.
4. Replaces the PR creator’s display name with the mapped DingTalk name (if available).
5. Collects the mobile numbers of reviewers to build the atMobiles array used by DingTalk robot format. If the reviewer is a team or an “@all” marker is detected, it will set isAtAll to true.
6. Appends an instruction line to the message asking the mapped users to review.
7. Returns an object containing text, atMobiles and isAtAll to the HTTP Request node.

Using this approach keeps the message readable and ensures the right DingTalk accounts are notified.

Configure Azure DevOps Service Hook

Create a Service Hook in your Azure DevOps project:

1. Go to Project Settings > Service Hooks.
2. Create a new subscription and choose the Web Hooks service.
3. Select the trigger event Pull request created (or other PR events you want).
4. Paste your n8n webhook URL (from the PR Webhook Trigger node path) and set the HTTP method to POST.
5. Test and save the subscription.

Configure the DingTalk group robot

1. In DingTalk, add a group robot (custom bot) and secure it either with a signing secret or an access_token. Copy the webhook URL.
2. Set the webhook URL into the Send DingTalk Webhook HTTP Request node in n8n. Example URL format: https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN
3. Make sure the robot has permission to @mention users by mobile number and that the mobiles listed in your MySQL table match DingTalk account phones.

Security considerations

• Protect the n8n webhook endpoint with a secret path and IP allow list if possible — avoid exposing it publicly without restrictions.
• Store your DingTalk access_token securely in n8n credentials, not directly in the workflow JSON.
• Limit access to the MySQL table to only the n8n service account to reduce data exposure.

Testing and troubleshooting

Test the full flow

1) Create a test PR in Azure DevOps. 2) Check the Service Hook delivery logs (Azure DevOps). 3) Inspect the n8n webhook executions and node outputs. 4) Verify the DingTalk group receives the markdown message and mentions.

Common issues

• No message received in DingTalk — verify the webhook URL and the HTTP Request node configuration and check the DingTalk robot logs for rejection reasons.
• Mentions not working — confirm phone numbers in the MySQL mapping exactly match DingTalk account mobiles and that the robot has mention privileges.
• Mapping fails — look at the Build DingTalk Payload node logs to ensure reviewer uniqueName values match your TfsAccount table values (string matching rules are used).

Customizations and advanced tips

• Use additional Azure DevOps events (PR updated, merged) to notify different chat channels or send different message templates.
• Enhance mapping logic to handle multiple aliases per user or use a separate identity service API instead of a static MySQL table.
• Add rate-limiting or batching for high-traffic repositories to avoid flooding DingTalk with messages.
• Include PR metadata like branch names, links, reviewers’ avatars, or commit summaries in the markdown message for better context.

Importing the template into n8n

To get started quickly:

1. In n8n, click Import and paste the workflow JSON for the template.
2. Create a MySQL credential in n8n and update the Load Account Map node to use it.
3. Edit the webhook path for the PR Webhook Trigger node, copy the generated URL, and use it in your Azure DevOps Service Hook.
4. Store the DingTalk robot access token in an HTTP Request credential and update the Send DingTalk Webhook node to reference it.
5. Run a test PR to confirm everything works.