What this n8n template actually does

Let’s start with the big picture. Once you plug in this template, here’s what happens whenever a pull request is created in Azure DevOps:

• Azure DevOps fires a Service Hook when a PR is created
• n8n receives that event through a webhook trigger
• A MySQL table is queried to match Azure DevOps users to DingTalk accounts
• A code node builds a clean, markdown-formatted message with all the important PR info
• The workflow sends that message to a DingTalk group robot, @mentioning the right reviewers

In other words, your team sees “Hey, here’s a new PR, here’s who opened it, here are the reviewers, and here’s who needs to take action” right inside DingTalk, without anyone having to copy links or ping people manually.

When should you use this workflow?

If any of these sound familiar, this template is probably a good fit:

• Your code lives in Azure DevOps, but your team communicates in DingTalk
• PR reviews are slow because people miss notifications or forget to check Azure DevOps
• You want consistent, readable PR notifications in chat, not random copy-pasted links
• You’d like to @mention reviewers automatically instead of tagging them by hand

Once it is in place, you get faster reviews, better visibility, and fewer “Hey, did you see my PR?” messages.

How the workflow is structured

The n8n template is intentionally compact but covers the full journey from PR event to DingTalk message. It uses four main nodes:

1. PR Webhook Trigger – An n8n Webhook node that receives POST requests from Azure DevOps Service Hooks whenever a pull request is created.
2. Load Account Map – A MySQL node that queries a mapping table where you store relationships between Azure DevOps accounts and DingTalk users.
3. Build DingTalk Payload – A Code node that:
   • Parses the incoming PR payload
   • Matches the PR creator and reviewers to DingTalk names and mobiles
   • Builds the final markdown text and @mention data
4. Send DingTalk Webhook – An HTTP Request node that posts the message to your DingTalk group robot webhook URL.

Each piece has a clear job, which makes it easy to tweak or extend later.

What you need before you start

Before importing the n8n template, make sure you have these in place:

• An n8n instance where you can import and run workflows
• An Azure DevOps project with permission to create Service Hooks
• A DingTalk group robot (custom bot) with a webhook URL or access token
• A MySQL database where you can create a simple user mapping table

Setting up the MySQL mapping table

The secret to clean @mentions is a small mapping table that connects Azure DevOps accounts to DingTalk identities. You only need a very simple schema:

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

What each field is used for

• TfsAccount – The Azure DevOps uniqueName (often an email-style string) that appears in the PR webhook payload. This is what the workflow uses to match users.
• UserName – An optional, human-friendly display name that you want to show in DingTalk messages.
• DingTalkMobile – The phone number tied to the user’s DingTalk account, used to @mention them via the DingTalk robot. The robot expects mobile numbers when building mentions.

Once this table is populated for your team, the workflow can automatically translate Azure DevOps users into DingTalk mentions.

How the mapping and message-building logic works

Curious what the Code node is doing behind the scenes? Here’s the flow inside the Build DingTalk Payload node:

1. It reads the pull request event payload that came in through the PR Webhook Trigger.
2. It loads the account mapping data that the MySQL node returned.
3. It tries to match:
   • The PR creator’s Azure DevOps account to a DingTalk name and mobile
   • Each reviewer’s Azure DevOps account to a DingTalk entry as well
4. If a match is found for the PR creator, their display name in the message is replaced with the DingTalk-friendly name from the mapping table.
5. For reviewers, it collects the corresponding mobile numbers into an atMobiles array, which is part of the DingTalk robot message format.
6. If the payload indicates that a team is being notified or an “@all” style marker is present, it sets isAtAll to true instead of building a specific mobile list.
7. It appends a line in the message body that calls out the mapped reviewers and asks them to review the PR.
8. Finally, it returns an object containing:
   • text – the final markdown message
   • atMobiles – the list of mobile numbers to @mention
   • isAtAll – a boolean flag for mentioning everyone

   which is passed on to the HTTP Request node that talks to DingTalk.

This approach keeps the message readable for humans while making sure the right DingTalk accounts actually get notified.

Connecting Azure DevOps to n8n via Service Hooks

Next, you need Azure DevOps to send PR events into your n8n workflow. You do that with a Service Hook:

1. In your Azure DevOps project, go to Project Settings > Service Hooks.
2. Create a new subscription and pick the Web Hooks service.
3. Choose the event type Pull request created. You can later add other PR events if you want more notifications.
4. Paste the n8n webhook URL from your PR Webhook Trigger node into the URL field.
5. Set the HTTP method to POST.
6. Use the Test option in Azure DevOps to make sure the request reaches n8n, then save the subscription.

Once that is done, every new PR will automatically trigger your workflow.

Configuring the DingTalk group robot

On the DingTalk side, you just need a custom bot that can receive webhook messages:

1. In your DingTalk group, add a custom robot. Configure it with either:
   • a signing secret, or
   • an access_token

   and copy the webhook URL that DingTalk gives you.

2. In n8n, open the Send DingTalk Webhook HTTP Request node and set that URL. It usually looks like:
   https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN
3. Make sure:
   • The robot is allowed to @mention users by mobile number
   • The phone numbers in your MySQL table match the phone numbers on the DingTalk accounts

After that, the workflow can post messages directly into your group chat with proper @mentions.

Importing and wiring up the n8n template

Ready to plug everything together? Here is a quick setup path inside n8n:

1. In n8n, click Import and paste the workflow JSON for this template.
2. Create a MySQL credential in n8n and assign it to the Load Account Map node so it can query your mapping table.
3. Edit the webhook path in the PR Webhook Trigger node, then copy the generated URL and use that in your Azure DevOps Service Hook.
4. Store your DingTalk robot token in an HTTP Request credential, then configure the Send DingTalk Webhook node to use that credential instead of hardcoding the token.
5. Activate the workflow and create a test pull request in Azure DevOps to see the message appear in DingTalk.

Security best practices

Since this workflow connects multiple systems, it is worth locking things down a bit:

• Use a secret or non-obvious path for the n8n webhook, and if possible, restrict access by IP so only Azure DevOps can call it.
• Store your DingTalk access_token inside n8n credentials, not in the workflow JSON or plain text fields.
• Limit database permissions so that only the n8n service account can access the tfs_dingtalk_account_map table.

Testing the workflow and fixing common issues

How to test the full flow

Once everything is wired up, walk through a full end-to-end test:

1. Create a test pull request in Azure DevOps.
2. Open the Azure DevOps Service Hook delivery logs and confirm that the webhook call succeeded.
3. Check n8n’s execution list to see the webhook run, and inspect the output of each node if needed.
4. Look at your DingTalk group to verify that:
   • The PR message shows up with the expected markdown formatting
   • The correct reviewers are @mentioned

Common problems and how to diagnose them

• No message in DingTalk Make sure the webhook URL in the HTTP Request node is correct, and check any logs or error messages from the DingTalk robot. Also verify that the n8n execution finished successfully.
• @mentions are not working Double-check that the mobile numbers in your MySQL mapping table exactly match the mobile numbers in DingTalk. Confirm that the robot is allowed to mention users by mobile.
• Users are not being mapped correctly Inspect the Build DingTalk Payload node output. Look at the reviewer uniqueName values in the Azure DevOps payload and make sure they match the TfsAccount values in your mapping table. Since this is string-based matching, even small differences can break it.

Ideas for customizations and advanced tweaks

Once the basics are running smoothly, you can take the workflow further to match your team’s style:

• Listen to additional Azure DevOps events like “PR updated” or “PR merged” and send different notifications or route them to other DingTalk groups.
• Extend the mapping logic to support multiple aliases per user or pull identity data from a dedicated identity service API instead of a static MySQL table.
• Add simple rate limiting or batching in n8n if you have very busy repositories and want to reduce notification noise.
• Enrich the message with more PR metadata, such as:
  • Source and target branch names
  • Direct links to the PR
  • Commit summaries
  • Reviewer info or avatars where applicable

Because this is all running in n8n, you can keep iterating on the workflow visually as your team’s needs change.