Every Dynamics 365 organization has a process someone wants to “just automate.” Renewal reminders. Annual contract notices. The once-a-year check-in with every account. The request usually arrives as a short list of emails and dates, and the obvious response is a workflow or a Power Automate flow: set the triggers, write the templates, let it run.
Sometimes that is exactly right. But for a certain kind of process it is the wrong fix, and the failure is hard to spot because nothing appears to break. This article is about how to tell the difference, and what to build instead.
The three-question test
Full automation works when the world stays roughly still between runs. For a process that fires daily, it does. For a process that touches any given customer once a year, it usually doesn’t. Before automating something with a long cycle, ask three questions.
- Do the recipients change between runs? Notices go to people, not companies. Over twelve months, the contact who handled the last renewal may have left, and there may now be two or three people who need to hear about it. A workflow sending to a lookup field on the account will happily email someone who no longer works there.
- Does the offer change between runs? Pricing, terms and the product line all move over a year. A template written twelve months ago may be quietly selling last year’s product at last year’s price.
- Does it fail silently? This is the one that matters most. An automated reminder sent to a blank greeting, a dead mailbox, or nobody at all does not raise an error. It simply doesn’t land, and for a renewal, the first sign that anything went wrong is a subscription that has already expired.
If the answer to all three is yes, the process doesn’t need automating. It needs what we call semi-automatic automation: the system does everything it can - tracking, timing, personalization, and the checks - and a person stays in the loop for the one step that shouldn’t happen unattended.
The pattern: a dashboard that does everything but send
The build for a semi-automatic process is a single-screen dashboard the process owner opens every day or every week. It has four jobs.
First, it shows the whole population and the timing. In the renewals case that is every active subscription customer in one list, with term and expiration date, and three working lists beside it: due in thirty days, due in seven, and expired. The timing logic that a workflow would hide in its triggers is on screen where a person can see it.
Second, it resolves who should receive each notice - and lets there be more than one. Instead of a single “renewal contact” lookup on the account, each contact carries a toggle. The dashboard reads the toggles and lists the people, not the company.
Third, it prepares the message and then checks its own work. In this case every contact has a “Dear” field for the greeting, which the system fills from the first name if it is empty. Then it blocks anything that isn’t ready: a contact whose greeting is still blank, a contact with no email address, an account where nobody is flagged to receive notices at all. Each block is shown in the list with a one-click path to fix it.
Fourth, a person sends - and the send goes through the user’s own mailbox. This is the part most teams skip. When the reminder leaves from the account owner’s Outlook rather than a marketing platform, it reads like a person wrote it, replies land back with that person, and it is far more likely to clear the recipient’s filters. The client in this example has seen more customers write back than they did to bulk mail.
Once a batch is sent, those contacts drop off the list and reappear on the next one when it is their time. The user is only ever looking at what is due, and what is blocked.
What it looks like in practice
The example running through this article is a printing company with a subscription product, mostly annual, some two and three-year terms. And a few hundred customers on it, so renewals fall every week. Their request was three reminders: thirty days before, seven days before, seven days after. The semi-automatic version took the same three dates and put them on a screen, with the checks described above and a Send Reminder button that a person clicks.
Nothing about the pattern is specific to renewals. It fits any long-cycle, person-to-person process: annual account reviews, contract anniversaries, compliance notices, the yearly “are these still the right contacts?” pass. The test is the same three questions.
A quick way to spot candidates
If a process on your automation backlog has a cycle measured in months, addresses individual people, and would not raise an alert if it sent to the wrong person, it is a candidate. Build it so the system does the remembering and the checking, and a person does the sending. It is a small amount of human time in exchange for never finding out about a problem from an expired customer.
P2 Automation builds custom Dynamics 365 dashboards. We call them My Day views for exactly this kind of process. If you have one your team hates, tell us about it: in twenty minutes we’ll say whether a My Day view would fix it, roughly what it would take, and if it wouldn’t.