How to Use Tongyi Qianwen in DingTalk to Automate OA Approvals and Group-Chat Follow-Ups

The short answer: DingTalk is where a China-based SME's approvals and daily decisions actually happen — and where decisions quietly die. Tongyi Qianwen, Alibaba's model family, can draft an OA approval request from a plain-language description and turn a scrolling group chat into a numbered, owned action list. It drafts and structures; a named person still reviews and submits.

A purchase decision gets made in a DingTalk group at 6:40pm on a Tuesday. Four people are in the thread, two of them half-reading it on the metro, and the outcome — buy the twelve laptops, from the vendor that quoted second, against the H2 budget line — is spread across nine messages, one of which is a voice note.

By Friday nobody has raised the OA approval. Not because anyone forgot, exactly. The person who would normally raise it was not certain the decision was final; the person who made it assumed the request was already in the queue.

This is the most ordinary operational failure in a China-based SME, and it is not caused by bad tools. DingTalk (钉钉) handles group chat well and handles OA approval (OA审批) well. What it does not do on its own is convert the first into the second — and that gap is where an office manager's week goes.

Why DingTalk Decisions Get Lost the Moment the Chat Scrolls

A group chat and an approval form are two different data shapes, and the work of converting between them falls on whoever notices it needs doing.

An approval form wants structure: a requester, an amount, a budget code, a vendor, a justification, an approval chain. A chat thread has none of that. It has context, hedging, a change of mind in message six, an attachment, and a decision that was never stated as a decision — it was stated as "行，就这样吧" and everyone moved on.

Three things follow from that mismatch, and they are worth naming because they are what you are actually trying to fix:

• No moment of record. Nothing in the thread marks where discussion became decision. Different people in the same chat will point to different messages.
• No owner. A decision with three participants and no named follow-up owner is a decision with zero follow-up owners. The approval does not raise itself.
• Reconstruction cost. Whoever eventually fills in the form re-reads forty messages to recover four fields. That is ten minutes of work that feels like an hour, which is exactly why it gets postponed.

Note what is not on that list: the approval chain itself, and the finance rules behind it. Those are working fine. The failure is upstream of the form.

What Tongyi Qianwen Can Do Inside DingTalk

Tongyi Qianwen (通义千问) is Alibaba's model family, reachable through Alibaba Cloud's model service — the same account and the same network as the rest of an Alicloud deployment. For a company already hosting in Alicloud and already running daily operations in DingTalk, both ends of this workflow sit inside one vendor's environment. That is the same practical logic that makes a DeepSeek-on-Alicloud support bot easier to govern than a cross-border one: fewer network paths, fewer contracts, one data-residency conversation instead of two.

DingTalk itself also ships AI features, and the mix differs by edition and changes over time. Check what is already enabled on your tenant before building anything — you may be about to rebuild something you already pay for.

Drafting OA approval requests from a plain-language description

The workflow that earns its keep is unglamorous: someone types or dictates what they need in ordinary Chinese, and gets back a filled approval form.

"给市场部买 12 台笔记本，用第二家报价的那个供应商，走下半年预算" contains, read carefully, a department, a quantity, an item, a vendor selection with an implied justification, and a budget period. A model can map those onto the fields your OA form actually has — and, critically, tell you which required fields the description did not cover. The unit price is missing. The delivery date is missing. Nobody said which cost centre.

That last part is most of the value. The draft is useful; the list of what is still blank is what stops a form bouncing back three days later.

Turning a group-chat thread into a numbered, owned action-item list

The second job is a summarisation task with a specific output shape. Not "summarise this discussion" — that produces a paragraph nobody acts on. Ask instead for three separate lists: decisions that were actually made, action items with an owner and a due date, and open questions that were raised and never answered. Every row cites the message it came from.

The three-list structure does real work. Decisions and actions get conflated constantly in chat, and the open-questions list is usually the one that produces the "wait, we never settled that" moment — before the purchase order goes out rather than after.

Where the thread does not support a field, the answer must be "not stated", never a guess. An action item with an invented owner is worse than no list at all, because it looks handled.

A Practical Workflow — From Chat Discussion to a Tracked Approval

Decide what enters the pipeline. Not every group chat. Pick the two or three groups where operational decisions genuinely get made — the ops group, the procurement group, the site group — and leave the rest alone. A summariser pointed at a social chat produces noise and teaches people to ignore its output.

Extract on a trigger, not continuously. Someone marks the end of a discussion, or the extraction runs on a fixed daily boundary. Continuous summarisation of a live thread reports half-finished arguments as conclusions.

Post the three lists back into the same chat. This matters more than it sounds. A list that lands where the discussion happened gets corrected within minutes by the people who were there. A list that lands in someone's private dashboard is never corrected by anyone.

Draft the approval from the confirmed decision, not the raw thread. Once the decision list has been corrected in-chat, feed that one line into the approval draft — not the forty messages. The input is cleaner and the output is auditable: you can point at the decision the form came from.

A named person reviews and submits. The requester checks the fields, fills the blanks the draft flagged, and submits through the normal OA chain. Nothing about the chain changes; the chain is the control, and it stays exactly where it is.

Log what the draft got wrong. For the first month, keep a note of every field the model filled incorrectly. That list becomes your prompt fix, and it is also the honest answer when someone asks how well this actually works.

AI-Assisted DingTalk Workflows vs Manual OA Forms vs a Dedicated Project-Tracking Tool

• AI-assisted DingTalk workflow. Starts where the work already happens, so adoption costs nothing — nobody is asked to open a new app. Turns a ten-minute reconstruction into a one-minute review. Its weakness is that it is only as good as the chat: a decision made in a phone call and never written down does not exist to it, and a confidently wrong extracted field is easy to nod through.
• Manual OA forms only. Completely reliable in the sense that whatever is in the form was typed by a person who meant it. Also completely dependent on someone deciding to open the form, which is the exact step that fails. Fine at low volume, and its failure mode is silence rather than error — which is harder to notice.
• A dedicated project-tracking tool. Teambition, Feishu's task features, Jira or similar give you real state — assignee, status, history — which a chat-based list never will. The cost is a second place people must go. In an SME where DingTalk is the entire working surface, a tracker nobody opens is worse than a chat list everyone sees. If your team genuinely lives in a tracker already, extract into that rather than into a chat message.

The honest combination for most SMEs: keep the tracker if you have one and it is used, extract into DingTalk if you do not, and in both cases keep the approval chain in OA where finance can audit it.

Where It Goes Wrong

Approvals drafted with the wrong budget code. The model infers a cost centre from context and gets it plausibly, confidently wrong. Finance catches it at month end, which is a bad time to catch it. Fix: never let the model populate a code from inference — either it appears literally in the source text, or the field comes back blank for a human to fill.

Silent scope changes. A thread where the quantity moved from ten to twelve and back to ten summarises to whichever number the model weighted. Requiring a message reference on every extracted number lets the reviewer check the one that matters in seconds.

No audit trail. If an AI-drafted form is submitted with no record of the input it was drafted from, you have lost the reason the request exists. Keep the source decision line with the approval — pasted into the justification field is fine.

Auto-submission. The temptation is to close the loop entirely: extract, draft, submit. Do not. An approval submitted with no human between the chat and the chain removes the one control that makes the chain meaningful, and it is the first thing an auditor will ask about.

Getting This Right — Approval-Chain Governance, Data Residency, and When to Bring in IT

The approval chain is a financial control, not a workflow step. Whatever you automate, the person who submits and the people who approve stay human and unchanged. If the automation ever makes it easier to submit than to think, it has weakened the control while speeding up the process — the wrong trade, made invisibly.

Be specific about what data leaves DingTalk. A procurement thread contains vendor names, prices, and internal budget positions. Before anything is piped to a model endpoint, know which endpoint, in which region, under what retention terms — and check the current terms directly rather than assuming, because they change. Running Tongyi Qianwen in an Alicloud China region keeps this inside one provider and one jurisdiction, which is the main reason to prefer it here over a cross-border API.

Treat the credentials as production credentials. The model API key and the DingTalk application credentials that let this thing read chats and create approval drafts are, between them, read access to your operational conversations and write access to your finance workflow. They belong in a secrets store with rotation and a named owner, not in a script on somebody's laptop.

Scope the application permissions narrowly. A DingTalk internal application can be granted broad chat-reading scopes. Grant it the specific groups and the specific approval templates it needs, and nothing else. The review question is not "does it work" but "what else could it read".

Choosing the deployment, writing the extraction prompts and the fixed output structure, and setting review rules that survive a busy week is AI+ Support work. The Alicloud side — where the model endpoint sits, how the network reaches it, who holds the keys — is managed IT cloud services. The DingTalk app registration, permission scoping and ongoing support underneath is ordinary managed IT support. For the customer-facing counterpart of this pattern, see our write-up on running a DeepSeek customer service chatbot on Alibaba Cloud, or get in touch if you want to work through the approval-chain design first.

Frequently Asked Questions

Does this data ever leave Alicloud's network?

It depends entirely on which endpoint you call. If you run Tongyi Qianwen through Alibaba Cloud's model service in a China region, the request stays within that provider and jurisdiction — which is the specific reason this pairing is worth preferring for China operations. Point the same workflow at an overseas API and you have created a cross-border data transfer, with everything that implies. Confirm the region and the retention terms in the provider's current documentation before the first production call, not after.

Can an AI-drafted approval get auto-submitted without review?

Technically yes, and you should not build it that way. The approval chain is a financial control; a human requester between the chat and the submission is what keeps it meaningful. Build the draft-and-review step, measure how often the draft is right, and resist the efficiency argument for removing the reviewer — the time saved is minutes and the control given up is the whole point of having a chain.

How is this different from DingTalk's own built-in AI features?

DingTalk ships its own assistant and summarisation features, and what is available depends on your edition and changes as the product does. Check what your tenant already has before building anything custom. The reason to build is usually specificity: your OA form's exact fields, your budget-code rules, your three-list output format. If the built-in feature covers your case, use it — that is cheaper and better supported than anything you would write.

What happens when the group chat spans multiple decisions at once?

This is the normal case, and it is why the extraction should return a list rather than a summary. Ask explicitly for every distinct decision as its own numbered row, and expect to correct the boundaries at first — models tend to merge two related decisions into one. Posting the list back into the chat is what catches this, because the participants will immediately say that rows two and three were different things.

Do we need Alibaba Cloud to use this if we are already on DingTalk?

You need somewhere to run the model, and Alicloud is the natural choice if you are already in that ecosystem — same account, same network, one jurisdiction. It is not a hard requirement. What matters is that the decision about where the model runs is made deliberately by someone who understands the data crossing that boundary, rather than defaulting to whichever API key was easiest to obtain.

How accurate is the field extraction in practice?

Accurate enough to be useful, not accurate enough to be trusted unreviewed — and the ratio varies with how disciplined your chats are. Structured, decision-oriented threads extract well. Long, forked, half-voice-note threads do not. The productive answer is to measure it on your own chats over a month rather than accept anyone's percentage, including ours.

What about voice messages in the thread?

Voice notes are extremely common in DingTalk groups and are a genuine gap: if the audio is not transcribed, everything in it is invisible to the extraction, and nothing in the output announces the absence. Decide early whether transcription is in scope. If it is not, treat any thread with voice content as one the model has only partly read, and have the output say so.