Nudge Dynamics 365 deal owners about stale pipeline in Slack

Every weekday at 8am in my workspace timezone, audit my open sales pipeline in Microsoft Dynamics 365 and privately nudge each deal owner in Slack about the deals that are going stale. Use a cron trigger: Dynamics 365 does not offer a poll or webhook trigger on this platform, so the schedule fires the run and the workflow pulls the pipeline itself.

Start with Dynamics 365 Query Records against the opportunity table to pull every open opportunity. Filter to open deals with statecode eq 0, and select at least name, opportunityid, _ownerid_value, estimatedvalue, estimatedclosedate, salesstagecode, stepname and modifiedon. Order by estimatedvalue descending. Request formatted-value annotations so you get readable owner names and stage labels instead of raw option-set numbers, and page through @odata.nextLink until you have the full pipeline rather than only the first page.

Then exercise judgement over that list rather than applying one blunt rule. The signals that matter: a deal with no modification for 14 or more days has gone quiet; a deal whose estimated close date is already in the past, or falls within the next 7 days while the deal is still sitting in an early sales stage, is not going to land on time; and a high-value deal that has slipped backwards a stage is the most urgent of all. Weigh these together with deal value, so a large deal that is mildly stale can outrank a tiny deal that is badly stale. Do not flag a deal just because it is new, and do not flag a late-stage deal that is clearly still moving.

Use Retrieve Record to pull fuller detail on anything that looks risky before you write about it, so the reasons you give are grounded in the actual record rather than guessed from a list row. For the riskiest deals it is also worth querying related activity records for that opportunity to confirm whether the silence is real or whether someone has logged a call or email that did not touch the deal record itself. If auditing is enabled in the environment, the change history is the reliable way to confirm a backwards stage move or a close date that has been pushed repeatedly. Where you cannot establish history, say the deal looks stalled rather than asserting it regressed. Never invent a reason.

Group the flagged deals by owner. Resolve each owner from _ownerid_value with Retrieve Record against the systemuser table to get their full name and internalemailaddress. Then map each owner to a Slack account: use Slack List Users to find the workspace member whose profile email matches the owner's Dynamics email, use Open a Conversation to get that person's DM channel, and use Send a Message to deliver the nudge. If no Slack account matches an owner's email, skip the DM rather than messaging the wrong person, and note the unmatched owner in the leadership summary so it can be corrected.

Each DM should be short and immediately actionable: a one-line opener, then the owner's flagged deals ranked most urgent first, capped at the top five so it stays readable. Give each deal its name, its value, its close date, one plain sentence on why it was flagged, and one concrete suggested next step for that specific deal. Suggest something a rep can actually do today, like re-confirming the close date with the champion or booking a call, not generic advice to follow up. Write in Slack mrkdwn, which uses single asterisks for bold and angle-bracket links, not standard Markdown.

Finally, post one aggregate summary to the sales leadership channel: how many deals were flagged, the total value at risk, the breakdown by owner, and the handful of deals that most need a manager to step in. This is a roll-up for pattern spotting, not a repeat of every DM.

The workflow must stay quiet on good days. An owner with nothing flagged gets no DM at all, not an empty or all-clear message. If nothing is flagged anywhere in the pipeline, skip the leadership post too and end the run silently. Treat the deal data as read-only throughout: never edit deals, change stages, or update close dates in Dynamics 365. Pace the Slack messages so you stay within its roughly one message per second per channel limit, and if Dynamics 365 returns a rate-limit response, honor the Retry-After delay and resume rather than dropping owners from the run.